[LLVMdev] Unwind behaviour in Clang/LLVM

Thu Feb 6 11:21:25 PST 2014

On Thu, Feb 6, 2014 at 5:29 AM, Renato Golin <renato.golin at linaro.org>wrote:

> Folks,
>
> We're having some discussions about the behaviour of exception handling
> and Dwarf sharing unwind logic, tables, etc. and it seems that the code
> around it wasn't designed with any particular goal in mind, but evolved
> (like the EHABI) and now we're seeing the results from it.
>
> The problems below are assuming C vs. C++, but it actually apply to any
> possibly-exceptional vs. never-exceptional cases.
>
>
> 1. C vs. C++
>
> We have two unwind flags: nounwind, which flags functions that can't
> unwind (leaf, nothrow, etc) and uwtable, which forces generation of the
> table regardless of nounwind. It seems sensible that C++ code with
> exceptions enabled should generate the tables for all functions, in case
> they're called by (or call) external functions. In C we don't want any of
> that.
>
> GCC seems to never emit tables, and G++ always do, even on C code (.c
> files, no exception or anything), which is very sensible and in line with
> my reasoning above. Clang, on the other hand, always generates them. I
> guess it'll have to figure out what to do based on its impressions on what
> language is being used to produce similar results.
>
> I believe that emitting the tables on anything that could potentially
> interact with exceptional code makes sense, but that's clearly a front-end
> decision. To LLVM, nounwind and uwtables should be absolute:
>
> IF (uwtables)
>   IF (nownwind)
>     CantUnwind
>   ELSE
>     Unwind Table
> ELSE
>   do nothing
> ENDIF
>

This looks wrong, based on the LangRef:

"uwtable
  This attribute indicates that the ABI being targeted requires that an
unwind table entry be produce for this function even if we can show that no
exceptions passes by it."

I think it's probably:

if (nounwind)
  can't unwind

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

2. .fnstart/.fnend+friends
>
> Another problem is that the emission of unwinding tables (based on
> .fnstart/.fnend symbols and others) is conditional *only* to the existence
> (or not) of an exception handling class being loaded (EHABI, Dwarf). Which
> means that, we can't disable the EH on a per-function basis.
>
> We'll have to change the way these symbols are emitted, at least when
> using ARMException, so that we can emit the tables and honour the uwtable
> on a per-function basis.
>
> Again, this is a requirement for problem 1, but it'd need to be fixed
> after 3.
>
>
> 3. Unwinding code
>
> Currently, even when no exception handling are needed, the exception code
> is used to generate Dwarf unwinding directives (CFI) for the debugger.
>
> Both DwarfCFIException and ARMException inherit from DwarfException, and
> they are called to do the debug info about the stack unwinding, which is
> (at least) misplaced. The consensus is that this code should be factored
> out.
>
> The part that is relevant to this thread is that, today, if
> -arm-disable-ehabi is requested, ARMException will not be used and we won't
> have a way of generating debug stack directives, which is wrong.
>
> Factoring out this code is a requirement for the unwinding problem (1),
> since if we disable EH today, we'll disable Dwarf stack unwinding
> altogether. But we also need a final solution for problem 4 below before we
> start.
>
>
> 4. Clang EH control
>
> There are a number of Clang/LLVM options to control exception handling:
>  * -fno-excetpion (enable/disable EH on C++ mode, off in C mode)
>  * -fcxx-exception (no idea, is it objC++ specific? does it control tables
> in any way?)
>  * -funwind-tables (forces uwtable attribute?)
>  * -arm-disable-ehabi (ARM specific bogus flag)
>
> Those options are not always completely exclusive, and they damage
> different parts of the compilation process (as seen recently on the list),
> so we need a clear consensus on what each option mean (or should mean), and
> translate it to the back-end (via function attributes). This would
> considerably simplify the back-end and help us tackle this refactoring.
>

I believe the intent is:
  -fexceptions/-fno-exceptions controls whether we generate code that copes
with exceptions passing through it.
  -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).

So:

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

The (-cc1) frontend defaults to -fno-exceptions -fno-cxx-exceptions
-fno-objc-exceptions (I'm not sure why).
The driver defaults to:
  * in ObjC++: -fcxx-exceptions -fobjc-exceptions -fexceptions
  * in ObjC: -fobjc-exceptions -fexceptions
  * in C++: -fcxx-exceptions -fexceptions
  * in C: <nothing>

(Users might want to specify -fexceptions in C, when building code like
qsort that might have exceptions thrown across it.)

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

The 'nounwind' attribute is set if -fexceptions is specified, or if we have
some other way of knowing the function does not throw. Exception: in
-fobjc-exceptions mode, we ask the ObjC runtime whether to set the flag.
This looks like a bug to me.

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

My main target for this problem is to have the one true option on the
> front-ends, and rely only on function attributes on the back-end (including
> tools like llc). For that, I'd love to be left with -fexception only and
> infer all the rest from the language / conditions of the code.
>
> Ex:
>
> IF (C++ mode)
>   IF (-fno-exception)
>     no uwtable
>     no nounwind
>   ELSE
>     uwtable
>     IF (leaf / nothrow)
>       nounwind
>     ENDIF
>   ENDIF
> ELSE
>   no uwtable
>   no nounwind
>

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

> ENDIF
>
> My main goal is to get rid of (at least) -arm-disable-ehabi.
>
>
>
> Finally,
>
> If you got this far, you're *really* interested in making the exception
> handling more user/dev friendly in LLVM, so I welcome any critics about the
> "proposal" above, as well as any explanations of the doubts expressed. I
> may be wrong about many things, feel free to enlighten me! We may have a
> lot less work to do, and I'll be happy. ;)
>
> I believe the dependency graph of the solutions are:
>
> 4 -> 3 -> 2 -> 1
>
> So, we first should solve the flags problem, than refactor the unwinding
> code out of EH, make the debug generation use them as well, and then we can
> start with the EH specific changes. The problem is that 4 will change
> things considerably, so we might need some scaffolding during the whole
> process.
>
> Makes sense?
>
> cheers,
> --renato
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/12b89335/attachment.html>