[lldb-dev] Stack trace from within syscall on x86 Linux

[Jason Molenda]

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 <chaorenl at 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 <labath at google.com> wrote:
> 
> On 10 March 2015 at 17:13, Chaoren Lin <chaorenl at 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.
>