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
