[Driver] Fix compiler-rt lookup for x32

[hvdijk]

Summary

x86_64-linux-gnu and x86_64-linux-gnux32 use different ABIs and objects built for one cannot be used for the other. In order to build and use compiler-rt for x32, we need to treat x32 as a new arch there. This updates the driver to search using the new arch name.

[glaubitz]

Thanks, this finally fixes the build for me. I wasn't aware that there was a getArchNameForCompilerRTLib() function in clang.

[glaubitz]

clang/test/Driver/sanitizer-ld.c

309

Do we need want to run the test for i386 anymore?

[glaubitz]

clang/test/Driver/sanitizer-ld.c

309

Do we _not_, not _need_. Sorry.

[hvdijk]

clang/test/Driver/sanitizer-ld.c

309

This test just somewhat arbitrarily distributes the different sanitizer modules over i386 and x86_64 for testing rather than testing each module for each arch, so I figured there was no harm in changing one of them to x86_64-linux-gnux32. i386 is still getting tested elsewhere.

[glaubitz]

clang/test/Driver/sanitizer-ld.c

309

OK, thanks. Then I will mark this as approved from my side.

[glaubitz]

So, we only need D99988 and this one (D100148) now and the LLVM package will finally build on Debian without any additional tweaks.

[glaubitz]

Hi! Can we get this patch merged as-is or do we need anything else?

[hvdijk]

In D100148#2683325, @glaubitz wrote:

Hi! Can we get this patch merged as-is or do we need anything else?

Sorry, miscommunication. I was thinking you could use this to update D99988 to actually build the relevant compiler-rt bits for x32, and then once both that and this are ready, both can be submitted at the same time. The reason for that is that this is not useful by itself, and if it turns out that D99988 actually requires some other clang change as well that we are not seeing yet, it will be easier to update this if it has not been pushed yet. Do you think it would be better to push this first?

[glaubitz]

In D100148#2683710, @hvdijk wrote:

In D100148#2683325, @glaubitz wrote:

Hi! Can we get this patch merged as-is or do we need anything else?

Sorry, miscommunication. I was thinking you could use this to update D99988 to actually build the relevant compiler-rt bits for x32, and then once both that and this are ready, both can be submitted at the same time. The reason for that is that this is not useful by itself, and if it turns out that D99988 actually requires some other clang change as well that we are not seeing yet, it will be easier to update this if it has not been pushed yet. Do you think it would be better to push this first?

Understood. However, I'm not really sure what else we need. Do we just take the architecture definition from here to pass the proper flags to the compiler or do we also need to add
some x32-specific code?

[hvdijk]

In D100148#2683748, @glaubitz wrote:

Understood. However, I'm not really sure what else we need. Do we just take the architecture definition from here to pass the proper flags to the compiler or do we also need to add
some x32-specific code?

My personal opinion: I would say to enable the compiler-rt bits that are already correct for x32, which should only require passing the proper flags. Beyond the libsanitizer bits, I do not know which other bits, if any, might already be correct for x32 though.

[glaubitz]

@hvdijk I just noticed that the sanitizer defines SANITIZER_X32 for x32, so I assume your patch itself is already correct.

[hvdijk]

Updated to use Triple.isX32().

Should we perhaps just merge this as is, ahead of the update to compiler-rt to create x32 objects? For non-x32, this change is NFC, for x32, the change results in a better error message about compiler-rt objects not existing rather than being for the wrong architecture.

[glaubitz]

In D100148#2880499, @hvdijk wrote:

Updated to use Triple.isX32().

Should we perhaps just merge this as is, ahead of the update to compiler-rt to create x32 objects? For non-x32, this change is NFC, for x32, the change results in a better error message about compiler-rt objects not existing rather than being for the wrong architecture.

Yes, I fully agree on this stance. I've been waiting for this patch for Debian, plus the remaining changes to get Rust to build on x32 ;-).

[MaskRay]

Since @glaubitz is here:

I want to set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR to on by default so that the libraries for x86-64 will be in lib/clang/13.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.profile.a instead of lib/clang/13.0.0/lib/linux/libclang_rt.profile-x86_64.a.
Clang driver supports both paths.

[glaubitz]

In D100148#2881382, @MaskRay wrote:

Since @glaubitz is here:

I want to set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR to on by default so that the libraries for x86-64 will be in lib/clang/13.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.profile.a instead of lib/clang/13.0.0/lib/linux/libclang_rt.profile-x86_64.a.
Clang driver supports both paths.

OK, I don't think this will have any ramifications for Debian. But if you want me to test a patch, please let me know or pull me into the review.

clang/lib/Driver/ToolChain.cpp

if (TC.getArch() == llvm::Triple::arm || TC.getArch() == llvm::Triple::armeb)
     return (arm::getARMFloatABI(TC, Args) == arm::FloatABI::Hard && !IsWindows)
                ? "armhf"
                : "arm";
 
   // For historic reasons, Android library is using i686 instead of i386.
   if (TC.getArch() == llvm::Triple::x86 && Triple.isAndroid())
     return "i686";
 
+  if (TC.getArch() == llvm::Triple::x86_64 &&
+      Triple.getEnvironment() == llvm::Triple::GNUX32)
+    return "x32";
+
   return llvm::Triple::getArchTypeName(TC.getArch());
 }
 
 StringRef ToolChain::getOSLibName() const {
   switch (Triple.getOS()) {
   case llvm::Triple::FreeBSD:
     return "freebsd";
   case llvm::Triple::NetBSD:

clang/test/Driver/sanitizer-ld.c

 // RUN:     -target x86_64-unknown-linux -fuse-ld=ld \
 // RUN:     -resource-dir=%S/Inputs/resource_dir \
 // RUN:     --sysroot=%S/Inputs/basic_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-MSAN-NO-LINK-RUNTIME-LINUX %s
 //
 // CHECK-MSAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.msan
 
 // RUN: %clang -fsanitize=undefined %s -### -o %t.o 2>&1 \
-// RUN:     -target i386-unknown-linux -fuse-ld=ld \
-// RUN:     --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:     -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
+// RUN:     --sysroot=%S/Inputs/multilib_64bit_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
 
 // RUN: %clang -fsanitize=float-divide-by-zero %s -### -o %t.o 2>&1 \
-// RUN:     -target i386-unknown-linux -fuse-ld=ld \
-// RUN:     --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:     -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
+// RUN:     --sysroot=%S/Inputs/multilib_64bit_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
 
 // RUN: %clang -fsanitize=undefined %s -### -o %t.o 2>&1 \
-// RUN:     -target i386-unknown-linux -fuse-ld=ld \
-// RUN:     --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:     -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
+// RUN:     --sysroot=%S/Inputs/multilib_64bit_linux_tree \
 // RUN:     -static-libsan \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
 
 // CHECK-UBSAN-LINUX: "{{.*}}ld{{(.exe)?}}"
 // CHECK-UBSAN-LINUX-NOT: libclang_rt.asan
 // CHECK-UBSAN-LINUX-NOT: libclang_rt.ubsan_standalone_cxx
-// CHECK-UBSAN-LINUX: "--whole-archive" "{{.*}}libclang_rt.ubsan_standalone-i386.a" "--no-whole-archive"
+// CHECK-UBSAN-LINUX: "--whole-archive" "{{.*}}libclang_rt.ubsan_standalone-x32.a" "--no-whole-archive"
 // CHECK-UBSAN-LINUX-NOT: libclang_rt.asan
 // CHECK-UBSAN-LINUX-NOT: libclang_rt.ubsan_standalone_cxx
 // CHECK-UBSAN-LINUX-NOT: "-lstdc++"
 // CHECK-UBSAN-LINUX: "-lpthread"
 
 // RUN: %clang -fsanitize=undefined -fno-sanitize-link-runtime %s -### -o %t.o 2>&1 \
 // RUN:     -target x86_64-unknown-linux -fuse-ld=ld \
 // RUN:     -resource-dir=%S/Inputs/resource_dir \
 // RUN:     --sysroot=%S/Inputs/basic_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-NO-LINK-RUNTIME-LINUX %s
 //
 // CHECK-UBSAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.undefined