[Openmcl-devel] Another linux86-32: signed doubleword parameters.
Gary Byers
gb at clozure.com
Mon Oct 13 23:30:03 PDT 2008
Aha! The bits in the node-regs-mask are supposed to be ordered by the
register's "ordinal" number (e.g., the value used to encode the register
in an instruction.)
? (x86::gpr-ordinal "EAX")
0
The ordering is eax=0,ecx,edx,ebx,esp,ebp,esi,edi=7.
So why is mark_xp() treating the first 4 registers as if they were
ordered eax,ebx,ecx,edx ?
forward_xp() seems to have the same bug.
Because both mark_xp() and forward_xp() get the bit-ordering wrong,
we error in both directions: we can misidentify an immediate as
a node (and, if the immediate is tagged as a return address, crash
as we've seen) and we can misidentify a node as an immediate (which
might mean that if the register's the only reference to an object,
the object will get GCed (even though a suspended thread might be
in the act of referencing it.) If the object is otherwise referenced
and moves, a register that's pointing at it (but has its bit clear
in the node_regs_mask) won't be updated to to point to the object
at its new address. (This is something that could very easily
cause symptoms similar to the other symptom you're seeing, either
directly or after the GC's chewed things up a bit more. It's hard
to know whether this bug or something else is to blame for that,
but this bug can definitely cause similar bad things to happen.)
Assuming that I didn't botch something, this should be fixed in
r11087.
On Mon, 13 Oct 2008, David Brown wrote:
> On Mon, Oct 13, 2008 at 10:26:36PM -0600, Gary Byers wrote:
>
>> regs[REG_EDI] should contain contain the function; subtracting the
>> value regs[REG_EDI] from that of regs[EDI_EIP] should show the relative
>> offset of the program counter within that function. Doing:
>>
>> (gdb) call print_lisp_object(<value_of_regs[REG_EDI])
>>
>> will try (using the kernel debugger's imperfect but sometimes useful)
>> lisp-object printer. ("call" in gdb sometimes gets confused but often
>> works)
>
> (gdb) call print_lisp_object(0x1400a71e)
> $4 = 0x807a640 "#<Function %COPY-IVECTOR-TO-IVECTOR #x1400A71E>"
> (gdb) p regs[14] - regs[4]
> $5 = 59
>
> The interesting part is that the code looks like it is marking temp1
> as immediate, so seems fine.
>
> Let me know if you want me to poke into anything else.
>
> CL-USER> (disassemble 'ccl::%copy-ivector-to-ivector)
> (recover-fn)
> (movl (@ 12 (% esp)) (% temp0)) ;[5]
> (movl (@ 8 (% esp)) (% temp1)) ;[9]
> (movl (% arg_z) (% imm0)) ;[13]
> (sarl ($ 2) (% imm0)) ;[15]
> (pushl (% arg_z)) ;[18]
> (movl (@ 8 (% esp)) (% arg_z)) ;[19]
> (andb ($ 251) (@ (% fs) 8)) ;[23]
> (andb ($ 191) (@ (% fs) 8)) ;[32]
> (sarl ($ 2) (% temp1)) ;[41]
> (sarl ($ 2) (% arg_y)) ;[44]
> (cmpl (% arg_z) (% temp0)) ;[47]
> (jne L55) ;[49]
> (cmpl (% temp1) (% arg_y)) ;[51]
> (jg L77) ;[53]
> L55
> (testl (% imm0) (% imm0))
> (jmp L73) ;[57]
> L59
> (movb (@ -2 (% temp0) (% temp1)) (% imm0.b))
> (movb (% imm0.b) (@ -2 (% arg_z) (% arg_y))) ;[63]
> (incl (% temp1)) ;[67]
> (incl (% arg_y)) ;[68]
> (subl ($ 4) (@ (% esp))) ;[69]
> L73
> (jne L59)
> (jmp L101) ;[75]
> L77
> (addl (% imm0) (% temp1))
> (addl (% imm0) (% arg_y)) ;[79]
> (testl (% imm0) (% imm0)) ;[81]
> (jmp L99) ;[83]
> L85
> (decl (% temp1))
> (decl (% arg_y)) ;[86]
> (movb (@ -2 (% temp0) (% temp1)) (% imm0.b)) ;[87]
> (movb (% imm0.b) (@ -2 (% arg_z) (% arg_y))) ;[91]
> (subl ($ 4) (@ (% esp))) ;[95]
> L99
> (jne L85)
> L101
> (addl ($ 4) (% esp))
> (xorl (% temp1) (% temp1)) ;[104]
> (orb ($ 4) (@ (% fs) 8)) ;[106]
> (xorl (% arg_y) (% arg_y)) ;[115]
> (orb ($ 64) (@ (% fs) 8)) ;[117]
> (retl ($ 20)) ;[126]
> David
>
>
More information about the Openmcl-devel
mailing list