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
Approved-By: Tom Tromey <tom@tromey.com>
/* 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
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; }
# 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)