[LLVMdev] Unwind, exception handling, debuggers and profilers

[Renato Golin]

On 20 March 2014 02:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> I think this is just 2. It uses .eh_frame for unwinding proper. The
> only  difference in .eh_frame is that there is a personality function
> defined.

If there is no debug information, it should still be possible to
unwind the stack via the saved LR on the stack, no?

If there is only line info, you could even print the function names
with just the LR.

But yes, Debug and EH unwinding should be identical (modulo the PR).


> No. The -g option should never change the set of optimizations that
> are run.

Bad wording. I meant fix the edge cases Logan reported on the LR
removal, which might have some effect (bigger frames by one word), but
that's discussion for another thread.


>> * uwtable
>>   - Generated only when -g or -pg are specified
>
> No. Se above note about -g.

I don't see how not having unwinding information would change the
binary execution.



> What we do today then is that on x86-64 "clang -S" adds uwtable to all
> functions and "clang -S -fno-asynchronous-unwind-tables" doesn't.

This is remarkably similar to the behaviour I want to create. But that
can't be encoded in IR right now wrt. nothrow.

These are the options:

1. no attr: don't emit tables
2. nounwind: emit CantUnwind
3. uwtable: emit table
4. uwtable + nounwind: emit table

This is because uwtable means *also* debug/profiler use, and emitting
CantUnwind could stop them from unwinding, since there is no
information on how to continue unwinding the stack.

The semantics I want is to be able to separate between EH unwinding
and Debug/Profiler unwinding (even though they map to the same
physical tables), so that we DO emit CantUnwind in those cases.


> * arm-unwind-table. The other unwind table format.

No. This is not an ARM specific issue. The table format is back-end
specific, and the IR has no business in interfering with it.

cheers,
--renato