[cfe-dev] [LLVMdev] Unwind, exception handling, debuggers and profilers

[Renato Golin]

On 19 March 2014 21:53, Robinson, Paul
<Paul_Robinson at playstation.sony.com> wrote:
>> In debug/profile mode (-g, -pg), none of the optimizations that prune
>> unwind information should be allowed to run.

Sigh... Sorry folks, I made the same mistake *again*. I don't mean to
change how passes are run, just to reduce the amount of disturbance in
the debug information. I should have said something like: "When -g is
set, changes to the unwind information should be preserved more
energetically". However, I'm only following Logan's post's ideas, I
don't know how much of that is actually possible.


> And if
> the program itself will not do unwinding, it's okay for the debug
> unwind info to be imperfect.

Yes, but it has to have at least one way of implying the location of
the previous frame, which was the point of my comment.


> Um, does your concept of "unwind" include "debugger displays a backtrace"?

Yes.


> A debugger likes to be able to display the chain of subprogram activations
> that led to the current stopping point (backtrace), but this is different
> from manipulating the process state to imitate the effect of a sequence of
> subprogram de-activations (unwind).
> A debugger also likes to be able to virtually present the process state
> during some not-the-most-recent activation, which is like a virtual unwind,
> but this is not a reason to require full EH tables in all cases; this
> particular debugger feature is well understood by users to be lossy.

The unwind information in Dwarf / ELF is on the same place EH unwind
info is: .eh_frame. The only difference I know is that EH needs the
personality routine to find the frame that is catching the exception,
while debuggers and profilers only do forced unwind, which only need
to know the position of the previous frame, as well as the values of
the stack variables on those frames (or in which registers they were,
etc).

I don't know about the Win64 EH style, but ARM EHABI is not that different!

The main differences are:

1. ARM specific unwind directives that GNU implemented almost
verbatim, and is what GAS uses to create EH unwind tables on ARM.

2. Short tables, which is a condensed set of stack unwind instructions
(1-2 bytes long each) on the word that the pointer to the code in
Dwarf would be.

None of which actually demand any difference in the IR level. The fact
that GNU implemented the ARM directives is also not a reason why we
can't use Dwarf CFI directives to encode EHABI logic in the ASM or obj
outputs. In a way, we should be moving to use CFI-only for all
back-ends.

So, in essence, EH tables and debug tables are the same thing. The
decision to create a new function attribute is mainly to control how
we emit CantUnwind information.

cheers,
--renato