[Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64

[Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64

[matoro_gcc_bugzilla at matoro dot tk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847

            Bug ID: 103847
           Summary: gccgo SIGSEGV in libgo standard library on sparc64
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: matoro_gcc_bugzilla at matoro dot tk
                CC: cmang at google dot com
  Target Milestone: ---

$ go version
go version go1.16.5 gccgo (Gentoo 11.2.1_p20211127 p2) 11.2.1 20211127
linux/sparc64

$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-unknown-linux-gnu/11.2.1/lto-wrapper
Target: sparc64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/configure
--host=sparc64-unknown-linux-gnu --build=sparc64-unknown-linux-gnu
--prefix=/usr --bindir=/usr/sparc64-unknown-linux-gnu/gcc-bin/11.2.1
--includedir=/usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/include
--datadir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/11.2.1
--mandir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/11.2.1/man
--infodir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/11.2.1/info
--with-gxx-include-dir=/usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/include/g++-v11
--with-python-dir=/share/gcc-data/sparc64-unknown-linux-gnu/11.2.1/python
--enable-languages=c,c++,go --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
11.2.1_p20211127 p2' --disable-esp --enable-libstdcxx-time
--with-build-config=bootstrap-lto --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp
--disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --with-isl --disable-isl-version-check
--enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.1 20211127 (Gentoo 11.2.1_p20211127 p2) 

$ uname -a
Linux 5.15.11-gentoo-sparc64 #1 SMP sparc64 sun4v UltraSparc T4 (Niagara4)
GNU/Linux


I am attempting to build a simple go application using gccgo on this sparc64
host, but keep getting compiler SEGV inside the libgo standard library.  This
is happening for pretty much all commands except for simple version checks.

When trying to build from a fresh clone, the crash seem to be in network
related code as dependencies are pulled down.

When trying to build in an environment where dependencies are pre-downloaded,
the crash seems to be in semaphore synchronization.

Both runs were done with GOMAXPROCS=1 in order to make the traceback logs
deterministic.  I also attempted to bootstrap the gc compiler using gcc, but
got the same results.  I've attached the crash logs from the two different
types of builds I attempted as build-with-network.log and
build-without-network.log, respectively.

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

[matoro_gcc_bugzilla at matoro dot tk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847

matoro <matoro_gcc_bugzilla at matoro dot tk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matoro_gcc_bugzilla@matoro.
                   |                            |tk

--- Comment #1 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
Created attachment 52072
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52072&action=edit
build-with-network.log

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

[matoro_gcc_bugzilla at matoro dot tk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847

--- Comment #2 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
Created attachment 52073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52073&action=edit
build-without-network.log

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

[matoro_gcc_bugzilla at matoro dot tk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847

--- Comment #3 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
Oh, and just for reference, I did confirm that these crashes do not occur on
amd64.

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847

--- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
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.

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

[matoro_gcc_bugzilla at matoro dot tk]

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?

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847

--- Comment #6 from Ian Lance Taylor <ian at airs dot com> ---
I can try debugging it with ssh access.  I'll want to build my own copy of
gccgo.  Let me know where I should send the public key.  Thanks.

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

[matoro_gcc_bugzilla at matoro dot tk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847

--- Comment #7 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
(In reply to Ian Lance Taylor from comment #6)
> I can try debugging it with ssh access.  I'll want to build my own copy of
> gccgo.  Let me know where I should send the public key.  Thanks.

matoro_gcc_bugzilla <at> matoro <dot> tk

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Ian Lance Taylor <ian@gcc.gnu.org>:

https://gcc.gnu.org/g:62c3f75fd29e93054f3aeb8a623fd52c98c3db0b

commit r12-6147-g62c3f75fd29e93054f3aeb8a623fd52c98c3db0b
Author: Ian Lance Taylor <iant@golang.org>
Date:   Wed Dec 29 15:08:32 2021 -0800

    compiler, libgo: don't pad sparc64-linux epollevent

    Change the compiler to not add zero padding because of zero-sized
    fields named "_", since those can't be referenced anyhow.

    Change the sparc-linux64 epollevent struct to name the alignment
    field "_", to avoid zero padding.

    Fixes PR go/103847

            PR go/103847
            * godump.c (go_force_record_alignment): Name the alignment
            field "_".

    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/374914

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #9 from Ian Lance Taylor <ian at airs dot com> ---
This should be fixed on tip.  Thanks for reporting it.

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:7918d8270a43e42b0cba902ec17ce87b6a3c74a9

commit r12-6163-g7918d8270a43e42b0cba902ec17ce87b6a3c74a9
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Jan 1 06:30:39 2022 +0100

    testsuite: Adjust gcc.misc-tests/godump-1.c testcase

    On Wed, Dec 29, 2021 at 03:54:03PM -0800, Ian Lance Taylor via Gcc-patches
wrote:
    > PR go/103847
    > * godump.c (go_force_record_alignment): Name the alignment
    > field "_".

    > --- a/gcc/godump.c
    > +++ b/gcc/godump.c
    > @@ -651,7 +651,7 @@ go_force_record_alignment (struct obstack *ob, const
char *type_string,
    >                          unsigned int index, const char *error_string)
    >  {
    >    index = go_append_artificial_name (ob, index);
    > -  obstack_grow (ob, "_align ", 7);
    > +  obstack_grow (ob, "_ ", 2);
    >    if (type_string == NULL)
    >      obstack_grow (ob, error_string, strlen (error_string));
    >    else

    This change caused
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _ts_nested struct { u
struct { s int16; Godump_0_pad \\\\[2\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int32; }; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _ts_nested2 struct { u
struct { Godump_0_pad \\\\[4\\\\]byte; Godump_1_pad \\\\[2\\\\]byte; s int16; c
int8; Godump_2_pad
    +\\\\[1\\\\]byte; Godump_3_pad \\\\[2\\\\]byte; Godump_4_align
\\\\[0\\\\]u?int32; }; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_gaps struct {
bf1 uint8; c uint8; bf2 uint8; Godump_0_pad \\\\[2\\\\]byte; s uint16;
Godump_1_align \\\\[0\\\\]int32; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad16_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_align \\\\[0\\\\]int16; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad16_2 struct {
Godump_0_pad \\\\[2\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int16; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad32_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int32; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad32_2 struct {
Godump_0_pad \\\\[4\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int32; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad64_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int64; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad64_2 struct {
Godump_0_pad \\\\[8\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int64; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsn_anon struct { a
uint8; s uint16; b uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]int16; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsu_anon struct { c
uint8; Godump_0_pad \\\\[7\\\\]byte; Godump_1_align \\\\[0\\\\]u?int64; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu1 struct { c uint8;
Godump_0_pad \\\\[.\\\\]byte; Godump_1_align \\\\[0\\\\]u?int64; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu3_size struct { ca
\\\\[4\\\\+1\\\\]uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int64; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu_nested struct { u
struct { s int16; Godump_0_pad \\\\[2\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int32; }; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu_nested2 struct { u
struct { Godump_0_pad \\\\[4\\\\]byte; Godump_1_pad \\\\[2\\\\]byte; s int16; c
int8; Godump_2_pad
    +\\\\[1\\\\]byte; Godump_3_pad \\\\[2\\\\]byte; Godump_4_align
\\\\[0\\\\]u?int32; }; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu_size struct { ca
\\\\[4\\\\+1\\\\]uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int64; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _s_nested struct { u
struct { s int16; Godump_0_pad \\\\[2\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int32; }; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _s_nested2 struct { u
struct { Godump_0_pad \\\\[4\\\\]byte; Godump_1_pad \\\\[2\\\\]byte; s int16; c
int8; Godump_2_pad
    +\\\\[1\\\\]byte; Godump_3_pad \\\\[2\\\\]byte; Godump_4_align
\\\\[0\\\\]u?int32; }; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_gaps struct { bf1
uint8; c uint8; bf2 uint8; Godump_0_pad \\\\[2\\\\]byte; s uint16;
Godump_1_align \\\\[0\\\\]int32; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad16_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_align \\\\[0\\\\]int16; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad16_2 struct {
Godump_0_pad \\\\[2\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int16; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad32_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int32; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad32_2 struct {
Godump_0_pad \\\\[4\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int32; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad64_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int64; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad64_2 struct {
Godump_0_pad \\\\[8\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int64; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sn_anon struct { a
uint8; s uint16; b uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]int16; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _su_anon struct { c
uint8; Godump_0_pad \\\\[7\\\\]byte; Godump_1_align \\\\[0\\\\]u?int64; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u1 struct { c uint8;
Godump_0_pad \\\\[.\\\\]byte; Godump_1_align \\\\[0\\\\]u?int64; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u3_size struct { ca
\\\\[4\\\\+1\\\\]uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int64; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u_nested struct { u
struct { s int16; Godump_0_pad \\\\[2\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int32; }; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u_nested2 struct { u
struct { Godump_0_pad \\\\[4\\\\]byte; Godump_1_pad \\\\[2\\\\]byte; s int16; c
int8; Godump_2_pad
    +\\\\[1\\\\]byte; Godump_3_pad \\\\[2\\\\]byte; Godump_4_align
\\\\[0\\\\]u?int32; }; }\$
    +FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u_size struct { ca
\\\\[4\\\\+1\\\\]uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int64; }\$
    on x86_64-linux.

    The following patch adjusts the testcase for the above change.

    2022-01-01  Jakub Jelinek  <jakub@redhat.com>

            * gcc.misc-tests/godump-1.c: Adjust for renaming of last
            field from _align suffix to _ suffix.

[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0