[pypy-dev] PPC64 backend compile_framework_7_interior failure

[David Edelsohn]

Armin, et al,

compile_framework_7_interior in test_zrpy_gc fails for the PPC64
backend in a strange way.  Identical problems happen on the public
system and my private system, but GDB on the public system is not
permitting hardware watchpoints, so it is more difficult to catch the
cause of the failure.

The testcase segfaults in a load following the instructions generated
for getinteriorfield_gc:

   0xfffb74e1958:	li      r3,0
   0xfffb74e195c:	li      r0,24
   0xfffb74e1960:	mullw   r0,r3,r0
   0xfffb74e1964:	addic   r0,r0,16
   0xfffb74e1968:	ldx     r3,r30,r0    ; $r30 + $r0 = 0xfffb75ea030
=> 0xfffb74e196c:	ld      r3,8(r3)      ; $r3 = 904

The ldx is the load from getinteriorfield_gc and the subsequent load fails.

"904" appears to correspond to "n + i * 100 + ..." in the testcase for i = 9.

If I set a watchpoint on the address, it initially is written during
memcpy of a minor collection:

#0  0x00000fffb7d0daa0 in .memcpy () from /lib64/power7/libc.so.6
#1  0x000000001000fb0c in .pypy_g_trace___trace_drag_out ()
#2  0x0000000010014288 in .pypy_g_MiniMarkGC_collect_oldrefs_to_nursery ()
#3  0x0000000010015358 in .pypy_g_MiniMarkGC_minor_collection.part.0 ()
#4  0x000000001001ce04 in .pypy_g_MiniMarkGC_collect ()

at which point

(gdb) x/gx 0xfffb75ea030
0xfffb75ea030:	0x00000fffb776c170
(gdb) x/gd 0x00000fffb776c170
0xfffb776c170:	904

In other words, the location contains a pointer to another location
containing the value "904".

The value at that location later is overwritten in jitted code:

   0xfffb74e0dec:	li      r28,0
   0xfffb74e0df0: 	li      r0,24
   0xfffb74e0df4: 	mullw   r0,r28,r0
   0xfffb74e0df8: 	addic   r0,r0,16
   0xfffb74e0dfc: 	stdx    r3,r30,r0
   0xfffb74e0e14:	li      r4,16
   0xfffb74e0e18:	add     r4,r3,r4
   0xfffb74e0e1c:	li      r3,904
   0xfffb74e0e20:	std     r3,0(r4)   ; $r4 = 0xfffb75ea030

(gdb) print/x $r4
$6 = 0xfffb75ea030

$r3 is stored as part of a setinteriorfield_gc sequence.  Subsequently
$r3+16 is used as an address to store "904".  So now that location
instead of containing a pointer to the value "904" has been
overwritten with the value "904", which fails when it later is
accessed.

I don't know if this flattening is intentional and the code reading
the value was not updated to compensate for some sort of unboxing or
one level of indirection has been lost.  Any guidance to help debug
this would be appreciated.

Thanks, David