<div dir="ltr"><div><font face="arial, helvetica, sans-serif">After some more debugging, I no longer think it's related to the syscall. The subroutine that invokes the syscall has a strange prologue (see below) which results in a return address stored at ebp+12 instead of ebp+4, which seems to be what LLDB uses to determine if a frame is valid. Is there some way we could not rely on the return address being at ebp+4? Maybe cache esp after every call instruction? Or keep looking up the stack for a valid return address? Or should we call this an intended behavior and use something other than fgets while waiting to be attached in TestHelloWorld.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">libc.so.6`__read:<br></font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">->  0xf7d9cbec <+28>: calll  *%gs:0x10<br></font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">->  0xf7fdb420: pushl  %ecx</font></div><div><font face="monospace, monospace">    0xf7fdb421: pushl  %edx</font></div><div><font face="monospace, monospace">    0xf7fdb422: pushl  %ebp</font></div><div><font face="monospace, monospace">    0xf7fdb423: movl   %esp, %ebp</font></div><div><font face="monospace, monospace">    0xf7fdb425: sysenter</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 10, 2015 at 10:26 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On 10 March 2015 at 17:13, Chaoren Lin <span dir="ltr"><<a href="mailto:chaorenl@google.com" target="_blank">chaorenl@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>According to the Apple dudes in that conversation, <span style="color:rgb(0,0,0);white-space:pre-wrap">UnwindLLDB and </span><span style="color:rgb(0,0,0);white-space:pre-wrap">RegisterContextLLDB are what I should be looking at, correct?</span></div></blockquote></div><br></span>Yes, those are the two main classes. I would go about by going through <span style="color:rgb(0,0,0);white-space:pre-wrap">RegisterContextLLDB::InitializeZerothFrame and try to figure out what UnwindPlan it ends up using. Then compare the unwind plan with the information obtained from gdb, for instance.</span></div><div class="gmail_extra"><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div class="gmail_extra"><span style="color:rgb(0,0,0);white-space:pre-wrap">I don't know where it gets its default unwind plan on i386 (maybe from nowhere?), but the reason the unwinding works (mostly) could be that lldb can read unwind plans from dwarf info which is generally embedded in the files.</span></div><div class="gmail_extra"><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div class="gmail_extra"><span style="color:rgb(0,0,0);white-space:pre-wrap">I suspect unwinding on i386 could be a bit tricky (especially in the proximity of assembly code like syscall internals) since the architecture has less registers, so people tend to reuse ebp for storing other stuff, which makes locating stuff on the stack harder.</span></div></div>
</blockquote></div><br></div>