[Bug libstdc++/105880] New: eh_globals_init destructor not setting _M_init to false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
Bug ID: 105880
Summary: eh_globals_init destructor not setting _M_init to
false
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: chrisj at rtems dot org
Target Milestone: ---
RTEMS 6 with GCC 12 (gcc version 12.1.1 20220509 (RTEMS 6, RSB
e73a258a3aa4af8735b589a2d770571b2105ac5f, Newlib 64b2081) (GCC)) is calling
`std::terminate()` in `__cxa_get_globals()`. The `_M_init` value is `true`
after the static destructor has run.
RTEMS is tracking the issue with https://devel.rtems.org/ticket/4661.
When `exit()` is called the static destructor for `eh_gloabls init` runs and
deletes the POSIX key however the `_M_init` variable is not set to false.
Later `__cxxabiv1::__cxa_get_globals()` is called and sees `_M_init` is `true`
so attempts to get the POSIX key value. This fails because the key has been
deleted so `NULL` is returned. Memory is allocated and the set fails because
there is no key so `std::terminate()` is called.
The issue is `init._M_init` is not set to false in the static destructor. The
code for aarch64 and arm is:
006562e0 <__eh_globals_init::~__eh_globals_init()>:
6562e0: 7903ldrbr3, [r0, #4]
6562e2: b510push{r4, lr}
6562e4: 4604mov r4, r0
6562e6: b90bcbnzr3, 6562ec
<__eh_globals_init::~__eh_globals_init()+0xc>
6562e8: 4620mov r0, r4
6562ea: bd10pop {r4, pc}
6562ec: 6800ldr r0, [r0, #0]
6562ee: f04d fe6b bl 6a3fc8
6562f2: 4620mov r0, r4
6562f4: bd10pop {r4, pc}
10222c30 <__eh_globals_init::~__eh_globals_init()>:
10222c30: 39401001ldrbw1, [x0, #4]
10222c34: 3541cbnzw1, 10222c3c
<__eh_globals_init::~__eh_globals_init()+0xc>
10222c38: d65f03c0ret
10222c3c: a9bf7bfdstp x29, x30, [sp, #-16]!
10222c40: 910003fdmov x29, sp
return pthread_key_delete (__key);
10222c44: b940ldr w0, [x0]
10222c48: 94008806bl 10244c60
10222c4c: a8c17bfdldp x29, x30, [sp], #16
10222c50: d65f03c0ret
[Bug libstdc++/105880] eh_globals_init destructor not setting _M_init to false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880 --- Comment #4 from Chris Johns --- (In reply to Andrew Pinski from comment #3) > Sounds like the order of deconstructors is wrong. > Where is __cxxabiv1::__cxa_get_globals being called from that is the problem? The `std::ios_base::Init::~Init()` is being called after this object has destructed. The ios_base class uses a sentry to check the state. The code in it's destructor is: if (bool(_M_os.flags() & ios_base::unitbuf) && !uncaught_exception()) The std::cerr object has ios_base::unitbuf set so uncaught_exception() is called. This call gets the cxa globals: __cxa_eh_globals *globals = __cxa_get_globals ();
[Bug libstdc++/105880] eh_globals_init destructor not setting _M_init to false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880 --- Comment #6 from Chris Johns --- (In reply to Andrew Pinski from comment #5) > There has to be an ordering issue of the calling of the deconstructors vs > the ordering of the constructors. > > Maybe the problem is the `eh_gloabls init` priority is not set correctly to > be first/last. It would have to be last or close to it and I have no idea how that could be done without additional attributes that are not standard.
[Bug libstdc++/105880] eh_globals_init destructor not setting _M_init to false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880 --- Comment #10 from Chris Johns --- (In reply to Jonathan Wakely from comment #9) > Created attachment 53103 [details] > Fix lifetime bugs for non-TLS eh_globals > > Does this work? That is a great way to solve this problem given the limitation the eh_globals has. And yes the eh_globals single-threaded fallback buffer does have this problem however for RTEMS that is a corner case because something has called `exit()` on an embedded realtime system and that typically means a reset is about to happen. FYI Sebastian has reviewed our compiler set up as TLS was not enabled. The architectures that support TLS should soon be switching to that.
[Bug libgcc/109282] New: Libgcc references sh and not $(SHELL) in Makefile.in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109282 Bug ID: 109282 Summary: Libgcc references sh and not $(SHELL) in Makefile.in Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: chrisj at rtems dot org Target Milestone: --- Created attachment 54753 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54753&action=edit Change sh to $(SHELL) The libgcc Makefile.in has `sh` and not `$(SHELL)` and that failed on MacOS Ventura. The attached patch fixes the problem and builds an RTEMS crosscompiler tool chain.
[Bug libgcc/109282] Libgcc references sh and not $(SHELL) in Makefile.in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109282 --- Comment #2 from Chris Johns --- (In reply to Andrew Pinski from comment #1) > move-if-change should work just fine with a normal POSIX shell ... It does. Maybe it was not found? > What is the error message with /bin/sh still there? The error message was: /bin/sh: line 1: 16562 Killed: 9 sh ../../../../gnu-mirror-gcc-cf59d86/libgcc/../move-if-change $dest ../../.././gcc/include/unwind.h This is the only place in the file `sh` is directly referenced like this. I did not look into this any further as `$(SHELL)` worked.
[Bug libgcc/109282] Libgcc references sh and not $(SHELL) in Makefile.in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109282 --- Comment #5 from Chris Johns --- (In reply to Andrew Pinski from comment #4) > My bet if you do /bin/sh you would also get into trouble too ... I do not think it is /bin/sh but you are right with the link bring MacOS blocking an exe that should not run and it was related to my path and my mistake. Using make's $(SHELL) with an absolute path made the build ignore my broken set up and more robust. Make uses: build/libcc1/config.log:SHELL='/bin/sh' I think the path as a clean up is a good things to have.
