Displaying 3 results from an estimated 3 matches for "800b485a4".
2010 Oct 16
5
[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 0x0000000004...
2010 Oct 17
0
[LLVMdev] Why gdb can't determine stack of code run in JIT?
...eemed 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 ?? ()
>...
2010 Oct 16
0
[LLVMdev] Why gdb can't determine stack of code run in JIT?
...d 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 ?? (...