ports@,
kmos@ help with access to sparc64 mahcine which allow me to play with it's
build on real hardware and I really think that the cause is a bug in gcc8
(and probably future) which might be triggered by our patches.
The first things: I can bootsrap gcc11 by clang18 from ports. But I can't
bootstrap gcc11 by gcc11 from previous step.
I can bootstrap gcc8 by bootstrap-gcc as well.
Why it fails? It brokes the stack in produced cc1 binary at
var-tracking.c:936 which has the line:
static poly_int64 hard_frame_pointer_adjustment = -1;
and at gcc8 has at var-tracking.c:927 the line:
static HOST_WIDE_INT hard_frame_pointer_adjustment = -1;
Commit which changed definition was introduced at 9x
So, the crash. The stack is broken seems to be broken during the first
initialization, but after it computes the jump destination, and it works.
But on the second call the static initializytion of poly_int64 from
gcc/ipa-modref-tree.h:95 it computes jump to a wrong distation and boom.
Here an example of gdb session at the first call:
Reading symbols from /usr/ports/pobj/gcc-11.2.0/build-sparc64/gcc/cc1...
(gdb) r
Starting program: /usr/ports/pobj/gcc-11.2.0/build-sparc64/gcc/cc1
Program received signal SIGSEGV, Segmentation fault.
0x0000002590e4c378 in _ZN8poly_intILj1ExEC1IiEERKT_+0xfffffffffcbb3c94@plt ()
(gdb) disassemble
Dump of assembler code for function
_ZN8poly_intILj1ExEC1IiEERKT_+0xfffffffffcbb3c94@plt:
0x0000002590e4c368 <+0>: mov %o7, %g5
0x0000002590e4c36c <+4>: call 0x2590e4c374
<_ZN8poly_intILj1ExEC1IiEERKT_+0xfffffffffcbb3c94@plt+12>
0x0000002590e4c370 <+8>: nop
0x0000002590e4c374 <+12>: ldx [ %o7 + 0x80c ], %g1
=> 0x0000002590e4c378 <+16>: jmpl %o7 + %g1, %g1
0x0000002590e4c37c <+20>: mov %g5, %o7
End of assembler dump.
(gdb) b _ZN8poly_intILj1ExEC1IiEERKT_+0xfffffffffcbb3c94@plt
Breakpoint 1 at 0x2590e4c368
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/ports/pobj/gcc-11.2.0/build-sparc64/gcc/cc1
Breakpoint 1, 0x000000c09474c368 in
_ZN8poly_intILj1ExEC1IiEERKT_+0xfffffffffcbb3c94@plt ()
(gdb) disassemble
Dump of assembler code for function
_ZN8poly_intILj1ExEC1IiEERKT_+0xfffffffffcbb3c94@plt:
=> 0x000000c09474c368 <+0>: mov %o7, %g5
0x000000c09474c36c <+4>: call 0xc09474c374
<_ZN8poly_intILj1ExEC1IiEERKT_+0xfffffffffcbb3c94@plt+12>
0x000000c09474c370 <+8>: nop
0x000000c09474c374 <+12>: ldx [ %o7 + 0x80c ], %g1
0x000000c09474c378 <+16>: jmpl %o7 + %g1, %g1
0x000000c09474c37c <+20>: mov %g5, %o7
End of assembler dump.
(gdb) b *0x000000c09474c36c
Breakpoint 2 at 0xc09474c36c
(gdb) b *0x000000c09474c374
Breakpoint 3 at 0xc09474c374
(gdb) b *0x000000c09474c378
Breakpoint 4 at 0xc09474c378
(gdb) c
Continuing.
Breakpoint 2, 0x000000c09474c36c in
_ZN8poly_intILj1ExEC1IiEERKT_+0xfffffffffcbb3c94@plt ()
(gdb) bt
#0 0x000000c09474c36c in _ZN8poly_intILj1ExEC1IiEERKT_+0xfffffffffcbb3c94@plt
()
#1 0x000000c092869858 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535)
at /usr/ports/pobj/gcc-11.2.0/gcc-11.2.0/gcc/var-tracking.c:936
#2 0x000000c0928698bc in _GLOBAL__sub_I_attrs_pool () at
/usr/ports/pobj/gcc-11.2.0/gcc-11.2.0/gcc/var-tracking.c:10614
#3 0x000000c0913006a4 in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) c
Continuing.
Breakpoint 3, 0x000000c09474c374 in
_ZN8poly_intILj1ExEC1IiEERKT_+0xfffffffffcbb3c94@plt ()
(gdb) bt
#0 0x000000c09474c374 in _ZN8poly_intILj1ExEC1IiEERKT_+0xfffffffffcbb3c94@plt
()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
as you may see after ldx the stack from gdb point of view quite broken.
Here that -S generates for clang which works:
.Ltmp57:
sethi %hi(_GLOBAL_OFFSET_TABLE_+(.Ltmp57-.Ltmp55)), %i1
.Ltmp56:
or %i1, %lo(_GLOBAL_OFFSET_TABLE_+(.Ltmp56-.Ltmp55)), %i1
add %i1, %o7, %i1
stx %i1, [%fp+2023] ! 8-byte Folded Spill
sethi %hi(__guard_local), %i0
add %i0, %lo(__guard_local), %i0
ldx [%i1+%i0], %i0
ldx [%i0], %i2
stx %i2, [%fp+2039]
mov -1, %i2
.Ltmp58:
.loc 1 936 51 prologue_end !
gcc-11.2.0/gcc-11.2.0/gcc/var-tracking.c:936:51
st %i2, [%fp+2035]
sethi %hi(_ZL29hard_frame_pointer_adjustment), %i2
add %i2, %lo(_ZL29hard_frame_pointer_adjustment), %i2
ldx [%i1+%i2], %o0
call _ZN8poly_intILj1ExEC2IiEERKT_
add %fp, 2035, %o1
.loc 1 936 52 is_stmt 0 !
gcc-11.2.0/gcc-11.2.0/gcc/var-tracking.c:936:52
ldx [%i0], %i0
ldx [%fp+2039], %i1
cmp %i0, %i1
bne %xcc, .LBB16_2
nop
ba .LBB16_1
nop
and gcc which fails:
.loc 25 936 19
mov -1, %g1
st %g1, [%fp+2035]
add %fp, 2035, %g1
mov %g1, %o1
sethi %hi(_ZL29hard_frame_pointer_adjustment), %g1
or %g1, %lo(_ZL29hard_frame_pointer_adjustment), %g1
ldx [%i5 + %g1], %g1
mov %g1, %o0
call _ZN8poly_intILj1ExEC1IiEERKT_, 0
nop
which looks like the same things in different order.
Now I'm trying to make smaller reproducer, but it is quite tricky.
Anyway, I'd like to share with you because it may ring any bell.
Also, here the .S files:
- https://kirill.korins.ky/pub/var-tracking.clang.S.gz
- https://kirill.korins.ky/pub/var-tracking.gcc.S.gz
--
wbr, Kirill
