Closed pkujhd closed 1 year ago
need rewrite R_CALL and R_PCREL_CALL
with ASM code JMPNear(0xE9, 0x00, 0x00, 0x00, 0x00) => CALL(0xFF, 0x15, 0x00, 0x00, 0x00, 0x00) => JMPNear(0xE9, 0x00, 0x00, 0x00, 0x00)
I can't seem to reproduce with this branch... Does this new test reproduce the failure for you?
I can't seem to reproduce with this branch... Does this new test reproduce the failure for you?
This bug is probabilistic. i think golang runtime switch stack when exec 'call' instruction will lead to this panic I haven't figured out why, but use jmpnear -> far call -> jmpnear instruction can avoid it
Ah, I think the reason the x86 case was a problem was because the CALL was to a PC in the epilogue (which aimed to JMP straight into the target function).
The return PC is pushed to the stack (as the frame's "virtual" link register), but if a traceback happens while we're still in the epilogue (but before the jump), the _func
for this PC would be the original caller, and not match the actual final call target (i.e. it would look like the function called itself, because the link register _func
and current PC _func
would be the same).
Your fix is correct (to first jump to the epilogue, so LR and current PC are consistent, then to CALL to the destination directly (so LR points to the epilogue, then jump back)
on windows exec ./loader -o schedule.o -times 100 panic
log: