[PATCH] D140011: [clang][compiler-rt] Support LLVM_ENABLE_PER_TARGET_RUNTIME_DIR on Arm Linux and BSD

[David Spickett via Phabricator via llvm-commits]

DavidSpickett created this revision.
Herald added subscribers: Enna1, kristof.beyls, dberris.
Herald added a project: All.
DavidSpickett requested review of this revision.
Herald added subscribers: llvm-commits, Sanitizers, cfe-commits, MaskRay.
Herald added projects: clang, Sanitizers, LLVM.

The orginal single folder layout produced libraries in the form:
lib/linux/<libname>-<archname>.a

That archname for Arm depended on whether you had hard or soft float.
This is sometimes shown as "arm" (soft) vs. "armhf" (hard).

If this is set in a triple we do it in the final portion, the ABI.
"gnueabi" for soft float, "gnueabihf" for hard float.

Meaning that the expected triple is:
arm-unknown-linux-gnueabihf
Not this:
armhf-unknown-linux-gnueabihf

For the per target layout I have decided to rely on the ABI portion
of the triple instead of the arch name used for the old layout
(doing that would produce the invalid triple above).

This means that building with triple:
armv8l-unknown-linux-gnueabihf
Will result in libraries in:
lib/arm-unknown-linux-gnueabihf/

And clang will now know to look for "arm" instead of "armv8l".
Meaning that we can share libraries between an armv8 and armv7 build
as we did with the previous layout. In addition to handling spelling
differences e.g. "armv8l" with an "l" on some Linux distros.

compiler-rt will autodetect that the "armhf" and/or "arm" architecture
can be built. We then replace the given triple's architecture with that.
Then if the triple's float ABI doesn't match, we change that. That new
triple is then used as the folder name.

If you select to build only the given triple, with COMPILER_RT_DEFAULT_TARGET_ONLY,
compiler-rt will not autodetect the architecture and for that I assume you
know what you're doing. In that case the library path will use the unomdified triple.

>From what I can tell, this is how most large builds e.g Android and
Arm's Embedded Toolchain for llvm do things. I assume that big endian "armeb"
builds would end up doing this too.

Bare metal builds will not be using per target runtime dirs so they
remain as they were.

Depends on D139536 <https://reviews.llvm.org/D139536>


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D140011

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-pc-windows-msvc/.keep
  clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-unknown-linux-gnueabi/.keep
  clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/arm-unknown-linux-gnueabihf/.keep
  clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/armeb-unknown-linux-gnueabi/.keep
  clang/test/Driver/Inputs/arm_float_abi_runtime_path/lib/armeb-unknown-linux-gnueabihf/.keep
  clang/test/Driver/arm-float-abi-runtime-path.c
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  llvm/CMakeLists.txt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D140011.482808.patch
Type: text/x-patch
Size: 5113 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20221214/38f88aa8/attachment.bin>