Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: simon.marchi@polymtl.ca
To: gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@polymtl.ca>
Subject: [PATCH] gdb: link with libatomic when it exists
Date: Fri,  6 Feb 2026 17:22:14 -0500	[thread overview]
Message-ID: <20260206222227.2847503-1-simon.marchi@polymtl.ca> (raw)

From: Simon Marchi <simon.marchi@polymtl.ca>

Since commit 329a53a6d5 (Some cleanups to "pretend language" handling),
building with clang fails with:

    $ ~/src/binutils-gdb/configure CC=clang CFLAGS=-O0 CXX=clang++ CXXFLAGS=-O0 LDFLAGS=-fuse-ld=mold
      CXXLD  gdb
    mold: error: undefined symbol: __atomic_compare_exchange
    >>> referenced by read.c
    >>>               dwarf2/read.o:(std::atomic<packed<dwarf_source_language, 2ul> >::compare_exchange_strong(packed<dwarf_source_language, 2ul>&, packed<dwarf_source_language, 2ul>, std::memory_order, std::memory_order))
    ...

It's not necessary to link with mold nor to build with -O0 to reproduce
the error, but it makes the error message more informative regarding
which use of std::atomic requires the __atomic_compare_exchange symbol.

For some reason, the compare_exchange_strong calls on
`std::atomic<packed<dwarf_source_language, 2>>` added in 329a53a6d5 make
clang generate a call into libatomic, whereas gcc implements it using
only the generated assembly.  I'm no compiler expert, but this seems
like a choice that each compiler is free to make.  The solution is to
use the -latomic flag when linking in clang builds.

We (the ROCgdb team) considered writing a targeted configure check to
determine if -latomic was needed for this specific edge case, for the
toolchain in use.  But we ended up thinking it would be simpler to just
always link with libatomic, when it is present.  We think there is no
real downside to it.  If libatomic is not really needed, since most
toolchains now default to using --as-needed, libatomic won't be
DT_NEEDED if it's not truly needed.  Plus, if things change (either our
code or the compilers) in the future and more things end up requiring
libatomic, we'll be covered.

Bug 33879 is about the error shown above.  Bug 29455 appears to be the
same, but about symbol __atomic_load.

Change-Id: I6778ae8f35acc99ffb8955479bb57766eecf4556
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33879
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29455
---
 gdb/config.in    |  3 +++
 gdb/configure    | 44 ++++++++++++++++++++++++++++++++++++++++++++
 gdb/configure.ac |  6 ++++++
 3 files changed, 53 insertions(+)

diff --git a/gdb/config.in b/gdb/config.in
index 3c3d33c9accc..b11fcf183726 100644
--- a/gdb/config.in
+++ b/gdb/config.in
@@ -262,6 +262,9 @@
 /* Define if your <locale.h> file defines LC_MESSAGES. */
 #undef HAVE_LC_MESSAGES
 
+/* Define to 1 if you have the `atomic' library (-latomic). */
+#undef HAVE_LIBATOMIC
+
 /* Define if you have the babeltrace library. */
 #undef HAVE_LIBBABELTRACE
 
diff --git a/gdb/configure b/gdb/configure
index ddc25568ccd4..12c54521682a 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -26672,6 +26672,50 @@ _ACEOF
 fi
 
 
+# GDB uses std::atomic, which sometimes (depending on the arch, compiler, types,
+# etc) generates some calls into libatomic.  Always link with libatomic when
+# it exists, there shouldn't be any downsides in linking with it even if not
+# needed.
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for main in -latomic" >&5
+$as_echo_n "checking for main in -latomic... " >&6; }
+if ${ac_cv_lib_atomic_main+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-latomic  $LIBS"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+
+int
+main ()
+{
+return main ();
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  ac_cv_lib_atomic_main=yes
+else
+  ac_cv_lib_atomic_main=no
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_atomic_main" >&5
+$as_echo "$ac_cv_lib_atomic_main" >&6; }
+if test "x$ac_cv_lib_atomic_main" = xyes; then :
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_LIBATOMIC 1
+_ACEOF
+
+  LIBS="-latomic $LIBS"
+
+fi
+
+
 # Some systems (e.g. Solaris) have `gethostbyname' in libnsl.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing gethostbyname" >&5
 $as_echo_n "checking for library containing gethostbyname... " >&6; }
diff --git a/gdb/configure.ac b/gdb/configure.ac
index bd1a091aabf2..cf8078e1d89b 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -556,6 +556,12 @@ esac
 # We might need to link with -lm; most simulators need it.
 AC_CHECK_LIB(m, main)
 
+# GDB uses std::atomic, which sometimes (depending on the arch, compiler, types,
+# etc) generates some calls into libatomic.  Always link with libatomic when
+# it exists, there shouldn't be any downsides in linking with it even if not
+# needed.
+AC_CHECK_LIB(atomic, main)
+
 # Some systems (e.g. Solaris) have `gethostbyname' in libnsl.
 AC_SEARCH_LIBS(gethostbyname, nsl)
 

base-commit: 7aed4728e4d266f8e3c82f4689d90e53e9231f91
-- 
2.53.0


             reply	other threads:[~2026-02-06 22:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-06 22:22 simon.marchi [this message]
2026-02-07 15:00 ` Tom Tromey
2026-02-08  3:43   ` Simon Marchi

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=20260206222227.2847503-1-simon.marchi@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.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