https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
--- Comment #5 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
(In reply to Ian Lance Taylor from comment #4)
> There don't seem to be any sparc64-linux machines in the GCC compile farm,
> so I can't recreate this myself.
>
> Are you able to recreate the problem while running under gdb? A backtrace
> from the point of the signal might help. The stack backtraces you included
> unfortunately don't tell me anything useful. Thanks.
For some reason despite compiling with debug symbols I can't seem to get gdb to
recognize the symbol table, all I get is:
$ GOMAXPROCS=1 CGO_ENABLED=1 GO111MODULE=on gdb -q --args /usr/bin/go-11 build
Reading symbols from /usr/bin/go-11...
(gdb) r
Starting program: /usr/bin/go-11 build
[New LWP 51735]
[New LWP 51736]
Thread 1 "go-11" received signal SIGSEGV, Segmentation fault.
0xfff80001010c11ac in ?? ()
(gdb) bt full
#0 0xfff80001010c11ac in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
$ file -L /usr/bin/go-11
/usr/bin/go-11: ELF 64-bit MSB pie executable, SPARC V9, relaxed memory
ordering, version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped
$ ldd /usr/bin/go-11
linux-vdso.so.1 (0xfff8000100680000)
libgo.so.19 =>
/usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/libgo.so.19 (0xfff8000100684000)
libm.so.6 => /lib64/libm.so.6 (0xfff80001020c0000)
libc.so.6 => /lib64/libc.so.6 (0xfff8000102278000)
libgcc_s.so.1 =>
/usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/libgcc_s.so.1
(0xfff8000102508000)
/lib64/ld-linux.so.2 (0xfff8000100000000)
$ file -L /usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/libgo.so.19
/usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/libgo.so.19: ELF 64-bit MSB
shared object, SPARC V9, relaxed memory ordering, version 1 (SYSV), dynamically
linked, with debug_info, not stripped
$ readelf -S /usr/bin/go-11 | grep -i "debug"
[27] .debug_aranges PROGBITS 0000000000000000 005ad1e6
[28] .debug_info PROGBITS 0000000000000000 005ade86
[29] .debug_abbrev PROGBITS 0000000000000000 0075e02a
[30] .debug_line PROGBITS 0000000000000000 00772a5a
[31] .debug_frame PROGBITS 0000000000000000 007f5b20
[32] .debug_str PROGBITS 0000000000000000 007f5b70
[33] .debug_line_str PROGBITS 0000000000000000 00846a06
[34] .debug_loclists PROGBITS 0000000000000000 0084adc8
[35] .debug_rnglists PROGBITS 0000000000000000 0094e386
I am able to provide ssh access to the live system on which this is occurring -
would that be helpful or is that not really something you prefer to do in the
course of debugging?
