[lldb-dev] Stack trace from within syscall on x86 Linux
chaorenl at google.com
Tue Mar 10 17:29:35 PDT 2015
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.
-> 0xf7d9cbec <+28>: calll *%gs:0x10
-> 0xf7fdb420: pushl %ecx
0xf7fdb421: pushl %edx
0xf7fdb422: pushl %ebp
0xf7fdb423: movl %esp, %ebp
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev