This patch (on top of the previous two (https://reviews.llvm.org/D40898 and
https://reviews.llvm.org/D40899) complete the compiler-rt side of the the Solaris
sanitizer port.
It contains the following sets of changes:
- For the time being, the port is for 32-bit x86 only, so reject the various tests on x86_64.
- When compiling as C++, <setjmp.h> resp. <iso/setjmp_iso.h> only declares _setjmp and _longjmp inside namespace std.
- MAP_FILE is a Windows feature. While e.g. Linux <sys/mman.h> provides a no-op compat define, Solaris does not.
- test/asan/TestCases/Posix/coverage.cc was initially failing like this:
/vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/sanitizer_common/scripts/sancov.py: 4 files merged; 2 PCs total
rm: cannot remove '/var/gcc/llvm/local/projects/compiler-rt/test/asan/I386SunOSConfig/TestCases/Posix/Output/coverage': Invalid argument
Further digging revealed that the rm was trying to remove the running test's working directory which failed as observed. cd'ing out of the dir before let the test pass.
- Two tests needed a declaration of alloca. I've now copied the existing code from test/asan/TestCases/alloca_constant_size.cc, but it may be more profitable and maintainable to have a common testsuite header where such code is collected.
- Similarly, Solaris' printf %p format doesn't include the leading 0x.
- In test/asan/TestCases/malloc-no-intercept.c, I had to undef EXTENSIONS (predefined by clang for no apparent reason) to avoid conflicting declarations for memalign.
- test/ubsan/TestCases/Float/cast-overflow.cpp has different platform dependent ways to define BYTE_ORDER and friends. Why not just use BYTE_ORDER and friends as predefined by clang and gcc?
Do we need to check for __svr4__? Are there other alive SunOS systems?