[compiler-rt] Introduce rtsan clang frontend

[cjappl]

[[Demo review before upstreaming]]

Introduces the clang driver, codegen, -fsanitize flags. Adds lit tests to confirm things are operational.

[davidtrevelyan]

Does this just check for the presence of these two lines? Is there any way we could make this test a bit tighter, and really check the required behaviour of:

1. __rtsan_realtime_enter is the first instruction at the entry point, and
2. __rtsan_realtime_exit is final instruction before all exit points

I'm not sure this is possible because I'm really unfamiliar with the lit system. What do you think? Would this test bring good value?

[cjappl]

Good question. So for both of our references, the output of such a command looks like this:

/Users/topher/code/radsan_cjappl/llvm-project/build/bin/clang-19 -target x86_64-unknown-linux -fsanitize=realtime rtsan.c -S -emit-llvm -o - 

; ModuleID = 'rtsan.c'
source_filename = "rtsan.c"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux"

; Function Attrs: noinline nounwind nonblocking optnone uwtable
define dso_local i32 @foo(ptr noundef %0) #0 {
  call void @__rtsan_realtime_enter()
  %2 = alloca ptr, align 8
  store ptr %0, ptr %2, align 8
  %3 = load ptr, ptr %2, align 8
  %4 = load i32, ptr %3, align 4
  call void @__rtsan_realtime_exit()
  ret i32 %4
}

declare void @__rtsan_realtime_enter()

declare void @__rtsan_realtime_exit()

attributes #0 = { noinline nounwind nonblocking optnone uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }

!llvm.module.flags = !{!0, !1, !2, !3, !4}
!llvm.ident = !{!5}

!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 8, !"PIC Level", i32 2}
!2 = !{i32 7, !"PIE Level", i32 2}
!3 = !{i32 7, !"uwtable", i32 2}
!4 = !{i32 7, !"frame-pointer", i32 2}
!5 = !{!"clang version 19.0.0git (https://github.com/cjappl/llvm-project a247682ba7507b4a2babafe8b637ffc217bad9c6)"}

I worry that looking any more deeply into this representation may become brittle over time.

Basically, if we check for the following relative ordering:
define.foo
call.__rtsan_realtime_enter
call.*__rtsan_realtime_exit
ret

Is that overly confining? How often does the function representation change? Or the order shuffle? I don't know the answers to this question.

As inspiration, I took from tsan.c, which looks very similar:

int foo(int *a) { return *a; }
// CHECK: __tsan_init

and asan:

int foo(int *a) { return *a; }
// CHECK-ASAN: __asan_init
// CHECK-KASAN: __asan_{{.*}}load4_noabort
// CHECK-HWASAN: __hwasan_init
// CHECK-KHWASAN: __hwasan_tls

Both of which just check for presence of the initialization code.

As an additional wrinkle, I'm not sure if the lit system allows for relative checks/positional checks. We could possibly do it in some kind of more complex regex if we wanted to

[cjappl]

Closing in favor of the upstream review