On 2011/01/19 06:19:44, zaheer wrote:
Thanks serya for comments. I checked this patch with a moving stub test
and it
seems to work. details below.
On 2011/01/18 19:01:57, SeRya wrote:
>
http://codereview.chromium.org/6170001/diff/44002/src/arm/macro-assembler-arm.cc
> File src/arm/macro-assembler-arm.cc (right):
>
>
http://codereview.chromium.org/6170001/diff/44002/src/arm/macro-assembler-arm.cc#newcode1478
> src/arm/macro-assembler-arm.cc:1478: Call(function->address(),
> RelocInfo::RUNTIME_ENTRY);
> This will be translated into
> mov(lr, Operand(pc), LeaveCC, cond);
> mov(pc, Operand(target), LeaveCC, cond);
> (or equivalent with blx).
>
> The register is unreachable for GC which needs to fix the return
address if
the
> code has been moved, isn't it?
The first instruction in the native callback pushes the lr in the first
stack
slot. I point the exit frame pc to it and it gets patched.
callback is native callback
(gdb) bt
#0 callback (args=@0xbec33bb8) at external/v8/v8_latest/directcall.cc:59
#1 0x4087d0b0 in ?? ()
The first instruction pushes lr which is pointed to by exit frame pc
Dump of assembler code for function _Z8callbackRKN2v89ArgumentsE:
0x0001d9ac <_Z8callbackRKN2v89ArgumentsE+0>: push {r4, r5, r6, lr}
(gdb) x/4x $sp
0xbec33ba8: 0x001ac80c 0x001ad6b8 0x00000003 0x4087d0b0 (lr)
GC moves the stub
forward 0x4087cfc0 -> 0x4087cc40.
lr is patched
(gdb) x/4x 0xbec33ba8
0xbec33ba8: 0x001ac80c 0x001ad6b8 0x00000003 0x4087cd30
(patched)
(gdb) bt
#0 0x0001d9e0 in callback (args=<value optimized out>) at
external/v8/v8_latest/directcall.cc:68
#1 0x4087cd30 in ?? () --> modified return address
native function uses modified lr to return
0x0001d9e0 <_Z8callbackRKN2v89ArgumentsE+52>: pop {r4, r5, r6, pc}
I can't find a place in ARM ABI docs what would require this behavior. Is
this a
compiler specific stuff? If so it's not a good idea to rely on it.
> Apparently the only way to survive code relocation is to make the lr
register
to
> point to an unmovable piece of code.
in this case how do we return to a moving stub?
I actually see 2 ways to deal with it (it only make sense if the stuff
above is
really compiler specific):
a.
1. Push return address on stack (it will make it accessible to GC).
2. Set up the lr register pointing to the "pop pc" instruction
in unmovable code.
b.
1. Make the rest of code above
Call(function->address(), RelocInfo::RUNTIME_ENTRY);
to be unmovable.
Apparently it doesn't depend on args.
2. Put a pointer to that code to lr.
3. Jump to the C function.
The second approach would share some piece of code and probably faster. But
I'm
afraid there is no good method to make a code unmovable for now. In other
case
there wouldble be such a comment in CEntryStub::Generate:
// TODO(1242173): To let the GC traverse the return address of the exit
// frames, we need to know where the return address is. Right now,
// we push it on the stack to be able to find it again, but we never
// restore from it in case of changes, which makes it impossible to
// support moving the C entry code stub. This should be fixed, but
currently
// this is OK because the CEntryStub gets generated so early in the V8
boot
// sequence that it is not moving ever.
http://codereview.chromium.org/6170001/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
