interpreter question, darwin libffi
Andrew Haley
aph@redhat.com
Sun Feb 2 21:06:00 GMT 2003
Andreas Tobler writes:
> Andrew Haley wrote:
> >
> > Perhaps sp is saved on the stack at an offset from the frame pointer.
> > Then a call is made. When the call resturns, the frame pointer is not
> > restored correctly, so when POPL is executed the wrong stack slot is
> > overwritten. All you have to do to check this theory is print
> > __builtin_frame_address(0) before and after ffi_java_raw_call().
>
> How do I print this frame_address? Can I do that in the gdb?
With printf.
> > It's possible that it's not the frame pointer that is being corrupted,
> > but some other register.
> >
> > 1: x/i $pc 0x43e94 <_ZN16_Jv_InterpMethod3runEPvP7ffi_raw+9476>: stw r10,4(r13)
> >
> > This is writing to a double word memory location that is passed from
> > the caller. Perhaps the caller didn't allocate enough space or
> > perhaps the register or memory slot that cotains retp has been
> > corrupted.
> >
> > To see if this is true, check retp when _Jv_InterpMethod::run is
> > entered and again when your PC is overwritten.
>
> Here the steps:
>
> Breakpoint 1, _Jv_InterpMethod::run(void*, ffi_raw*) (this=0x860de0,
> retp=0xbffff328, args=0xbffff1b0) at
> /Volumes/xufs/gcc-cvs/gcc/libjava/interpret.cc:780
> 2: x/4xw 3221222188
> 0xbffff32c: 0xbffff37c 0x007d40c0 0x000a7130 0x90003dd0
> (gdb) p retp
> 4ドル = (void *) 0xbffff328
> (gdb) c
> Continuing.
>
> Breakpoint 2, _Jv_InterpMethod::run(void*, ffi_raw*) (this=0x860de0,
> retp=0xbffff328, args=0xbffff1b0) at
> /Volumes/xufs/gcc-cvs/gcc/libjava/interpret.cc:2374
> 2: x/4xw 3221222188
> 0xbffff32c: 0xbffff37c 0x007d40c0 0x000a7130 0x90003dd0
> (gdb) p retp
> 5ドル = (void *) 0xbffff328
> (gdb) s
> 2: x/4xw 3221222188
> 0xbffff32c: 0x00000007 0x007d40c0 0x000a7130 0x90003dd0
> (gdb) p retp
> 6ドル = (void *) 0xbffff328
> (gdb)
>
> So 'my' pointer which gets corrupted sits @ 0xbffff32c. The retp points
> to 4 less.
Yes, but it's a DOUBLE value. Did the caller allocate enough room for
a double?
Andrew.
More information about the Java
mailing list