[cfe-dev] Unwind behaviour in Clang/LLVM

[Renato Golin]

On 6 February 2014 18:02, Keith Walker <Keith.Walker at arm.com> wrote:

> You can make GCC emit unwind tables for C if you use the command line
> option -funwind-tables.
>
> This could be useful if you are compiling C code which is called by C++
> code and which itself calls C++ code and you wish the C++ exception to
> propagate through the C code.
>

Yes, we still need the possibility to force unwind tables in C code, and
that's what -funwind-tables is there for.

Since -fexception only triggers landing pads and cleanup blocks, we don't
need to worry about it, but the -funwind-tables should communicate with the
back-end via some clear and unambiguous means.

Maybe function attributes aren't enough, but we need to make sure that they
don't clash with the flags, if we do use them.


There is some interaction in that if you are generating a .eh_frame section
> for exception handling then there is little sense is generating a DWARF
> .debug_frame section as well;  I would hope most debuggers could use the
> .eh_frame section if present as its format is so similar to a .debug_frame
> section.
>

Right, makes sense.

It seems, then, that we basically need two types of unwinding, and they
could live in different places.

Before your patch, the debugger wasn't able to use the EHABI stack
unwinding code. Is that because it was using .push/.save instead of .cfi
directives? Or is that because the table generated is not readable by
normal debuggers?


What does -arm-disable-ehabi actually mean?
>
> Currently it is effectively "don't generate exception tables".
>

Yes. It has no effect on the front-end. It should actually be replaced by
whatever mechanism -f{no-}unwind-tables is using.

I created a bug (PR18758) and copied you.


Maybe is should it rather be "don't generate EHABI exception tables but
> generate .eh_frame tables instead"?   Obviously this requires the necessary
> DWARF like support to generate the information for the .eh_frame tables.
>

This is where things start getting a little interesting. If we all agree
that generating unwind tables is good *in any case*, even on embedded
devices like Coretx-M0, than I think we should hard-code .eh_frame
generation under any circumstance, and use -funwind-tables to generate
EHABI tables.

Clang would then enable it by default depending on the language contract,
which is of little importance to the back-end.

But the question I don't have an answer yet is: if we use that flag, what
do we do when -fno-unwind-tables clashes with the uwtables function
attribute?


 IF(arm_disable_ehabi)
>    USE ARMException
>  ELSE
>    USE DwarfCFIException
>  ENDIF
>

Today, it means:

IF(arm_disable_ehabi)
  nothing at all
ELSE
  USE ARMException
ENDIF

I'm sensing that the consensus is driving towards *always* emitting unwind
tables, but I can't just use DwarfCFIException on ARM, it won't work. This
is why we need to carefully extract the common interface, not just for the
debug x EH problem, but also the Dwarf x EHABI problem.


Hmmm!   I'm very nervous about the backend making decisions based on the
> language.
>

No, sorry! That was a front-end decision! I'd die before enquiring the
language in the back-end! :D


  IF (-funwind-tables || -fexceptions)
>     uwtable
>     IF (leaf / nothrow)
>       nounwind
>     ENDIF
>   ELSE
>     no uwtable
>     no nounwind
>   ENDIF
>

I'd only like to completely remove the unwind tables if the user forcefully
selected -fno-unwind-tables, so I wouldn't like Clang to automatically
select that, even in C code.


-fexceptions allows compiling exception handling constructs in the source
> language and enables the generation of unwind tables.
> -funwind-tables only enables the generation of unwind tables.
>

That makes total sense. Right now, I can't see a difference between
-fno-unwind-tables and -arm-disable-ehabi.

As far as I could see, -fcxx-exceptions has no relevance to this
discussion, so I'll drop it right here.

My questions about the flags were answered, and it's going to be a lot
easier than I thought. I'll change the ehabi flag to connect via
unwind-tables and will send a patch review.

Once that's done, we can get some work done on refactoring ARMException,
but only after your patch lands upstream.

Thanks!
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140206/b28466d9/attachment.html>