[LLVMdev] Why gdb can't determine stack of code run in JIT?

Jason Molenda jmolenda at apple.com
Fri Oct 15 18:08:34 PDT 2010


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>


More information about the llvm-dev mailing list