[LLVMdev] Unwind, exception handling, debuggers and profilers (original) (raw)
Renato Golin renato.golin at linaro.org
Fri Mar 21 12:07:10 PDT 2014
- Previous message: [LLVMdev] Unwind, exception handling, debuggers and profilers
- Next message: [LLVMdev] Unwind, exception handling, debuggers and profilers
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 21 March 2014 18:47, Logan Chien <tzuhsiang.chien at gmail.com> wrote:
* There's the table for ARM target:
- no attribute => emit unwind table - with nounwind => emit unwind table with cantunwind - with uwtable => emit unwind table - with uwtable+nounwind => emit unwind table WITHOUT the cantunwind The cantunwind record will stop the unwinder, and cantunwind will conflict with the stack unwind information according to EHABI. Thus, we should not emit cantunwind for the function with uwtable.
Logan,
Based on the current behaviour, you only need one flag: nounwind, which should only be emitted if -fno-unwind-tables is chosen AND the function can't unwind.
Also, do not assume that EHABI behaviour in LLVM is currently correct, especially related to uwtable and nounwind. Those were made with the x86_64's ABI in mind, and have only interoperated seriously with DwarfCFIException until very recently.
There has to be a way to disable unwind tables, so either the "no attribute" behaviour above is wrong or we need a new attribute "noehtable".
There has to be a way to emit CantUnwind, so if the behaviour above is right, the "uwtables" attribute is only related to forced unwind (debug, profiler), not exception handling.
There has to be a way to map "throw()" into IR, and "nounwind" seems to be the one to use. The fact that CantUnwind is only emitted without "uwtable" reinforces the idea that "uwtable" is forced unwind.
cheers, --renato
- Previous message: [LLVMdev] Unwind, exception handling, debuggers and profilers
- Next message: [LLVMdev] Unwind, exception handling, debuggers and profilers
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]