<div dir="ltr"><div>Source code:</div><div>int f() { return 5; }</div><div>int main() {</div><div>  f();</div><div>  return 0;</div><div>}</div><div><br></div><div>Can you execute the following commands on lldb:</div><div>
<br></div><div>log enable lldb unwind</div><div>b f</div><div>r</div><div>bt</div><div><br></div><div>and see what it outputs?</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 12, 2014 at 3:51 PM, Jason Molenda <span dir="ltr"><<a href="mailto:jmolenda@apple.com" target="_blank">jmolenda@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hm, on my Mac I'm getting the correct registers from the eh_frame.<br>
<br>
* thread #1: tid = 0xce36, 0x00001f30 a.out`main, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1<br>
    #0: 0x00001f30 a.out`main<br>
a.out`main:<br>
-> 0x1f30:  pushl  %ebp<br>
   0x1f31:  movl   %esp, %ebp<br>
   0x1f33:  subl   $0x8, %esp<br>
   0x1f36:  calll  0x1f3b                    ; main + 11<br>
(lldb) image show-unwind -n main<br>
<lldb.driver.main-thread> (i386) /private/tmp/a.out: Reading EH frame info<br>
First non-prologue instruction is at address 0x1f36 or offset 6 into the function.<br>
<br>
Asynchronous (not restricted to call-sites) UnwindPlan for a.out`main (start addr 0x1f30):<br>
This UnwindPlan originally sourced from assembly insn profiling<br>
Address range of this UnwindPlan: [a.out.__TEXT.__text + 0-0x00000029)<br>
row[0]: 0x00000000: CFA=esp +4 => esp=esp+4 eip=[esp]<br>
row[1]: 0x00000001: CFA=esp +8 => ebp=[esp] esp=esp+8 eip=[esp+4]<br>
row[2]: 0x00000003: CFA=ebp +8 => ebp=[ebp] esp=ebp+8 eip=[ebp+4]<br>
row[3]: 0x00000028: CFA=esp +4 => esp=esp+4 eip=[esp]<br>
<br>
Synchronous (restricted to call-sites) UnwindPlan for a.out`main (start addr 0x1f30):<br>
This UnwindPlan originally sourced from eh_frame CFI<br>
Address range of this UnwindPlan: [a.out.__TEXT.__text + 0-0x00000029)<br>
row[0]: 0x00000000: CFA=esp +4 => eip=[esp]<br>
row[1]: 0x00000001: CFA=esp +8 => ebp=[esp] eip=[esp+4]<br>
row[2]: 0x00000003: CFA=ebp +8 => ebp=[ebp] eip=[ebp+4]<br>
<br>
<br>
The UnwindAssembly_x86 generated UnwindPlan and the clang-generated eh_frame cfi match up...<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> On Aug 12, 2014, at 3:38 PM, Tong Shen <<a href="mailto:endlessroad@google.com">endlessroad@google.com</a>> wrote:<br>
><br>
> In i386 .eh_frame, esp=4, ebp=5. I confirmed it by cfi directives gcc generates and objdump -W.<br>
><br>
> So it's either we chose the wrong eRegisterKindXXX, or we put {dwarf, gcc}_{esp, ebp}_i386 in wrong order in source/Plugins/Process/Utility/RegisterContext_x86.h :-)<br>
><br>
><br>
> On Tue, Aug 12, 2014 at 3:23 PM, Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br>
> Hi Tong, sorry for not replying earlier.<br>
><br>
> I don't understand why the current code is wrong.<br>
><br>
>         eRegisterKindGCC = 0,    // the register numbers seen in eh_frame<br>
>         eRegisterKindDWARF,      // the register numbers seen DWARF<br>
><br>
> and<br>
><br>
>         SectionSP sect = sl->FindSectionByType (eSectionTypeEHFrame, true);<br>
>         if (sect.get())<br>
>         {<br>
>             m_eh_frame = new DWARFCallFrameInfo(m_object_file, sect, eRegisterKindGCC, true);<br>
>         }<br>
><br>
> We create a DWARFCallFrameInfo object to read the eh_frame information and we tell it that the register kind to use for the reg numbers is eRegisterKindGCC - aka the eh_frame register numbering domain.<br>
><br>
> This all looks correct to me, and designed specifically to handle the case of that ancient gcc register numbering bug in the eh_frame section for i386.<br>
><br>
> We never read the actual DWARF debug_frame (today) because I've never seen a case where it had more information than the eh_frame unwind info.<br>
><br>
><br>
><br>
> > On Aug 12, 2014, at 1:36 PM, Tong Shen <<a href="mailto:endlessroad@google.com">endlessroad@google.com</a>> wrote:<br>
> ><br>
> > Aha, got it.<br>
> > Patch confirmed and attached.<br>
> ><br>
> ><br>
> > On Tue, Aug 12, 2014 at 12:51 PM, Ed Maste <<a href="mailto:emaste@freebsd.org">emaste@freebsd.org</a>> wrote:<br>
> > On 12 August 2014 15:43, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
> > ><br>
> > > Hey Tong,<br>
> > ><br>
> > > Ah interesting.  The register infos in lldb have a vector of different register numbers (I think we call them "register kinds") based on the type of encoding you're using.  Let's have a look at that to see if we can adjust the code to query for the right register kind.  We'll look at this today!<br>

> ><br>
> > There was a thread on this topic on this list a while back, and I<br>
> > think the two register sets in question here are DWARF and GCC, which<br>
> > are identical in all cases except that i386 swaps esp and ebp between<br>
> > the two.  This is all the legacy of an ancient GCC bug.  So I think<br>
> > you're right Todd, just picking the other set should solve this.<br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Best Regards, Tong Shen<br>
> > <fix_register_kind.patch>_______________________________________________<br>
> > lldb-commits mailing list<br>
> > <a href="mailto:lldb-commits@cs.uiuc.edu">lldb-commits@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Best Regards, Tong Shen<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Regards, Tong Shen</div>
</div>