Is there a reason not to just call __llvm_libc::strcmp ?
The two will likely get collapsed by --icf=all anyway, but making it just a tail call to start with seems ideal.

In D145459#4173866, @leonardchan wrote:

Hmm, so test in compiler-rt/test/hwasan/TestCases/new-test.cpp does exercise this function via operator delete[](alloc, size, align);, but since we provide weak definitions for these symbols, even if the hwasan implementation isn't provided, then it'll default to the one provided by stdlib_new_delete.cpp.o in libc++. Not sure how easy it would be to tell the testing infrastructure not to use some specific symbols from libc++.

lgtm

Needs a test case.

This indicates a lack of testing coverage for the runtime. We should add runtime tests that use all the allocator signatures explicitly.

lgtm

In D143353#4105469, @jrtc27 wrote:

Latest feedback was not addressed when committing, and you gave hardly any time for anyone else who regularly works on or reviews changes for the RISC-V backend to comment

remove TODO

rebased, added clang driver test vs -fsanitize=shadow-call-stack

rebase

rebased

cleanups per review

LGTM pending acceptance of the spec change.

lgtm but we should probably wait for Fangrui's review too.

The lack of these registers is a regression in LLVM's assembler compared to the GNU assembler.

Assembler syntax exists for humans who write assembly, not just for compilers.
Compilers do not emit CFI that refers to these registers.

I don't think we want this in the generic compiler behavior. It would only make sense if the toolchain runtimes have extra versions, and I don't think we want that many extra versions.
It may be worthwhile to change the asan multilib builds to enable ubsan checks too, but I don't think we want to support two separate asan flavors in the driver.

I thought we agreed that the desirable semantics to keep things simple is that if markup is requested then markup is always printed, period. It shouldn't have anything to do with whether llvm-symbolizer works.

lgtm

This broke some existing cases using std::basic_string_view<std::byte> and the like.

lgtm

lgtm

In D85802#3879950, @dblaikie wrote:

In D85802#3879888, @mcgrathr wrote:

In D85802#3876106, @dblaikie wrote:

The C++ ABI is not part of the Fuchsia system ABI, nor what we call the "Fuchsia compiler ABI". Different users of C++ are free to use whatever C++ ABI they like. Only the backend ABI independent of language-specific issues is necessary to interoperate with other code on Fuchsia.

Sure enough - but I'm still sort of confused by why the Fuschia Clang target/compiler needs more than one C++ ABI. What is it interoperating with? (GCC doesn't have a Fuschia target implemented, does it? So what's it mean to target the GCC C++ ABI? what is compiling the code that Fuschia is trying to interoperate with when Clang targets Fuschia with a non-default C++ ABI?)

When we use GCC we're using the generic ELF targets. I think it's sufficient for us to tell you that indeed we do want the option of multiple C++ ABIs to select from without justifying everything about our work to a Clang reviewer before we can proceed with meeting the requirements of our system.

Would the generic ELF target support in Clang be adequate to meet that requirement, then? (so Fuschia target could be the custom C++ ABI (& custom C ABI if you likee) and a generic ELF target could be used for GCC ELF compatibility) - then we wouldn't need any C++ ABI customizability?

In D85802#3876106, @dblaikie wrote:

The C++ ABI is not part of the Fuchsia system ABI, nor what we call the "Fuchsia compiler ABI". Different users of C++ are free to use whatever C++ ABI they like. Only the backend ABI independent of language-specific issues is necessary to interoperate with other code on Fuchsia.

Sure enough - but I'm still sort of confused by why the Fuschia Clang target/compiler needs more than one C++ ABI. What is it interoperating with? (GCC doesn't have a Fuschia target implemented, does it? So what's it mean to target the GCC C++ ABI? what is compiling the code that Fuschia is trying to interoperate with when Clang targets Fuschia with a non-default C++ ABI?)

In D135716#3866291, @vitalybuka wrote:

BTW, would this one solve the problem D130237 this patch is trying to address?

I'm quite sure that we will always want a means to select the original Itanium ABI. It's also quite likely that there will be future innovations in the Fuchsia C++ ABI and we'll go through migration periods of supporting additional variants and changing the default for Fuchsia targets.

It's certainly correct that we envision each target having an explicit list of viable C++ ABIs to select from.

The C++ ABI is not part of the Fuchsia system ABI, nor what we call the "Fuchsia compiler ABI". Different users of C++ are free to use whatever C++ ABI they like. Only the backend ABI independent of language-specific issues is necessary to interoperate with other code on Fuchsia.

I had imagined making lsan always do this since there's a specific lsan-related rationale for it that applies to everybody.
I'm not clear on how cmake structures things and whether sanitizer_common would have to do it unconditionally since it's used by lsan code.

In D135340#3840704, @MaskRay wrote:

The subject should change the emitted symbol to __llvm_profile_raw_version.

lgtm

We haven't quite worked out this signature on the Fuchsia side yet.
Also, this makes the dl_iterate_phdr sequence in InitLoadedGlobals redundant so we should remove that for the Fuchsia configurations.

For the general case, not only glibc but probably all preexisting system libraries that don't have special hwasan support built in, I don't think you can rely on anything to hook into here. If you really needed to, *maybe* you could have dlopen and dlclose interceptors, but that seems really unlikely to go well. Bottom line, you probably have to find a way on those systems to have vanilla init and fini hook behavior (init_array, preinit_array, fini_array, etc.) be sufficient. It's challenging because you really need to come in before any code that could access a global is run, and with a DSO overriding a symbol in one of its DT_NEEDED DSOs the order of init hooks getting called could make it impossible to be in the right place.

lgtm.
You might add some comments in CGVTables.cpp about why this is done and what the alternatives might be in the future.

LGTM, I didn't realize Phabricator considered me to be blocking.

lgtm but be sure that Fuchsia target users get clear release-notes warning about the change.

lgtm

I don't see a problem having the compiler-rt and compiler changes in the same commit. Seems desirable in this case, actually.

lgtm since the compatibility window for platform versions that didn't have the new entry point has already passed by now.

Landed in a27b9139ab1bbdc93afaf240de2c2b9e45092884

lgtm

This needs a stub GetRSS for Fuchsia, at least.
Since there's no way to get a useful value for this on Fuchsia as yet, it would be preferable to conditionalize the machinery so it isn't doing no-op work.

Lgtm