[LLVMdev] Unwind behaviour in Clang/LLVM

[Renato Golin]

On 6 February 2014 19:21, Richard Smith <richard at metafoo.co.uk> wrote:
>
> if (nounwind)
>   can't unwind
>

can't unwind == unwind table + no EH directives + no EH table


if (uwtable || (!nounwind && need uwtable to unwind))
>   unwind table
>

"need unwind table to unwind" is probably true in almost all cases. At
least in all where ARMException and DwarfCFIException are concerned, which
is the ones we're discussing about.

I'm beginning to think that there is no reason at all to have an uwtable
attribute, given that the -funwind-tables is propagated to the back-end AND
if we emit the table for one function we should do it for all.


I believe the intent is:
>   -fexceptions/-fno-exceptions controls whether we generate code that
> copes with exceptions passing through it.
>

Right. Landing pads, cleanups, etc. We'll need those for emitting the EH
tables, but not the unwind tables, so for this particular discussion, we
don't need to worry.



>   -fcxx-exceptions/-fno-cxx-exceptions controls whether we allow exception
> constructs in C++ code (throw, catch, try) and whether we validate
> exception specifications (both during compilation and at runtime).
>   -fobjc-exceptions/-fno-objc-exceptions controls whether we allow
> exception constructs in ObjC code (@throw, @try, @catch).
>

Language-specific stuff, not even important to the EH tables (since in the
back end we don't care what constructs you use in the language, only the IR
basic block structure).


  -fno-exceptions implies -fno-cxx-exceptions and -fno-objc-exceptions
>   -fcxx-exceptions and -fobjc-exceptions require -fexceptions
>

Will -fcxx-exceptions also include -fexceptions? I mean, if the user
specify -fcxx-exceptions in C, will that also turn on all the internal
flags that -fexception would?

If so, we really don't need to worry at all about them.


-funwind-tables appears to be an entirely orthogonal flag, which is by
> default determined based on the target (with some -f flags to override the
> default), entirely ignoring the -fexceptions flags and language mode.
>

Right. They do clash in the back-end, since one generates EH unwinding and
the other might only generate Dwarf unwinding. We need to clear that
confusion in the back-end, but I don't think that the front-end should even
care on how it gets implemented in the end, as long as it works.


This does not appear to be a flag that an end-user should touch, under most
> circumstances, but it's far from clear to me that we're getting the default
> right here (maybe it should depend on -fexceptions?).
>

I think that both -fexceptions and -g should turn -funwind-tables by
default. The third user is the backtrace which doesn't need debug or EH
info (just the unwind table), and you need the -funwind-tables IFF your
target doesn't have it on by default.

I can only think about GPU targets that won't need any of that, but they're
not using Dwarf or EHABI handlers, so we shouldn't concern about that.
Embedded CPUs might want them disabled to save space, and for that we
should actively disable (-fno-unwind-tables or -Os/z).


The 'nounwind' attribute is set if -fexceptions is specified, or if we have
> some other way of knowing the function does not throw.
>

You mean -fno-exceptions, I believe. I think this behaviour is correct.


The 'uwtable' attribute is set based on the value we determined for
> -funwind-tables (either through an explicit flag or from the target).
>

Seems reasonable, though unnecessary in most cases.


This seems wrong -- in C with -fexceptions we do not want nounwind, and
> sometimes want uwtable (depending on ABI).
>

Yes, I agree, I was wrong. Unwind tables are almost entirely orthogonal to
EH and Dwarf.


Thanks everyone for the enlightening responses, I'll have to digest
everything again and see if I remember any of it tomorrow... :)

I managed to get a definite step out of this (http://llvm.org/PR18758), and
I think we can safely ignore the -fexceptions flags for now.

My revised plan:

0. Get Keith's patch in to have unwinding without EH
1. Connect -funwind-tables with EHABI
2. Abstract the unwind code where both EH and the Dwarf producers can make
use of
3. Disable unwind tables if -fno-unwind-tables on ARM
4. Apply CFI unwinding if -funwind-tables AND -fno-exceptions on EHABI

I'm not sure why we're using .save/.push and not CFI with EHABI, but step 2
would be a lot simpler if we could unify both exception handling classes,
and step 4 would completely disappear. Anton/Logan?

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/8de3db82/attachment.html>