>> The semantics uwtable is just "make sure it is possible to unwind past >> this function". It doesn't include anything more, >> like the ability to run destructors. It is used for ABIs that require >> it for use in debuggers and profilers. > > Well, that meaning fails when you have both uwtable and nounwind, > which means: "generate a CantUnwind table".Why fails? I would read a "generate a CantUnwind table" as a table that a debugger or profiler can use, but lacks information to allow an exception to be handled.>> I am not too sure about nounwind. I think it is more about using >> unwind for control flow in the language. Having it allows us >> to prune information used for exception handling. > > nounwind translates into "doesNotThrow()", which is *also* used on > "needsUnwindTables()" which is used in "needsCFIMoves()". > > It's not simple. ;) > > cheers, > --renatoCheers, Rafael
On 11 February 2014 14:12, Rafael Espíndola <rafael.espindola at gmail.com> wrote:> Why fails? I would read a "generate a CantUnwind table" as a table > that a debugger or profiler can use, but lacks information to allow an > exception to be handled.Right, I was assuming CantUnwind was interpreted as is by debug and profilers. If CantUnwind is *only* blocking EH, than it looks good. Let Keith's patch go in and I'll have a go trying to merge the two. Thanks, --renato
I assume this "CantUnwind table" is not the same as Unwind table index '.ARM.exidx' at offset 0x818 contains 4 entries: 0x5d4 <main>: 0x1 [cantunwind] because the latter prevent any unwinding, breaking debuggers/profilers/sanitizers. As I understand, the right way to enable basic unwind through any function (without emitting landing pands etc, unless they are needed for something else) is -funwind-tables. I'm going to add that in the driver for all sanitizers then. On Tue, Feb 11, 2014 at 6:20 PM, Renato Golin <renato.golin at linaro.org> wrote:> On 11 February 2014 14:12, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Why fails? I would read a "generate a CantUnwind table" as a table >> that a debugger or profiler can use, but lacks information to allow an >> exception to be handled. > > Right, I was assuming CantUnwind was interpreted as is by debug and > profilers. If CantUnwind is *only* blocking EH, than it looks good. > > Let Keith's patch go in and I'll have a go trying to merge the two. > > Thanks, > --renato > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Maybe Matching Threads
- [LLVMdev] [cfe-dev] Unwind behaviour in Clang/LLVM
- [LLVMdev] [cfe-dev] Unwind behaviour in Clang/LLVM
- [LLVMdev] [cfe-dev] Unwind behaviour in Clang/LLVM
- [LLVMdev] Unwind, exception handling, debuggers and profilers
- [LLVMdev] Unwind, exception handling, debuggers and profilers