[PATCH] gdb: link with libatomic when it exists

[PATCH] gdb: link with libatomic when it exists

[simon.marchi]

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

Re: [PATCH] gdb: link with libatomic when it exists

[Tom Tromey]

>>>>> "Simon" == simon marchi <simon.marchi@polymtl.ca> writes:

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

Makes sense.

This looks good to me.  Thank you.
Approved-By: Tom Tromey <tom@tromey.com>

Tom

Re: [PATCH] gdb: link with libatomic when it exists

[Simon Marchi]

On 2026-02-07 10:00, Tom Tromey wrote:
>>>>>> "Simon" == simon marchi <simon.marchi@polymtl.ca> writes:
> 
> Simon> We (the ROCgdb team) considered writing a targeted configure check to
> Simon> determine if -latomic was needed for this specific edge case, for the
> Simon> toolchain in use.  But we ended up thinking it would be simpler to just
> Simon> always link with libatomic, when it is present.  We think there is no
> Simon> real downside to it.  If libatomic is not really needed, since most
> Simon> toolchains now default to using --as-needed, libatomic won't be
> Simon> DT_NEEDED if it's not truly needed.  Plus, if things change (either our
> Simon> code or the compilers) in the future and more things end up requiring
> Simon> libatomic, we'll be covered.
> 
> Makes sense.
> 
> This looks good to me.  Thank you.
> Approved-By: Tom Tromey <tom@tromey.com>
> 
> Tom

Thanks, pushed.

Simon