[all-commits] [llvm/llvm-project] 73d45f: [compiler-rt][Sanitizer] Link sanitizer libs with ...

Tue Aug 2 01:56:44 PDT 2022

  Branch: refs/heads/release/15.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 73d45fea656b1c15c20dd96b386d6004638ae7f3
      https://github.com/llvm/llvm-project/commit/73d45fea656b1c15c20dd96b386d6004638ae7f3
  Author: Rainer Orth <ro at CeBiTec.Uni-Bielefeld.DE>
  Date:   2022-08-02 (Tue, 02 Aug 2022)

  Changed paths:
    M compiler-rt/CMakeLists.txt

  Log Message:
  -----------
  [compiler-rt][Sanitizer] Link sanitizer libs with -latomic on SPARC

When building on Linux/sparc64, the 32-bit `libclang_rt.asan.so`,
`libclang_rt.ubsan_minimal.so`, and `libclang_rt.ubsan_standalone.so`
failed to link with undefined references to 64-bit atomics, which `clang`
cannot inline.  Even D130569 <https://reviews.llvm.org/D130569> didn't help
because those libraries are linked with `-nodefaultlibs`, so dependent
libraries need to be added explicitly.

That's what this patch does.

Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`.

Differential Revision: https://reviews.llvm.org/D130571

(cherry picked from commit 0b2d5fd48bc281af89e5e7bfa33a3054b826ed52)

  Commit: 12e4e9777975858ea7f5f2a80157b0543c1f0c72
      https://github.com/llvm/llvm-project/commit/12e4e9777975858ea7f5f2a80157b0543c1f0c72
  Author: Rainer Orth <ro at CeBiTec.Uni-Bielefeld.DE>
  Date:   2022-08-02 (Tue, 02 Aug 2022)

  Changed paths:
    M llvm/include/llvm/Support/Host.h
    M llvm/lib/Support/CMakeLists.txt
    M llvm/lib/Support/Host.cpp

  Log Message:
  -----------
  [Support] Handle SPARC in sys::getHostCPUName

While working on D118450 <https://reviews.llvm.org/D118450>, I noticed that
`sys::getHostCPUName` lacks SPARC support.

This patch implements it.  The code is taken from/inspired by GCC's
`gcc/config/sparc/driver-sparc.cc`.  There's one caveat: since LLVM, unlike
GCC, doesn't support the SPARC-M7, -S7, and -M8 CPUs, I map all those to
the latest supported one (UltraSparc T4/`niagara4`).

Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu` by
running `savcov --version` on

- Netra SPARC S7-2 (SPARC-S7, Solaris 11.4)
- SPARC T5-2 (SPARC T5, Solaris 11.4)
- SPARC Enterprise T5220 (UltraSPARC T2, Solaris 11.3)
- SPARC T5 (UltraSPARC T5, Debian sid)
- SPARC T3 (UltraSPARC T3, Debian sid)
- SPARC Enterprise T5220 (Debian sid)

Differential Revision: https://reviews.llvm.org/D130272

(cherry picked from commit 979ddfff37d7e3bf258c2e5cbdc272fcb44c15f0)

  Commit: 0b96bce063b1cb0c118c94704b7ca778b687b239
      https://github.com/llvm/llvm-project/commit/0b96bce063b1cb0c118c94704b7ca778b687b239
  Author: Rainer Orth <ro at gcc.gnu.org>
  Date:   2022-08-02 (Tue, 02 Aug 2022)

  Changed paths:
    M clang/lib/Driver/ToolChains/Gnu.cpp
    M clang/test/Driver/linux-ld.c

  Log Message:
  -----------
  [Driver] Use libatomic for 32-bit SPARC atomics support on Linux

This is the Linux/sparc64 equivalent to D118021
<https://reviews.llvm.org/D118021>, necessary to provide an external
implementation of atomics on 32-bit SPARC which LLVM cannot inline even
with `-mcpu=v9` or an equivalent default.

Tested on `sparc64-unknown-linux-gnu`.

Differential Revision: https://reviews.llvm.org/D130569

(cherry picked from commit 9b1897bbd0e3a6e9ef099e74c3d3ed35428c0460)

  Commit: b00211d9dc994139520bc83b4cbeb621ed9b9fec
      https://github.com/llvm/llvm-project/commit/b00211d9dc994139520bc83b4cbeb621ed9b9fec
  Author: Rainer Orth <ro at gcc.gnu.org>
  Date:   2022-08-02 (Tue, 02 Aug 2022)

  Changed paths:
    M clang/lib/Driver/ToolChains/Arch/Sparc.cpp
    M clang/lib/Driver/ToolChains/Arch/Sparc.h
    M clang/lib/Driver/ToolChains/Clang.cpp
    M clang/lib/Driver/ToolChains/CommonArgs.cpp
    A clang/test/Driver/sparc-march.c
    A clang/test/Driver/sparc-mcpu.c
    A clang/test/Driver/sparc-mtune.c

  Log Message:
  -----------
  [clang][Driver] Handle SPARC -mcpu=native etc.

To make use of SPARC support in `getHostCPUName` as implemented by D130272
<https://reviews.llvm.org/D130272>, this patch uses it to handle
`-mcpu=native` and `-mtune=native`.  To match GCC, this patch rejects
`-march` instead of silently treating it as a no-op.

Tested on `sparcv9-sun-solaris2.11` and checking that those options are
passed on as `-target-cpu` resp. `-tune-cpu` as expected.

Differential Revision: https://reviews.llvm.org/D130273

(cherry picked from commit bf3714884ae4b4a0301bc6af78e8b4deff12558b)

  Commit: 08c239e29fb4ebc4970fbb041a027f8fffcc1a21
      https://github.com/llvm/llvm-project/commit/08c239e29fb4ebc4970fbb041a027f8fffcc1a21
  Author: Nico Weber <thakis at chromium.org>
  Date:   2022-08-02 (Tue, 02 Aug 2022)

  Changed paths:
    M lld/MachO/DriverUtils.cpp
    M lld/MachO/InputFiles.cpp
    M lld/MachO/InputFiles.h
    M lld/MachO/Writer.cpp
    M lld/test/MachO/special-symbol-ld-previous.s

  Log Message:
  -----------
  [lld/mac] Add support for $ld$previous symbols with explicit symbol name

A symbol `$ld$previous$/Another$1.2.3$1$3.0$14.0$_xxx$` means
"pretend symbol `_xxx` is in dylib `/Another` with version `1.2.3`
if the deployment target is between `3.0` and `14.0` and we're
targeting platform `1` (ie macOS)".

This means dylibs can now inject synthetic dylibs into the link, so
DylibFile needs to grow a 3rd constructor.

The only other interesting thing is that such an injected dylib
counts as a use of the original dylib. This patch gets this mostly
right (if _only_ `$ld$previous` symbols are used from a dylib,
we don't add a dep on the dylib itself, matching ld64), but one case
where we don't match ld64 yet is that ld64 even omits the original
dylib when linking it with `-needed-l`. Lld currently still adds a load
command for the original dylib in that case. (That's for a future
patch.)

Fixes #56074.

Differential Revision: https://reviews.llvm.org/D130725

(cherry picked from commit 241f0e8b76d544a4a07a7f775b8421632539be19)

Compare: https://github.com/llvm/llvm-project/compare/3928c126568d...08c239e29fb4