public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: David Edelsohn <dje.gcc@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime
Date: Wed, 06 Dec 2023 02:28:42 -0300	[thread overview]
Message-ID: <or1qbzsxv9.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <orr0k0rw0g.fsf@lxoliva.fsfla.org> (Alexandre Oliva's message of "Tue, 05 Dec 2023 21:54:07 -0300")

On Dec  5, 2023, Alexandre Oliva <oliva@adacore.com> wrote:

> Maybe we should narrow it down to targets in which weak undefined
> symbols are available with the expected semantics, and where the symbol
> is known to have ever been defined in libc.  On it...

This patch reintroduces the weak symbol reference only on GNU systems,
where they're most likely to be useful.  If other systems could benefit,
we can always add them later.

> Or maybe a weak definition (or weak alias to a definition) in that file
> would enable us to test whether the weak definition was preempted

Uhh...  'cept libc wouldn't preempt from libstdc++; the opposite would
occur, but that doesn't help.


Regstrapped on x86_64-linux-gnu, also tested with
ac_cv_func___cxa_thread_atexit_impl=no.  Ok to (re)install?


libsupc++: try cxa_thread_atexit_impl at runtime

g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
a platform that lacks __cxa_thread_atexit_impl, even if the program is
built and run using that toolchain on a (later) platform that offers
__cxa_thread_atexit_impl.

This patch adds runtime testing for __cxa_thread_atexit_impl on select
platforms (GNU variants, for starters) that support weak symbols.


for  libstdc++-v3/ChangeLog

	* config/os/gnu-linux/os_defines.h
	(_GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL): Define.
	* libsupc++/atexit_thread.cc [__GXX_WEAK__ &&
	_GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL]
	(__cxa_thread_atexit): Add dynamic detection of
	__cxa_thread_atexit_impl.
---
 libstdc++-v3/config/os/gnu-linux/os_defines.h |    5 +++++
 libstdc++-v3/libsupc++/atexit_thread.cc       |   23 ++++++++++++++++++++++-
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/config/os/gnu-linux/os_defines.h b/libstdc++-v3/config/os/gnu-linux/os_defines.h
index 87317031fcd71..a2e4baec069d5 100644
--- a/libstdc++-v3/config/os/gnu-linux/os_defines.h
+++ b/libstdc++-v3/config/os/gnu-linux/os_defines.h
@@ -60,6 +60,11 @@
 # define _GLIBCXX_HAVE_FLOAT128_MATH 1
 #endif
 
+// Enable __cxa_thread_atexit to rely on a (presumably libc-provided)
+// __cxa_thread_atexit_impl, if it happens to be defined, even if
+// configure couldn't find it during the build.
+#define _GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL 1
+
 #ifdef __linux__
 // The following libpthread properties only apply to Linux, not GNU/Hurd.
 
diff --git a/libstdc++-v3/libsupc++/atexit_thread.cc b/libstdc++-v3/libsupc++/atexit_thread.cc
index 9346d50f5dafe..aa4ed5312bfe3 100644
--- a/libstdc++-v3/libsupc++/atexit_thread.cc
+++ b/libstdc++-v3/libsupc++/atexit_thread.cc
@@ -138,11 +138,32 @@ namespace {
   }
 }
 
+#if __GXX_WEAK__ && _GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL
+extern "C"
+int __attribute__ ((__weak__))
+__cxa_thread_atexit_impl (void (_GLIBCXX_CDTOR_CALLABI *func) (void *),
+			  void *arg, void *d);
+#endif
+
+// ??? We can't make it an ifunc, can we?
 extern "C" int
 __cxxabiv1::__cxa_thread_atexit (void (_GLIBCXX_CDTOR_CALLABI *dtor)(void *),
-				 void *obj, void */*dso_handle*/)
+				 void *obj, void *dso_handle)
   _GLIBCXX_NOTHROW
 {
+#if __GXX_WEAK__ && _GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL
+  if (__cxa_thread_atexit_impl)
+    // Rely on a (presumably libc-provided) __cxa_thread_atexit_impl,
+    // if it happens to be defined, even if configure couldn't find it
+    // during the build.  _GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL
+    // may be defined e.g. in os_defines.h on platforms where some
+    // versions of libc have a __cxa_thread_atexit_impl definition,
+    // but whose earlier versions didn't.  This enables programs build
+    // by toolchains compatible with earlier libc versions to still
+    // benefit from a libc-provided __cxa_thread_atexit_impl.
+    return __cxa_thread_atexit_impl (dtor, obj, dso_handle);
+#endif
+
   // Do this initialization once.
   if (__gthread_active_p ())
     {


-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

  reply	other threads:[~2023-12-06  5:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-09  1:55 Alexandre Oliva
2023-11-09  8:20 ` Jonathan Wakely
2023-12-01 20:40   ` Alexandre Oliva
2023-12-01 20:41     ` Jason Merrill
2023-12-05 16:10 ` David Edelsohn
2023-12-05 23:15   ` David Edelsohn
2023-12-05 23:19     ` Andrew Pinski
2023-12-06  5:18     ` Alexandre Oliva
2023-12-06  0:54   ` Alexandre Oliva
2023-12-06  5:28     ` Alexandre Oliva [this message]
2023-12-06 12:30       ` Thomas Schwinge
2023-12-06 13:52         ` Jonathan Wakely
2023-12-06 14:40           ` Jonathan Wakely
2023-12-06 22:46             ` Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=or1qbzsxv9.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).