<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>J<br><div><br><div><div>On Oct 15, 2010, at 5:58 PM, Yuri wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I run some code in JIT on x86-64 architecture.<br>Even though llvm::NoFramePointerElim is set to true, I still see weird <br>stack in gdb, see below.<br>800b485a4 is the current rip register where gdb stopped. Then many <br>others values aren't valid. Then there is value that looks ok again.<br><br>Why gdb can't determine stack?<br><br>Yuri<br><br><br>-- stack --<br>#0 0x0000000800b485a4 in ?? ()<br>#1 0x000000000000005f in ?? ()<br>#2 0x0000000003899330 in ?? ()<br>#3 0x000000000422d6f8 in ?? ()<br>#4 0x0000000000ea7468 in ?? ()<br>#5 0x00000000051b0600 in ?? ()<br>#6 0x00000000013714d8 in ?? ()<br>#7 0x0000000003b425c8 in ?? ()<br>#8 0x000000000397c420 in ?? ()<br>#9 0x00007fffffffae60 in ?? ()<br>#10 0x0000000800b481b1 in ?? ()<br>#11 0x0000000003b42590 in ?? ()<br>#12 0x00000000038993c0 in ?? ()<br>#13 0x000000000397c940 in ?? ()<br>#14 0x00000000038992e8 in ?? ()<br>#15 0x0000000003899330 in ?? ()<br>#16 0x0000000004b0a748 in ?? ()<br>#17 0x000000000556e818 in ?? ()<br>#18 0x0000000003899378 in ?? ()<br>#19 0x00000000038993c0 in ?? ()<br><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></div></blockquote></div><br></div></div></body></html>