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

[Chaoren Lin]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150310/10c1efc8/attachment.html>