llvm dev - Oct 2010 - [LLVMdev] Why gdb can't determine stack of code run in JIT?

I run some code in JIT on x86-64 architecture.
Even though llvm::NoFramePointerElim is set to true, I still see weird 
stack in gdb, see below.
800b485a4 is the current rip register where gdb stopped. Then many 
others values aren't valid. Then there is value that looks ok again.

Why gdb can't determine stack?

Yuri


-- stack --
#0  0x0000000800b485a4 in ?? ()
#1  0x000000000000005f in ?? ()
#2  0x0000000003899330 in ?? ()
#3  0x000000000422d6f8 in ?? ()
#4  0x0000000000ea7468 in ?? ()
#5  0x00000000051b0600 in ?? ()
#6  0x00000000013714d8 in ?? ()
#7  0x0000000003b425c8 in ?? ()
#8  0x000000000397c420 in ?? ()
#9  0x00007fffffffae60 in ?? ()
#10 0x0000000800b481b1 in ?? ()
#11 0x0000000003b42590 in ?? ()
#12 0x00000000038993c0 in ?? ()
#13 0x000000000397c940 in ?? ()
#14 0x00000000038992e8 in ?? ()
#15 0x0000000003899330 in ?? ()
#16 0x0000000004b0a748 in ?? ()
#17 0x000000000556e818 in ?? ()
#18 0x0000000003899378 in ?? ()
#19 0x00000000038993c0 in ?? ()

When gdb is stopped in a function with no known start address, it has to make a
guess about how to get the caller's rip.  Either we assume that the saved
rip is at rsp+8, or we assume that the saved rip is found via the rbp register. 
But it's a guess either way - gdb can't find the start of the function
so it can't know which is the correct method.  It would be nice if it could
realize that a saved rip of 0x5f is unlikely and try an alternate method, but it
doesn't do anything that sophisticated.

There is some divergence between how the FSF gdb and how the Apple gdb backtrace
on x86-64.  Is this FSF gdb?  I wouldn't expect a stack like this from the
Apple gdb but I haven't tried a scenario like this myself.

Once you're off frame 0, if you don't have a function start address you
can assume that the frames on the stack are using a standard rbp type call frame
and walk the stack reliably.  But frame 0 can be tricky when you're guessing
like this.

J

On Oct 15, 2010, at 5:58 PM, Yuri wrote:
> I run some code in JIT on x86-64 architecture.
> Even though llvm::NoFramePointerElim is set to true, I still see weird 
> stack in gdb, see below.
> 800b485a4 is the current rip register where gdb stopped. Then many 
> others values aren't valid. Then there is value that looks ok again.
> 
> Why gdb can't determine stack?
> 
> Yuri
> 
> 
> -- stack --
> #0  0x0000000800b485a4 in ?? ()
> #1  0x000000000000005f in ?? ()
> #2  0x0000000003899330 in ?? ()
> #3  0x000000000422d6f8 in ?? ()
> #4  0x0000000000ea7468 in ?? ()
> #5  0x00000000051b0600 in ?? ()
> #6  0x00000000013714d8 in ?? ()
> #7  0x0000000003b425c8 in ?? ()
> #8  0x000000000397c420 in ?? ()
> #9  0x00007fffffffae60 in ?? ()
> #10 0x0000000800b481b1 in ?? ()
> #11 0x0000000003b42590 in ?? ()
> #12 0x00000000038993c0 in ?? ()
> #13 0x000000000397c940 in ?? ()
> #14 0x00000000038992e8 in ?? ()
> #15 0x0000000003899330 in ?? ()
> #16 0x0000000004b0a748 in ?? ()
> #17 0x000000000556e818 in ?? ()
> #18 0x0000000003899378 in ?? ()
> #19 0x00000000038993c0 in ?? ()
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101015/f7ff1dc0/attachment.html>

On 10/15/2010 18:08, Jason Molenda wrote:
> When gdb is stopped in a function with no known start address, it has 
> to make a guess about how to get the caller's rip.  Either we assume 
> that the saved rip is at rsp+8, or we assume that the saved rip is 
> found via the rbp register.  But it's a guess either way - gdb
can't
> find the start of the function so it can't know which is the correct 
> method.  It would be nice if it could realize that a saved rip of 0x5f 
> is unlikely and try an alternate method, but it doesn't do anything 
> that sophisticated.
>
> There is some divergence between how the FSF gdb and how the Apple gdb 
> backtrace on x86-64.  Is this FSF gdb?  I wouldn't expect a stack like 
> this from the Apple gdb but I haven't tried a scenario like this
myself.
This is FSF gdb.
>
> Once you're off frame 0, if you don't have a function start address
> you can assume that the frames on the stack are using a standard rbp 
> type call frame and walk the stack reliably.  But frame 0 can be 
> tricky when you're guessing like this.
So is there any way to let gdb know the method to compute stack? I 
assume that with NoFramePointerElim set it will be via the rbp register.

Yuri

I know you haven't been able to get the JIT gdb support to work on
FreeBSD (right?), but this is exactly the problem that we ran into
that it solves.

http://llvm.org/docs/DebuggingJITedCode.html

I don't know what heuristic gdb is trying to use to unwind the stack,
but it doesn't work.  I asked a gdb developer about it two summers ago
when I was working on this, but he seemed dismissive about teaching
gdb how to get this right.

Reid

On Fri, Oct 15, 2010 at 8:58 PM, Yuri <yuri at rawbw.com>
wrote:
> I run some code in JIT on x86-64 architecture.
> Even though llvm::NoFramePointerElim is set to true, I still see weird
> stack in gdb, see below.
> 800b485a4 is the current rip register where gdb stopped. Then many
> others values aren't valid. Then there is value that looks ok again.
>
> Why gdb can't determine stack?
>
> Yuri
>
>
> -- stack --
> #0  0x0000000800b485a4 in ?? ()
> #1  0x000000000000005f in ?? ()
> #2  0x0000000003899330 in ?? ()
> #3  0x000000000422d6f8 in ?? ()
> #4  0x0000000000ea7468 in ?? ()
> #5  0x00000000051b0600 in ?? ()
> #6  0x00000000013714d8 in ?? ()
> #7  0x0000000003b425c8 in ?? ()
> #8  0x000000000397c420 in ?? ()
> #9  0x00007fffffffae60 in ?? ()
> #10 0x0000000800b481b1 in ?? ()
> #11 0x0000000003b42590 in ?? ()
> #12 0x00000000038993c0 in ?? ()
> #13 0x000000000397c940 in ?? ()
> #14 0x00000000038992e8 in ?? ()
> #15 0x0000000003899330 in ?? ()
> #16 0x0000000004b0a748 in ?? ()
> #17 0x000000000556e818 in ?? ()
> #18 0x0000000003899378 in ?? ()
> #19 0x00000000038993c0 in ?? ()
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Sun, 17 Oct 2010 11:28:35 -0400
Reid Kleckner <reid.kleckner at gmail.com> wrote:
> I know you haven't been able to get the JIT gdb support to work on
> FreeBSD (right?), but this is exactly the problem that we ran into
> that it solves.
> 
> http://llvm.org/docs/DebuggingJITedCode.html
> 
> I don't know what heuristic gdb is trying to use to unwind the stack,
> but it doesn't work.  I asked a gdb developer about it two summers ago
> when I was working on this, but he seemed dismissive about teaching
> gdb how to get this right.
Doesn't LLVM already generate asynchronous unwind tables for exception
handling purposes? On x86-64 thats the only way to get a stacktrace
anyway since framepointers are omitted by default.
Won't unwinding the stack via async unwind tables work (or be made to
work) on x86-32 too?

Best regards,
--Edwin

On 10/17/2010 08:28, Reid Kleckner wrote:
> I know you haven't been able to get the JIT gdb support to work on
> FreeBSD (right?), but this is exactly the problem that we ran into
> that it solves.
>    
Yes, I can't link with libllvm.a for various reasons so I use libLLVM.so 
and I still wait for the fix in llvm-aware gdb.
Do you know when can this be expected? It's not needed normally, only 
when running into some issues and debugging it. I am sure many people 
will be asking about this with expanding llvm acceptance.

Yuri