[PATCH] D98452: [compiler-rt] Produce the right arch suffix for arm libraries

[Martin Storsjö via Phabricator via llvm-commits]

mstorsjo added a comment.

In D98452#3113198 <https://reviews.llvm.org/D98452#3113198>, @manojgupta wrote:

> Sorry for replying since this patch has been there for a while. But this has broken the installs for the baremetal targets eg armv7m-none-eabi.

Sorry for the breakage. Now I see the source for the issue.

Have a look at `getArchNameForCompilerRTLib` in clang/lib/Driver/ToolChain.cpp:

  static StringRef getArchNameForCompilerRTLib(const ToolChain &TC,
                                               const ArgList &Args) {
    const llvm::Triple &Triple = TC.getTriple();
    bool IsWindows = Triple.isOSWindows();
  
    if (TC.getArch() == llvm::Triple::arm || TC.getArch() == llvm::Triple::armeb)
      return (arm::getARMFloatABI(TC, Args) == arm::FloatABI::Hard && !IsWindows)
                 ? "armhf"
                 : "arm";
  [...]

This gets called from `ToolChain::buildCompilerRTBasename`. Thus, when using this implementation, Clang only ever looks for libraries with the name `libclang_rt.builtins-arm.a` (and `-armhf`) . It does indeed lack differentiability between architecture versions - but I changed compiler-rt to produce the names that Clang expects.

The unexpected issue is that the BareMetal toolchain overrides `buildCompilerRTBasename`, like this:

  std::string BareMetal::buildCompilerRTBasename(const llvm::opt::ArgList &,
                                                 StringRef, FileType,
                                                 bool) const {
    return ("libclang_rt.builtins-" + getTriple().getArchName() + ".a").str();
  }

Thus here the exact architecture name gets used.

Can we detect whether we are targeting the `baremetal` OS in the compiler-rt cmake codepath that I touched (I would expect that we can, as it installs things into a `/baremetal/` subdirectory), and avoid the architecture name normalization in that case?

> Setting LLVM_ENABLE_PER_TARGET_RUNTIME_DIR does not help either. It changes installation location to /usr/lib64/clang/14.0.0/lib/armv7m-none-eabi/libclang_rt.builtins.a which is better for installing multiple ABIS.

But "-print-libgcc-file-name" does not detect it, it still prints /usr/lib64/clang/13.0.0/lib/baremetal/libclang_rt.builtins-armv7m.a. .

That sounds like a separate issue that woul be great to fix, independently of this issue. The per-target runtime directory setup probably is better overall, but we should still keep both setups working.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98452/new/

https://reviews.llvm.org/D98452