This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: interpreter question, darwin libffi


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]