Page MenuHomeFreeBSD

riscv64: enable ASAN and UBSAN
ClosedPublic

Authored by pkubaj on Jan 13 2022, 2:03 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 8 2024, 9:34 AM
Unknown Object (File)
Mar 8 2024, 9:34 AM
Unknown Object (File)
Mar 8 2024, 7:45 AM
Unknown Object (File)
Feb 8 2024, 6:36 AM
Unknown Object (File)
Jan 29 2024, 10:17 AM
Unknown Object (File)
Jan 15 2024, 1:53 AM
Unknown Object (File)
Jan 11 2024, 7:13 AM
Unknown Object (File)
Jan 4 2024, 10:32 PM
Subscribers

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 43899
Build 40787: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Jan 13 2022, 3:49 PM
lib/libclang_rt/Makefile
42

Hmm, I don't really like to have these blocks, but putting more ifdeffery in the first #ifdef block isn't too nice either. In other cases we typically do this with intermediate variables...

There are two ways we can do it.

  1. Having lists of available sanitizers for each architecture (present behaviour).
  2. Having lists of architectures for each sanitizers.

Do you prefer to switch to 2.?

Anyway, the point of this review is to add support for riscv64, not refactor that code.

Let's commit this now, and refactor it later.

Also, there's only so much that we can add in that Makefile, once https://reviews.llvm.org/D116867 I plan to add support for powerpc*, then maybe ARM people will add their and that's it.

lib/libclang_rt/Makefile
42

I'd almost commented the same thing, but I thought I'd defer *that* until we can chunk this into things like "HAS_UBSAN" "HAS_ASAN" "HAS_XRAY" or something like "SUPPORTS=asan ubsan" or "SUPPORTS=asan cfi safestack stats ubsan fuzzer msan tsan xrat" or possibly "SUPPORTS.amd64=" "SUPPORTS.riscv=". Not sure the best model, but am leaning towards the latter.

In D33875#766092, @dim wrote:

Let's commit this now, and refactor it later.

On this I agree. It's hard to generalize from only a couple of cases. And we've often been worse for it in the past and had to refactor again

Also, there's only so much that we can add in that Makefile, once https://reviews.llvm.org/D116867 I plan to add support for powerpc*, then maybe ARM people will add their and that's it.

Yea, if these events are on the foreseeable horizon, we should wait til we get through them all to refactor.

As for powerpc*, depends on how soon my patch gets reviewed.
As for ARM, I don't have any plans to implement it. I only meant that it should be possible to add some sanitizers for ARM (not only aarch64, but also armv7 and maybe armv6).

What does this enable? Is it required to build world WITH_ASAN=y/WITH_UBSAN=y ? Or just adds the necessary bits so that one could compile and link a program with sanitizers enabled?

What does this enable?

This enables the build of the indicated runtime support libraries, which go into /usr/lib/clang/x.y.z/lib/freebsd, and are linked in whenever you turn on these sanitizers on the compiler command line.

Is it required to build world WITH_ASAN=y/WITH_UBSAN=y ? Or just adds the necessary bits so that one could compile and link a program with sanitizers enabled?

Both. Well, without the runtime libraries you can't link programs, so WITH_ASAN would appear to work, until you'd run into a link error.