[LLVMdev] Unwind behaviour in Clang/LLVM

[Renato Golin]

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


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.

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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/f53b78ed/attachment.html>