gdb: link with libatomic when it existsHEADmaster

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>

0 files changed, 0 insertions, 0 deletions