Hi guys, sorry for not seeing this thread yesterday. lldb should be able to handle this function, if and only if it knows the start address for the function/symbol. The assembly instruction profiler can do the right thing with an instruction sequence like this.
The first thing to do is (lldb) image show-unwind -a $pc when you're stopped in the function, or (lldb) image show-unwind -n __read This will dump the various UnwindPlans that lldb can use for this function. To see how the unwinder is actually walking the stack, before you step into __read, do (lldb) log enable lldb unwind then go into __read and try to backtrace a couple of frames. The output may not be easy to read - but send it along and I can interpret. J > On Mar 10, 2015, at 5:29 PM, Chaoren Lin <chaor...@google.com> wrote: > > 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. > > libc.so.6`__read: > > -> 0xf7d9cbec <+28>: calll *%gs:0x10 > > -> 0xf7fdb420: pushl %ecx > 0xf7fdb421: pushl %edx > 0xf7fdb422: pushl %ebp > 0xf7fdb423: movl %esp, %ebp > 0xf7fdb425: sysenter > > On Tue, Mar 10, 2015 at 10:26 AM, Pavel Labath <lab...@google.com> wrote: > > On 10 March 2015 at 17:13, Chaoren Lin <chaor...@google.com> wrote: > According to the Apple dudes in that conversation, UnwindLLDB and > RegisterContextLLDB are what I should be looking at, correct? > > Yes, those are the two main classes. I would go about by going through > 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. > > 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. > > 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. > _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
