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

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

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

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