[LLVMdev] Unwind behaviour in Clang/LLVM

[Richard Smith]

On Thu, Feb 6, 2014 at 1:27 PM, Renato Golin <renato.golin at linaro.org>wrote:

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

-fcxx-exceptions implies -fexceptions if the input kind is C++ and is
ignored if not.
-fobjc-exceptions implies -fexceptions if the input kind is ObjC(++) and is
ignored if not.

Which isn't quite what you asked, but I think the conclusion is the same
(you don't need to care, the driver does the right thing).


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

This (-fexceptions and -g imply -funwind-tables) seems like it's probably
the right thing for most targets. With SjLj exceptions, -fexceptions
probably doesn't need -funwind-tables.

 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/defd33c1/attachment.html>