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

[Yuri]

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