[Bug sanitizer/112563] [14 regression] libsanitizer doesn't assemble with Solaris/sparc as

["ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>> --- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #9)
[...]
>> If it works, nice.  Can you file it on github.com/llvm/llvm-project as an issue
>> and see if upstream is willing to accept it?  I think they'll want some
>
> Can do, either as an issue or directly as a pull request.  I'll run it
> through a full llvm build, too, first.

Unfortunately, this didn't work out at all.  Initially, I had only
rebuilt libsanitizer with the patch, checking that there were only the
exepected number of calls to mem* functions in libasan.so.

The LLVM build on Solaris/sparcv9, while successful, doesn't tell you
much, unfortunately: due to a clang bug on sparc, the asan tests are
never run there.

When I ran a full Solaris/SPARC bootstrap, all asan tests FAILed with

AddressSanitizer: CHECK failed: asan_rtl.cpp:397 "((!AsanInitIsRunning() &&
"ASan init calls itself!")) != (0)" (0x0, 0x0) (tid=1)

I've once had the misfortune of debugging such a initializion order
issue in LLVM, and that was an long and painful experience which I'd
rather not repeat here.  The fix found in that case (build both
libasan.so and all asan tests with -z now) didn't work here, either:
this just turned the assertion failures into SEGVs.

This reliance on init order is a total nightmare: the details are
completely platform-specific and not portable at all.

Given all this, I've instead developed a patch that checks for assembler
a = b support in the libsanitizer configury and uses the result in
sanitizer_redefine_builtins.h.  This way, only the one configuration
that has an issue here is punished.  However, this has to stay local to
libsanitizer for obvious reasons.