[LLVMdev] Unwind, exception handling, debuggers and profilers (original) (raw)

Logan Chien tzuhsiang.chien at gmail.com
Sun Mar 23 09:37:28 PDT 2014

Hi Renato,

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.

I don't quite understand what do you mean here.

I was trying to say: due to the design of .ARM.exidx, you won't be possible to emit both the cantunwind directive and the stack unwinding information at the same time (they share the same word.) Thus, if -funwind-tables is available, then we should ignore the nounwind attribute. Otherwise, the force unwind simply won't work. That's the reason why I said that if the function has uwtable attribute, then we should not emit cantunwind directive.

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".

IMO, noehtable attribute won't solve the issue. In my article, I was using ehtable to provide the guarantee of the information to throw-and-catch the exception, but you are using in the converse way. In fact, uwtable and ehtable means almost the SAME table in ARM EHABI (except the LSDA.)

Furthermore, no exception handling table (LSDA) will be generated for the functions without the landingpad instruction, even -funwind-tables are given. IMO, adding noehtable attribute won't reach your goal to remove the unnecessary unwind table.

Also, do not assume that EHABI behaviour in LLVM is currently correct, especially related to uwtable and nounwind. Those were made with the x8664's ABI in mind, and have only interoperated seriously with DwarfCFIException until very recently.

If you don't care about the backward compatibility at LLVM assembly level at all, then the simplest solution is to determine whether we should generate unwind table by the existence of the uwtable function attribute. The result should be:

This combination will work (including the interleaving of C and C++ programs). The will be only a little difference when the function really throws an exception and the front-end did not generate the landingpad instruction. Since clang will transform "throw ()" or "noexpect(true)" to:

define void @_Z3foov() nounwind { invoke void @_Z9may_throwv() to label %1 unwind label %2

; :1 ret void

; :2 %3 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) filter [0 x i8*] zeroinitializer %4 = extractvalue { i8*, i32 } %3, 0 tail call void @__cxa_call_unexpected(i8* %4) unreachable }

The landingpad instruction will be emitted to catch every exceptions, and call __cxa_call_unexpected() to stop the unwinding procedure.

BUT, this means that all of the front-ends should be updated if they was not emitting uwtable attribute. I am afraid that this won't be a viable solution.

Best regards, Logan

Footnote

[1] To be precise, one additional word will be emit to mark the absence of LSDA but this word should be emitted anyway.

On Sat, Mar 22, 2014 at 3:07 AM, Renato Golin <renato.golin at linaro.org>wrote:

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 x8664'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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140324/4d22f81e/attachment.html>

More information about the llvm-dev mailing list