[RISC-V][HWASAN] Enable HWASAN for RISC-V architecture

[smd]

Summary

[12/12] patch series to port ASAN for riscv64

These changes allow using HWASAN on RISCV64 architecture.

The majority of existing tests are passing with a few exceptions(see below).
The tests were run on QEMU, since currently there're no hardware with support
for J-extension.

For this feature to work the system must support PR_{SET,GET}_TAGGED_ADDR_CTRL
syscall. For now this is only available for a patched Linux kernel and QEMU with
enabled experimental J-extension.

Results of running HWASAN lit tests for RISC-V:

Unsupported      :  5
Passed             : 79                                                                           
Expectedly Failed  :  3

Current RISC-V code models and existing relocation symbols don't allow us to
tag global variables. This will be addressed in further patches.
These tests are marked as expected to fail since they check tagging globals:

HWAddressSanitizer-riscv64 :: TestCases/global-with-reduction.c (21 of 87)
HWAddressSanitizer-riscv64 :: TestCases/global.c (22 of 87)
HWAddressSanitizer-riscv64 :: TestCases/exported-tagged-global.c (52 of 87)

Depends On D131344

[kito-cheng]

I guess we should checking J extension is enabled somewhere when user trying to enable HWASAN? or checking that at HWASAN library at run-time? otherwise my understanding is user will get crash when enabling HWASAN if linux and/or HW don't support that?

[smd]

In D131345#3712814, @kito-cheng wrote:

I guess we should checking J extension is enabled somewhere when user trying to enable HWASAN? or checking that at HWASAN library at run-time? otherwise my understanding is user will get crash when enabling HWASAN if linux and/or HW don't support that?

It relies on a runtime check: during init runtime makes PR_{SET,GET}_TAGGED_ADDR_CTRL calls and if they're not supported, it fails with an error. So burden of checking if J extension is present is on Linux kernel.

[kito-cheng]

It relies on a runtime check: during init runtime makes PR_{SET,GET}_TAGGED_ADDR_CTRL calls and if they're not supported, it fails with an error. So burden of checking if J extension is present is on Linux kernel.

Sounds good to me :)

clang/lib/Driver/ToolChains/Linux.cpp

if (IsX86_64 || IsMIPS64 || IsAArch64 || IsPowerPC64 || IsSystemZ ||
     Res |= SanitizerKind::Thread;
   if (IsX86_64)
     Res |= SanitizerKind::KernelMemory;
   if (IsX86 || IsX86_64)
     Res |= SanitizerKind::Function;
   if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86 || IsMIPS || IsArmArch ||
       IsPowerPC64 || IsHexagon || IsLoongArch64)
     Res |= SanitizerKind::Scudo;
-  if (IsX86_64 || IsAArch64) {
+  if (IsX86_64 || IsAArch64 || IsRISCV64) {
     Res |= SanitizerKind::HWAddress;
+  }
+  if (IsX86_64 || IsAArch64) {
     Res |= SanitizerKind::KernelHWAddress;
   }
   return Res;
 }
 
 void Linux::addProfileRTLibs(const llvm::opt::ArgList &Args,
                              llvm::opt::ArgStringList &CmdArgs) const {
   // Add linker option -u__llvm_profile_runtime to cause runtime

compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake

 set(ALL_GWP_ASAN_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64})
 if(APPLE)
   set(ALL_LSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${MIPS64} ${ARM64})
 else()
   set(ALL_LSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${MIPS64} ${ARM64} ${ARM32}
       ${PPC64} ${S390X} ${RISCV64} ${HEXAGON})
 endif()
 set(ALL_MSAN_SUPPORTED_ARCH ${X86_64} ${MIPS64} ${ARM64} ${PPC64} ${S390X})
-set(ALL_HWASAN_SUPPORTED_ARCH ${X86_64} ${ARM64})
+set(ALL_HWASAN_SUPPORTED_ARCH ${X86_64} ${ARM64} ${RISCV64})
 set(ALL_MEMPROF_SUPPORTED_ARCH ${X86_64})
 set(ALL_PROFILE_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${PPC32} ${PPC64}
     ${MIPS32} ${MIPS64} ${S390X} ${SPARC} ${SPARCV9} ${HEXAGON}
     ${RISCV32} ${RISCV64})
 set(ALL_TSAN_SUPPORTED_ARCH ${X86_64} ${MIPS64} ${ARM64} ${PPC64} ${S390X}
     ${LOONGARCH64})
 set(ALL_UBSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${RISCV64}
     ${MIPS32} ${MIPS64} ${PPC64} ${S390X} ${SPARC} ${SPARCV9} ${HEXAGON}