[lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling

[Tamas Berghammer via lldb-dev]

If we are trying to unwind from a non call site (frame 0 or signal handler)
then the current implementation first try to use the non call site unwind
plan (usually assembly emulation) and if that one fails then it will fall
back to the call site unwind plan (eh_frame, compact unwind info, etc.)
instead of falling back to the architecture default unwind plan because it
should be a better guess in general and we usually fail with the assembly
emulation based unwind plan for hand written assembly functions where
eh_frame is usually valid at all address.

Generating asynchronous eh_frame (valid at all address) is possible with
gcc (I am not sure about clang) but there is no way to tell if a given
eh_frame inside an object file is valid at all address or only at call
sites. The best approximation what we can do is to say that each eh_frame
entry is valid only at the address what it specifies as start address but
we don't make a use of it in LLDB at the moment.

For the 2nd part of the original question, I think changing the eh_frame
based unwind plan after a failed unwind using instruction emulation is only
a valid option for the PC where we tried to unwind from because the
assembly based unwind plan could be valid at other parts of the function.
Making the change for that 1 concrete PC address would make sense, but have
practically no effect because the next time we want to unwind from the
given address we use the same fall back mechanism as in the first case and
the change would have only a very small performance gain.

Tamas

On Wed, Oct 14, 2015 at 9:36 PM Greg Clayton via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

>
> > On Oct 14, 2015, at 1:02 PM, Joerg Sonnenberger via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >
> > On Wed, Oct 14, 2015 at 11:42:06AM -0700, Greg Clayton via lldb-dev
> wrote:
> >> EH frame can't be used to unwind when we are in the first frame because
> >> it is only valid at call sites. It also can't be used in frames that
> >> are asynchronously interrupted like signal handler frames.
> >
> > This is not necessarily true, GCC can build them like that. I don't
> > think we have a flag for clang/LLVM to create full async unwind tables.
>
> Most compilers don't generate stuff that is complete, and if it is
> complete, I am not aware of any markings on EH frame that states it is
> complete. So we really can't use it unless we know the info is complete.
> Was there ever an additional augmentation letter that was attached to the
> complete EH frame info?
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151015/457adfee/attachment.html>