On Thu, Jun 2, 2016 at 9:58 PM, Jason Molenda wrote:
> This has no eh_frame unwind instructions. Even if we were using eh_frame
> at frame 0, you'd be out of luck.
>
I did not understand how eh_frame unwind instructions are not there,
pardon me asking, can you tell me how you inferred that
This has no eh_frame unwind instructions. Even if we were using eh_frame at
frame 0, you'd be out of luck.
I forget the exact order of fallbacks. I think for frame 0 we try to use the
assembly profile unwind ("async unwind plan") and if we can't do that we fall
back to the eh_frame unwind ("s
Hello,
This is happening in TestPrintStackTraces, where we can end up
here:
ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2:
0x77df04e0 <+0>: 48 83 ec 38
subq $0x38, %rsp
0x77df04e4 <+4>: 48 89 04 24
movq %rax, (%rsp)
0x77df04e8 <+8>: 4
It gets so tricky! It's hard for the unwinder to tell the difference between a
real valid stack unwind and random data giving lots of "frames".
It sounds like the problem that needs fixing is to figure out why the assembly
unwind is wrong for frame 0. What do you get for
disass -a
image sh
Ok , currently the problem that I am facing is that there are cases in
which eh_frame should have been used for frame 0 but it isn't and the
assembly unwind just gives wrong information which could only be detected
if the debugger tried to extract more frames. Now the usage of
AddOneMoreFrame in Un
> On May 31, 2016, at 11:31 AM, jing...@apple.com wrote:
>
>
>> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev
>> wrote:
>>
>> Hello,
>> I posted this query a while ago, i still have no answers, I am
>> currently working on Bug 27687 (PrintStackTraces), so the reason for
> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev
> wrote:
>
> Hello,
> I posted this query a while ago, i still have no answers, I am
> currently working on Bug 27687 (PrintStackTraces), so the reason for the
> failure is the erroneous unwinding of the frames from the ze
