<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><span style="line-height:1.5">Tamas</span><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 14, 2015 at 9:36 PM Greg Clayton via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Oct 14, 2015, at 1:02 PM, Joerg Sonnenberger via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On Wed, Oct 14, 2015 at 11:42:06AM -0700, Greg Clayton via lldb-dev wrote:<br>
>> EH frame can't be used to unwind when we are in the first frame because<br>
>> it is only valid at call sites. It also can't be used in frames that<br>
>> are asynchronously interrupted like signal handler frames.<br>
><br>
> This is not necessarily true, GCC can build them like that. I don't<br>
> think we have a flag for clang/LLVM to create full async unwind tables.<br>
<br>
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?<br>
<br>
<br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>