On 06/08/2014 09:27 PM, Cameron Kaiser wrote:
[Codegen] instruction CallGetIntrinsicValue
[Codegen] == push(immgcptr) ==
[Codegen] #label ((1068))
[Codegen] == push(imm) ==
[Codegen] 0201522c --- lis r0,913 (0x3910000)
[Codegen] 02015230 --- ori r0,r0,18768 (0x4950)
[Codegen] 02015234 --- stwu r0,-4(sp)
[Codegen] == callWithExitFrame(ion *) ==
[Codegen] == push(imm) ==
[Codegen] 02015238 --- li r0,2112 (0x840)
[Codegen] 0201523c --- stwu r0,-4(sp)
[Codegen] == call(JitCode) ==
[Codegen] 02015240 --- mfspr r0,lr
[Codegen] 02015244 --- bl .+4 << "lr = pc"
[Codegen] 02015248 --- mfspr r12,lr << get pc into r12
[Codegen] 0201524c --- mtspr lr, r0
[Codegen] 02015250 --- addi r12,r12,32 (0x20) << push pc+32
[Codegen] 02015254 --- stwu r12,-4(sp)
[Codegen] 02015258 --- x_skip_this_jump
/* x_skip_this_jump is patched by the assembler to a lis/ori/mtctr stanza to
call the VM wrapper */
[Codegen] 0201525c --- nop
[Codegen] 02015260 --- nop
[Codegen] 02015264 --- bctrl << jump to CTR
/* VM gets called and returns here */
[Codegen] ##addPendingCall offs 00000458 to 00cf1fa0
[Codegen] #label ((1128))
[Codegen] == push(reg) ==
[Codegen] 02015268 --- stwu r3,-4(sp)
[Codegen] == push(reg) ==
[Codegen] 0201526c --- stwu r4,-4(sp)
....
The return address (using these offsets) is 0x02015268. That's where it
should return to, if I understand what it's doing. By the way, it doesn't
look like I need to preserve LR and it was never saved in Baseline; it's
just here for paranoia.
Safepoint return address is here as a convenient way to index the safepoint
and to know where we can patch the code. When we have an invalidation, we
are patching 4/8 bytes of the dead code below (which is not going to be
executed once we return to this function) to register the pointer of the
IonScript.
The return address doesn't correspond to where the OsiPoint got marked -- it
gets marked way down at 0x020153cc after the CallGetIntrinsic, or way back
at 0x020527c4 with the OsiPoint/MoveGroup. So it asserts in
IonScript::getOsiIndex() because the return address doesn't match any of the
recorded OsiPoints.
Indeed, the return address inside the Safepoint (the OsiPoint return
address) should be set by the OsiPoint, and it does not correspond to the
return address of the call inside the instruction which is using the Safepoint.
The ""return address"" which is on the stack is used to find the Safepoint.
The ""return address"" which is in the Safepoint is used to locate the OsiPoint.
I would simply say that this is expected that the Safepoint does not contain
its own return address as we can use a SafePoint multiple times in one
instruction.
--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
