[cfe-dev] Unwind, exception handling, debuggers and profilers

[Logan Chien]

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
> x86_64'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:

- no attribute => no table generated
- with nounwind attribute => no table generated
- with uwtable attribute => generate unwind table (with LSDA)
- with uwtable+nounwind attribute => generate unwind table (without
cantunwind)

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

; <label>:1
  ret void

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