llvm dev - Feb 2014 - [LLVMdev] [cfe-dev] Unwind behaviour in Clang/LLVM

Hi Joerg,

You are right, there are three separate issues here: unwinding, debug info
and exception handling.

Debug and EH require unwinding, but one doesn't require the other and
unwinding is not exclusive to either.


On 6 February 2014 14:51, Joerg Sonnenberger <joerg at
britannica.bec.de>wrote:
> (1) Should enough unwind data be provided for a basic, read-only stack
> walk?
>
As you said, platforms and systems should define their own defaults, and
that's mainly driven by the front-end via flags and triples.

The behaviour of flags should be precise, and different flags should be
on/off by default depending on the triple, so build systems can enforce
flags if they need to make sure the behaviour will be the same across
different platforms.

I can't decide that, but those decisions should stay in the front-end. To
the back-end, function attributes should be able to control table emission
(or maybe we need flags, I don't know).


> That said, the option already exists for changing the default:
> -funwind-tables. There shouldn't be another ARM specific flag.
>
So, can I assume that -f{no-}unwind-tables's syntax is to completely
enable/disable the unwind tables and add/remove the ELF sections from the
objects? If that's so, I can easily remove -arm-disable-ehabi and check on
that flag.

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

On Thu, Feb 06, 2014 at 03:18:02PM +0000, Renato Golin
wrote:
> Debug and EH require unwinding, but one doesn't require the other and
> unwinding is not exclusive to either.
Correct.
> I can't decide that, but those decisions should stay in the front-end.
To
> the back-end, function attributes should be able to control table emission
> (or maybe we need flags, I don't know).
I disagree on this. Table emission by itself doesn't involve code
generation and I don't think it makes sense as a per function attribute
either. You either want it for all functions or only when needed (e.g.
exceptions are possible). As such, it makes perfect sense to me as a
global flag.
> > That said, the option already exists for changing the default:
> > -funwind-tables. There shouldn't be another ARM specific flag.
> >
> 
> So, can I assume that -f{no-}unwind-tables's syntax is to completely
> enable/disable the unwind tables and add/remove the ELF sections from the
> objects? If that's so, I can easily remove -arm-disable-ehabi and check
on
> that flag.
-funwind-tables says that the tables should always be emitted. If there
are no other reasons like exception handling, they will only destructive
stack unwind.

-fno-unwind-tables says that tables should only be emitted, if another
(language specific) reason requires them. So for C++, it would normally
be ignored as exception support is the default. For C code, it would
ensure that no .eh_frame* sections are emitted, even on platforms that
require them for the ABI like AMD64.

Joerg

On Feb 6, 2014, at 10:47 AM, Joerg Sonnenberger <joerg at
britannica.bec.de> wrote:
> On Thu, Feb 06, 2014 at 03:18:02PM +0000, Renato Golin wrote:
>> I can't decide that, but those decisions should stay in the
front-end. To
>> the back-end, function attributes should be able to control table
emission
>> (or maybe we need flags, I don't know).
> 
> I disagree on this. Table emission by itself doesn't involve code
> generation and I don't think it makes sense as a per function attribute
> either. You either want it for all functions or only when needed (e.g.
> exceptions are possible). As such, it makes perfect sense to me as a
> global flag.
Does LTO change this analysis?

-- 
Stephen Checkoway

> I disagree on this. Table emission by itself doesn't involve code
> generation and I don't think it makes sense as a per function attribute
> either. You either want it for all functions or only when needed (e.g.
> exceptions are possible). As such, it makes perfect sense to me as a
> global flag.
It has to be an attribute because of LTO. You can LTO a file compiled
with -fasynchronous-unwind-tables and one with
-fno-asynchronous-unwind-tables. That is why we have the uwtable
attribute.

Cheers,
Rafael