[Bug libstdc++/106581] New: [Aarch64] libstdc++ segfault at end of execution

[Bug libstdc++/106581] New: [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com]

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

            Bug ID: 106581
           Summary: [Aarch64] libstdc++ segfault at end of execution
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lancethepants at gmail dot com
  Target Milestone: ---

aarch64
linux 4.1.51
GCC 12.1
uclibc-ng 1.0.41

All dynamically linked c++ executables will segfault.  Some executables will
run then segfault, some just segfault.  I think there are couple segfaulting
issues, but this is the first one to address I think. GCC 10 & 11 don't
segfault at the end of execution if they don't segfault for some other reason. 
Static linked binaries don't segfault at the end of execution using either
'-static' for fully static binary or '-static-libstdc++' to static link just
libstdc++.

Here is a backtrace of segfaulting 'hello world' c++ binary

admin@RT-AX88U-6860:~/src/hello.src# /opt/bin/gdb ./hello
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-openwrt-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello...
(gdb) run
Starting program: /mmc/src/hello.src/hello
warning: Unable to determine the number of hardware watchpoints available.
warning: Unable to determine the number of hardware breakpoints available.
warning: File "/mmc/lib/libthread_db-1.0.41.so" auto-loading has been declined
by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /mmc/lib/libthread_db-1.0.41.so
line to your configuration file "/mmc/.config/gdb/gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/mmc/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
warning: Unable to find libthread_db matching inferior's thread library, thread
debugging will not be available.
Hello, World from C++!

Program received signal SIGSEGV, Segmentation fault.
std::uncaught_exception () at
../../../../libstdc++-v3/libsupc++/eh_catch.cc:141
141     ../../../../libstdc++-v3/libsupc++/eh_catch.cc: No such file or
directory.
(gdb) backtrace
#0  std::uncaught_exception () at
../../../../libstdc++-v3/libsupc++/eh_catch.cc:141
#1  0x0000007fb7f0bd30 in std::ostream::sentry::~sentry (this=0x7ffffff340,
__in_chrg=<optimized out>)
    at
/home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-12.1.0/build/aarch64-tomatoware-linux-uclibc/libstdc++-v3/include/ostream:466
#2  0x0000007fb7f0bde4 in std::ostream::flush (this=0x7fb7fe4f48 <std::cerr>)
    at
/home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-12.1.0/build/aarch64-tomatoware-linux-uclibc/libstdc++-v3/include/bits/ostream.tcc:245
#3  0x0000007fb7ebbc40 in std::ios_base::Init::~Init (this=<optimized out>,
__in_chrg=<optimized out>) at
../../../../../libstdc++-v3/src/c++98/ios_init.cc:135
#4  0x0000007fb7d401b8 in __exit_handler (status=0) at
libc/stdlib/_atexit.c:263
#5  0x0000007fb7d402b8 in __GI_exit (rv=0) at libc/stdlib/_atexit.c:301
#6  0x0000007fb7d46134 in __uClibc_main (main=0x55555559d4 <main()>, argc=1,
argv=0x7ffffff598, app_init=0x55555557d8 <_init>, app_fini=0x5555555a78
<_fini>, rtld_fini=0x7fb7fe94f0 <_dl_fini>, stack_end=0x7ffffff590)
    at libc/misc/internals/__uClibc_main.c:552
#7  0x00000055555558c4 in _start () at libc/sysdeps/linux/aarch64/crt1.S:92
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2022-08-10
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This could be a bug in uclibc and TLS.

The crash is related to TLS of:
  abi::__cxa_eh_globals*
  get_global() _GLIBCXX_NOTHROW
  {
    static __thread abi::__cxa_eh_globals global;
    return &global;
  }

Can you provide the disassemble std::uncaught_exception of where the crash is
located?
just do "disassemble" in gdb.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com]

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

--- Comment #2 from Lance Fredrickson <lancethepants at gmail dot com> ---
Here is the disassemble

(gdb) disassemble
Dump of assembler code for function _ZSt18uncaught_exceptionv:
   0x0000007fb7eae2a8 <+0>:     stp     x29, x30, [sp, #-16]!
   0x0000007fb7eae2ac <+4>:     mov     x29, sp
   0x0000007fb7eae2b0 <+8>:     bl      0x7fb7ea8dd0 <__cxa_get_globals@plt>
=> 0x0000007fb7eae2b4 <+12>:    ldr     w0, [x0, #8]
   0x0000007fb7eae2b8 <+16>:    cmp     w0, #0x0
   0x0000007fb7eae2bc <+20>:    cset    w0, ne  // ne = any
   0x0000007fb7eae2c0 <+24>:    ldp     x29, x30, [sp], #16
   0x0000007fb7eae2c4 <+28>:    ret
End of assembler dump.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Lance Fredrickson from comment #2)
> Here is the disassemble
> 
> (gdb) disassemble
> Dump of assembler code for function _ZSt18uncaught_exceptionv:
>    0x0000007fb7eae2a8 <+0>:     stp     x29, x30, [sp, #-16]!
>    0x0000007fb7eae2ac <+4>:     mov     x29, sp
>    0x0000007fb7eae2b0 <+8>:     bl      0x7fb7ea8dd0 <__cxa_get_globals@plt>
> => 0x0000007fb7eae2b4 <+12>:    ldr     w0, [x0, #8]
>    0x0000007fb7eae2b8 <+16>:    cmp     w0, #0x0
>    0x0000007fb7eae2bc <+20>:    cset    w0, ne  // ne = any
>    0x0000007fb7eae2c0 <+24>:    ldp     x29, x30, [sp], #16
>    0x0000007fb7eae2c4 <+28>:    ret
> End of assembler dump.

"info registers"

What is the value of x0 at this point?

Can you also do "disassemble __cxa_get_globals"?

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com]

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

--- Comment #4 from Lance Fredrickson <lancethepants at gmail dot com> ---
Here you go.

(gdb) info registers
x0             0xff6fea06f0        1097094268656
x1             0x7fb7ffa6c0        548547831488
x2             0x0                 0
x3             0x0                 0
x4             0x5555555a9f        366503877279
x5             0x7fb7dc2d5f        548545506655
x6             0x57202c6f6c6c6548  6278066737626506568
x7             0x6f726620646c726f  8030593374864831087
x8             0x40                64
x9             0x7fb7ffccb0        548547841200
x10            0x7fb7e13090        548545835152
x11            0x1                 1
x12            0x18                24
x13            0x7fb7ffccc0        548547841216
x14            0x7fb7ffc2d0        548547838672
x15            0x1                 1
x16            0x7fb7eae3f4        548546470900
x17            0x7fb7fe26a8        548547733160
x18            0x0                 0
x19            0x7fb7fe4f50        548547743568
x20            0x7ffffff330        549755810608
x21            0x5555555890        366503876752
x22            0x0                 0
x23            0x0                 0
x24            0x0                 0
x25            0x0                 0
x26            0x0                 0
x27            0x0                 0
x28            0x0                 0
x29            0x7ffffff2e0        549755810528
x30            0x7fb7eae2b4        548546470580
sp             0x7ffffff2e0        0x7ffffff2e0
pc             0x7fb7eae2b4        0x7fb7eae2b4 <std::uncaught_exception()+12>
cpsr           0x80000000          [ EL=0 N ]
fpsr           0x0                 [ ]
fpcr           0x0                 [ RMode=0 ]


(gdb) disassemble __cxa_get_globals
Dump of assembler code for function __cxxabiv1::__cxa_get_globals():
   0x0000007fb7eae3f4 <+0>:     stp     x29, x30, [sp, #-16]!
   0x0000007fb7eae3f8 <+4>:     mov     x29, sp
   0x0000007fb7eae3fc <+8>:     bl      0x7fb7eae3b8 <(anonymous
namespace)::get_global()>
   0x0000007fb7eae400 <+12>:    ldp     x29, x30, [sp], #16
   0x0000007fb7eae404 <+16>:    ret
End of assembler dump.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
uclibc must have some ordering issue when it comes to atexit and shared
libraries and TLS.

Can you also do:
"info mem"

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com]

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

--- Comment #6 from Lance Fredrickson <lancethepants at gmail dot com> ---
info mem gives

(gdb) info mem
Using memory regions provided by the target.
There are no memory regions defined.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Lance Fredrickson from comment #6)
> info mem gives
> 
> (gdb) info mem
> Using memory regions provided by the target.
> There are no memory regions defined.

Sorry, I mean "info proc mappings"

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com]

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

--- Comment #8 from Lance Fredrickson <lancethepants at gmail dot com> ---
Here is 'info proc mappings'

(gdb) info proc mappings
process 16896
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
        0x5555555000       0x5555556000     0x1000        0x0
/mmc/src/hello.src/hello
        0x5555565000       0x5555566000     0x1000        0x0
/mmc/src/hello.src/hello
        0x5555566000       0x5555567000     0x1000     0x1000
/mmc/src/hello.src/hello
        0x5555567000       0x5555579000    0x12000        0x0 [heap]
        0x7fb7c9f000       0x7fb7db0000   0x111000        0x0
/mmc/lib/libuClibc-1.0.41.so
        0x7fb7db0000       0x7fb7dc0000    0x10000        0x0
        0x7fb7dc0000       0x7fb7dc1000     0x1000   0x111000
/mmc/lib/libuClibc-1.0.41.so
        0x7fb7dc1000       0x7fb7dc2000     0x1000   0x112000
/mmc/lib/libuClibc-1.0.41.so
        0x7fb7dc2000       0x7fb7ddc000    0x1a000        0x0
        0x7fb7ddc000       0x7fb7df0000    0x14000        0x0
/mmc/lib/libgcc_s.so.1
        0x7fb7df0000       0x7fb7e00000    0x10000        0x0
        0x7fb7e00000       0x7fb7e01000     0x1000    0x14000
/mmc/lib/libgcc_s.so.1
        0x7fb7e01000       0x7fb7e02000     0x1000    0x15000
/mmc/lib/libgcc_s.so.1
        0x7fb7e02000       0x7fb7fc6000   0x1c4000        0x0
/mmc/usr/lib/libstdc++.so.6.0.30
        0x7fb7fc6000       0x7fb7fd6000    0x10000        0x0
        0x7fb7fd6000       0x7fb7fe1000     0xb000   0x1c4000
/mmc/usr/lib/libstdc++.so.6.0.30
        0x7fb7fe1000       0x7fb7fe4000     0x3000   0x1cf000
/mmc/usr/lib/libstdc++.so.6.0.30
        0x7fb7fe4000       0x7fb7fe8000     0x4000        0x0
        0x7fb7fe8000       0x7fb7ff0000     0x8000        0x0
/mmc/lib/ld-uClibc-1.0.41.so
        0x7fb7ffa000       0x7fb7ffd000     0x3000        0x0
        0x7fb7ffd000       0x7fb7ffe000     0x1000        0x0 [vvar]
        0x7fb7ffe000       0x7fb7fff000     0x1000        0x0 [vdso]
        0x7fb7fff000       0x7fb8000000     0x1000     0x7000
/mmc/lib/ld-uClibc-1.0.41.so
        0x7fb8000000       0x7fb8001000     0x1000     0x8000
/mmc/lib/ld-uClibc-1.0.41.so
        0x7ffffdf000       0x8000000000    0x21000        0x0 [stack]

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
disassemble 0x7fb7eae3b8
Which was:
   0x0000007fb7eae3fc <+8>:     bl      0x7fb7eae3b8 <(anonymous
namespace)::get_global()>

I am still trying to figure out how the TLS address was formed here.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com]

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

--- Comment #10 from Lance Fredrickson <lancethepants at gmail dot com> ---
(gdb) disassemble 0x7fb7eae3b8
Dump of assembler code for function (anonymous namespace)::get_global():
   0x0000007fb7eae3b8 <+0>:     stp     x29, x30, [sp, #-16]!
   0x0000007fb7eae3bc <+4>:     mov     x29, sp
   0x0000007fb7eae3c0 <+8>:     adrp    x0, 0x7fb7fe3000
<_ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE15_M_update_egptrEv@got.plt>
   0x0000007fb7eae3c4 <+12>:    ldr     x1, [x0, #3248]
   0x0000007fb7eae3c8 <+16>:    add     x0, x0, #0xcb0
   0x0000007fb7eae3cc <+20>:    blr     x1
   0x0000007fb7eae3d0 <+24>:    mrs     x1, tpidr_el0
   0x0000007fb7eae3d4 <+28>:    add     x0, x1, x0
   0x0000007fb7eae3d8 <+32>:    ldp     x29, x30, [sp], #16
   0x0000007fb7eae3dc <+36>:    ret
End of assembler dump.

[Bug target/106581] [Aarch64] libstdc++ segfault at end of execution

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
          Component|libstdc++                   |target

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Lance Fredrickson from comment #10)
> (gdb) disassemble 0x7fb7eae3b8
> Dump of assembler code for function (anonymous namespace)::get_global():
>    0x0000007fb7eae3b8 <+0>:     stp     x29, x30, [sp, #-16]!
>    0x0000007fb7eae3bc <+4>:     mov     x29, sp
>    0x0000007fb7eae3c0 <+8>:     adrp    x0, 0x7fb7fe3000
> <_ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE15_M_update_egptrEv@got.plt>
>    0x0000007fb7eae3c4 <+12>:    ldr     x1, [x0, #3248]
>    0x0000007fb7eae3c8 <+16>:    add     x0, x0, #0xcb0
>    0x0000007fb7eae3cc <+20>:    blr     x1
>    0x0000007fb7eae3d0 <+24>:    mrs     x1, tpidr_el0
>    0x0000007fb7eae3d4 <+28>:    add     x0, x1, x0
>    0x0000007fb7eae3d8 <+32>:    ldp     x29, x30, [sp], #16
>    0x0000007fb7eae3dc <+36>:    ret
> End of assembler dump.

That looks correct.
It is basically:

        adrp    x0, :tlsdesc:a
        ldr     x1, [x0, #:tlsdesc_lo12:a]
        add     x0, x0, :tlsdesc_lo12:a
        .tlsdesccall    a
        blr     x1
        mrs     x1, tpidr_el0
        add     x0, x1, x0


So now this is looking more and more like an uclibc issue rather a
GCC/libstdc++ one.
Have you reported it to them yet?

[Bug target/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com]

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

--- Comment #12 from Lance Fredrickson <lancethepants at gmail dot com> ---
I will send an email to their mailing list and inform them of this thread as
well. I've queried on buildroot mailing list and irc if anyone uses aarch64 +
uclibc-ng.

thanks for your attention and troubleshooting!

[Bug target/106581] [Aarch64] libstdc++ segfault at end of execution

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |MOVED

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
https://www.mail-archive.com/devel@uclibc-ng.org/msg00953.html
https://www.mail-archive.com/devel@uclibc-ng.org/msg00871.html


Your mail:
https://www.mail-archive.com/devel@uclibc-ng.org/msg01204.html


hmm:
https://www.mail-archive.com/devel@uclibc-ng.org/msg01104.html

Yes so I think this is a uclibc issue as first 2 links show. So resolving as
moved.