[ASan][test] Enable ASan tests on SPARC #107405
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With PR llvm#107223 and PR llvm#107403, ASan testing can be enabled on SPARC. This patch does so, 32-bit only on Solaris (there is no 64-bit support even in GCC), and both 32 and 64-bit on Linux (although GCC only support 32-bit here). Apart from the obvious CMake changes, this patch includes a couple of testcase adjustments necessary for SPARC: - In `asan_oob_test.cpp`, the `OOB_int` subtest needs to be disabled: it performs unaligned accesses that cannot work on a strict-alignment target like SPARC. - `asan_test.cpp` needs to disable subtests that depend on support for `__builtin_setjmp` and `__builtin_longjmp`. - `zero_page_pc.cpp` reports `0x5` as the faulting address on access to `0x4`. I don't really know why, but it's consistent between Solaris and Linux. Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`. Solaris results are not too bad (36 `FAIL`s) while the Linux ones are quite bad, in particular because quite a number of tests just hang. For those reasons, I'm just posting the patch for reference in case someone else wants to try this on Linux.
llvmbot
added
compiler-rt
compiler-rt:asan
|
@llvm/pr-subscribers-compiler-rt-sanitizer Author: Rainer Orth (rorth) ChangesWith PR #107223 and PR #107403, ASan testing can be enabled on SPARC. This patch does so, 32-bit only on Solaris (there is no 64-bit support even in GCC), and both 32 and 64-bit on Linux (although GCC only supports 32-bit here). Apart from the obvious CMake changes, this patch includes a couple of testcase adjustments necessary for SPARC:
Tested on Solaris results are not too bad (36 For those reasons, I'm just posting the patch for reference in case someone else wants to try this on Linux. Full diff: https://github.com/llvm/llvm-project/pull/107405.diff 7 Files Affected:
diff --git a/compiler-rt/lib/asan/tests/CMakeLists.txt b/compiler-rt/lib/asan/tests/CMakeLists.txt
index b489bb99aeff3a..f103243e2549df 100644
--- a/compiler-rt/lib/asan/tests/CMakeLists.txt
+++ b/compiler-rt/lib/asan/tests/CMakeLists.txt
@@ -243,8 +243,8 @@ if(COMPILER_RT_CAN_EXECUTE_TESTS AND NOT ANDROID)
if(APPLE)
darwin_filter_host_archs(ASAN_SUPPORTED_ARCH ASAN_TEST_ARCH)
endif()
- list(REMOVE_ITEM ASAN_TEST_ARCH sparc sparcv9)
if(OS_NAME MATCHES "SunOS")
+ list(REMOVE_ITEM ASAN_TEST_ARCH sparcv9)
list(REMOVE_ITEM ASAN_TEST_ARCH x86_64)
endif()
diff --git a/compiler-rt/lib/asan/tests/asan_oob_test.cpp b/compiler-rt/lib/asan/tests/asan_oob_test.cpp
index 56f573c1fc4820..ce4c90c23e84b6 100644
--- a/compiler-rt/lib/asan/tests/asan_oob_test.cpp
+++ b/compiler-rt/lib/asan/tests/asan_oob_test.cpp
@@ -11,6 +11,13 @@
//===----------------------------------------------------------------------===//
#include "asan_test_utils.h"
+#ifdef __sparc__
+// Tests using unaligned accesses cannot work on strict-alignment targets.
+#define SKIP_ON_STRICT_ALIGNMENT(x) DISABLED_##x
+#else
+#define SKIP_ON_STRICT_ALIGNMENT(x) x
+#endif
+
NOINLINE void asan_write_sized_aligned(uint8_t *p, size_t size) {
EXPECT_EQ(0U, ((uintptr_t)p % size));
if (size == 1) asan_write((uint8_t*)p);
@@ -79,7 +86,7 @@ TEST(AddressSanitizer, OOB_char) {
OOBTest<U1>();
}
-TEST(AddressSanitizer, OOB_int) {
+TEST(AddressSanitizer, SKIP_ON_STRICT_ALIGNMENT(OOB_int)) {
OOBTest<U4>();
}
diff --git a/compiler-rt/lib/asan/tests/asan_test.cpp b/compiler-rt/lib/asan/tests/asan_test.cpp
index 827c2ae3a9cdc8..09d71569f89bba 100644
--- a/compiler-rt/lib/asan/tests/asan_test.cpp
+++ b/compiler-rt/lib/asan/tests/asan_test.cpp
@@ -631,7 +631,7 @@ NOINLINE void SigLongJmpFunc1(sigjmp_buf buf) {
#if !defined(__ANDROID__) && !defined(__arm__) && !defined(__aarch64__) && \
!defined(__mips__) && !defined(__mips64) && !defined(__s390__) && \
- !defined(__riscv) && !defined(__loongarch__)
+ !defined(__riscv) && !defined(__loongarch__) && !defined(__sparc__)
NOINLINE void BuiltinLongJmpFunc1(jmp_buf buf) {
// create three red zones for these two stack objects.
int a;
diff --git a/compiler-rt/test/asan/CMakeLists.txt b/compiler-rt/test/asan/CMakeLists.txt
index fb9e81bbe8082d..423491e54a37a3 100644
--- a/compiler-rt/test/asan/CMakeLists.txt
+++ b/compiler-rt/test/asan/CMakeLists.txt
@@ -36,8 +36,8 @@ set(ASAN_TEST_ARCH ${ASAN_SUPPORTED_ARCH})
if(APPLE)
darwin_filter_host_archs(ASAN_SUPPORTED_ARCH ASAN_TEST_ARCH)
endif()
-list(REMOVE_ITEM ASAN_TEST_ARCH sparc sparcv9)
if(OS_NAME MATCHES "SunOS")
+ list(REMOVE_ITEM ASAN_TEST_ARCH sparcv9)
list(REMOVE_ITEM ASAN_TEST_ARCH x86_64)
endif()
diff --git a/compiler-rt/test/asan/TestCases/zero_page_pc.cpp b/compiler-rt/test/asan/TestCases/zero_page_pc.cpp
index 9a395ecdf37c82..a7d00ce9b69886 100644
--- a/compiler-rt/test/asan/TestCases/zero_page_pc.cpp
+++ b/compiler-rt/test/asan/TestCases/zero_page_pc.cpp
@@ -19,6 +19,6 @@ int main() {
// the compiler is free to choose the order. As a result, the address is
// either 0x4, 0xc or 0x14. The pc is still in main() because it has not
// actually made the call when the faulting access occurs.
- // CHECK: {{AddressSanitizer: (SEGV|access-violation).*(address|pc) 0x0*[4c]}}
+ // CHECK: {{AddressSanitizer: (SEGV|access-violation).*(address|pc) 0x0*[45c]}}
return 0;
}
diff --git a/compiler-rt/test/sanitizer_common/CMakeLists.txt b/compiler-rt/test/sanitizer_common/CMakeLists.txt
index fa06b82acebd94..cad94df136a73c 100644
--- a/compiler-rt/test/sanitizer_common/CMakeLists.txt
+++ b/compiler-rt/test/sanitizer_common/CMakeLists.txt
@@ -58,10 +58,8 @@ foreach(tool ${SUPPORTED_TOOLS})
if(APPLE)
darwin_filter_host_archs(${tool_toupper}_SUPPORTED_ARCH TEST_ARCH)
endif()
- if(${tool} STREQUAL "asan")
- list(REMOVE_ITEM TEST_ARCH sparc sparcv9)
- endif()
if(OS_NAME MATCHES "SunOS" AND ${tool} STREQUAL "asan")
+ list(REMOVE_ITEM TEST_ARCH sparcv9)
list(REMOVE_ITEM TEST_ARCH x86_64)
endif()
diff --git a/compiler-rt/test/ubsan/CMakeLists.txt b/compiler-rt/test/ubsan/CMakeLists.txt
index d95f9ad649ebf8..4fda2e9ec27af1 100644
--- a/compiler-rt/test/ubsan/CMakeLists.txt
+++ b/compiler-rt/test/ubsan/CMakeLists.txt
@@ -51,10 +51,10 @@ foreach(arch ${UBSAN_TEST_ARCH})
if(COMPILER_RT_HAS_ASAN AND ";${ASAN_SUPPORTED_ARCH};" MATCHES ";${arch};")
# TODO(wwchrome): Re-enable ubsan for asan win 64-bit when ready.
# Disable ubsan with AddressSanitizer tests for Windows 64-bit,
- # 64-bit Solaris/x86, and SPARC.
+ # 64-bit Solaris/SPARC and Solaris/x86.
if((NOT (OS_NAME MATCHES "Windows" AND CMAKE_SIZEOF_VOID_P EQUAL 8)) AND
- (NOT (OS_NAME MATCHES "SunOS" AND ${arch} MATCHES x86_64)) AND
- (NOT ${arch} MATCHES sparc))
+ (NOT (OS_NAME MATCHES "SunOS" AND ${arch} MATCHES sparcv9)) AND
+ (NOT (OS_NAME MATCHES "SunOS" AND ${arch} MATCHES x86_64)))
add_ubsan_testsuites("AddressSanitizer" asan ${arch})
endif()
endif()
|
You can test this locally with the following command:git-clang-format --diff 0797c184c636889f2897746dc71390ae28005c7c 7b8142d20ed27dbd6d4d6771eaf0a0b5cb18ebed --extensions cpp -- compiler-rt/lib/asan/tests/asan_oob_test.cpp compiler-rt/lib/asan/tests/asan_test.cpp compiler-rt/test/asan/TestCases/zero_page_pc.cppView the diff from clang-format here.diff --git a/compiler-rt/lib/asan/tests/asan_oob_test.cpp b/compiler-rt/lib/asan/tests/asan_oob_test.cpp
index ce4c90c23e..0203662433 100644
--- a/compiler-rt/lib/asan/tests/asan_oob_test.cpp
+++ b/compiler-rt/lib/asan/tests/asan_oob_test.cpp
@@ -13,9 +13,9 @@
#ifdef __sparc__
// Tests using unaligned accesses cannot work on strict-alignment targets.
-#define SKIP_ON_STRICT_ALIGNMENT(x) DISABLED_##x
+# define SKIP_ON_STRICT_ALIGNMENT(x) DISABLED_##x
#else
-#define SKIP_ON_STRICT_ALIGNMENT(x) x
+# define SKIP_ON_STRICT_ALIGNMENT(x) x
#endif
NOINLINE void asan_write_sized_aligned(uint8_t *p, size_t size) {
@@ -86,9 +86,7 @@ TEST(AddressSanitizer, OOB_char) {
OOBTest<U1>();
}
-TEST(AddressSanitizer, SKIP_ON_STRICT_ALIGNMENT(OOB_int)) {
- OOBTest<U4>();
-}
+TEST(AddressSanitizer, SKIP_ON_STRICT_ALIGNMENT(OOB_int)) { OOBTest<U4>(); }
TEST(AddressSanitizer, OOBRightTest) {
size_t max_access_size = SANITIZER_WORDSIZE == 64 ? 8 : 4;
diff --git a/compiler-rt/lib/asan/tests/asan_test.cpp b/compiler-rt/lib/asan/tests/asan_test.cpp
index 09d71569f8..9cc4118dbd 100644
--- a/compiler-rt/lib/asan/tests/asan_test.cpp
+++ b/compiler-rt/lib/asan/tests/asan_test.cpp
@@ -629,9 +629,9 @@ NOINLINE void SigLongJmpFunc1(sigjmp_buf buf) {
siglongjmp(buf, 1);
}
-#if !defined(__ANDROID__) && !defined(__arm__) && !defined(__aarch64__) && \
- !defined(__mips__) && !defined(__mips64) && !defined(__s390__) && \
- !defined(__riscv) && !defined(__loongarch__) && !defined(__sparc__)
+# if !defined(__ANDROID__) && !defined(__arm__) && !defined(__aarch64__) && \
+ !defined(__mips__) && !defined(__mips64) && !defined(__s390__) && \
+ !defined(__riscv) && !defined(__loongarch__) && !defined(__sparc__)
NOINLINE void BuiltinLongJmpFunc1(jmp_buf buf) {
// create three red zones for these two stack objects.
int a;
|
rorth
changed the title
|
TBH, I'm wary of the suggested |
vitalybuka
approved these changes
Sep 6, 2024
rorth
added a commit
to rorth/llvm-project
that referenced
this pull request
Sep 11, 2024
When enabling ASan testing on SPARC as per PR llvm#107405, two tests `FAIL` in similar ways as detailed in Issue llvm#108194: at `-O1` and above, one line of the stacktrace lacks the line number info, causing the tests to `FAIL`. I could trace this to `clang` generating incomplete line number info; `g++` gets this right. To avoid this, this patch `XFAIL`s the affected tests on SPARC. Tested on `sparcv9-sun-solaris2.11`.
rorth
added a commit
to rorth/llvm-project
that referenced
this pull request
Sep 11, 2024
…p etc. on SPARC When enabling ASan testing on SPARC as per PR llvm#107405, two tests `FAIL`: ``` SanitizerCommon-asan-sparc-SunOS :: sanitizer_coverage_trace_pc_guard-dso.cpp SanitizerCommon-asan-sparc-SunOS :: sanitizer_coverage_trace_pc_guard.cpp ``` The issue is the same in both cases: ``` WARNING: No coverage file for projects/compiler-rt/test/sanitizer_common/asan-sparc-SunOS/Output/sanitizer_coverage_trace_pc_guard.cpp.tmp WARNING: No coverage file for sanitizer_coverage_trace_pc_guard.cpp.tmp.22766.sancov ERROR: No valid coverage files given. ``` Checking the file with `sancov -print` reveals `Wrong magic: 4294967090`. There seems to be an endianess bug somewhere, since the tests are already disabled on other big-endian targets. This patch matches this. Tested on `sparcv9-sun-solaris2.11`.
This was referenced Sep 11, 2024
…AIL`. In hindsight this is no wonder: while `compiler-rt/lib/asan/asan_mapping_sparc64.h` has support for the Linux/sparc64 VA hole, ``` commit 9df0754 Author: Vitaly Buka <[email protected]> Date: Tue Mar 12 21:02:24 2019 +0000 AddressSanitizer: 64-bit SPARC/Linux port ``` there's nothing corresponding in `clang`. Also, `gcc` disables 64-bit ASan on Linux/sparc64, too. So this patch disables `sparcv9` ASan testing in general. Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`
rorth
added a commit
to rorth/llvm-project
that referenced
this pull request
Sep 13, 2024
When SPARC Asan testing is enabled by PR llvm#107405, many Linux/sparc64 tests just hang like ``` #0 0xf7ae8e90 in syscall () from /usr/lib32/libc.so.6 #1 0x701065e8 in __sanitizer::FutexWait(__sanitizer::atomic_uint32_t*, unsigned int) () at compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:766 llvm#2 0x70107c90 in Wait () at compiler-rt/lib/sanitizer_common/sanitizer_mutex.cpp:35 llvm#3 0x700f7cac in Lock () at compiler-rt/lib/asan/../sanitizer_common/sanitizer_mutex.h:196 llvm#4 Lock () at compiler-rt/lib/asan/../sanitizer_common/sanitizer_thread_registry.h:98 llvm#5 LockThreads () at compiler-rt/lib/asan/asan_thread.cpp:489 llvm#6 0x700e9c8c in __asan::BeforeFork() () at compiler-rt/lib/asan/asan_posix.cpp:157 llvm#7 0xf7ac83f4 in ?? () from /usr/lib32/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) ``` It turns out that this happens in tests using `internal_fork` (e.g. invoking `llvm-symbolizer`): unlike most other Linux targets, which use `clone`, Linux/sparc64 has to use `__fork` instead. While `clone` doesn't trigger `pthread_atfork` handlers, `__fork` obviously does, causing the hang. To avoid this, this patch disables `InstallAtForkHandler` and lets the ASan tests run to completion. Tested on `sparc64-unknown-linux-gnu`.
|
@ebotcazou, any insight on the stage of 64-bit SPARC ASan support in |
|
I think that my last try was https://gcc.gnu.org/legacy-ml/gcc-patches/2019-03/msg00478.html |
rorth
added a commit
that referenced
this pull request
Sep 16, 2024
When SPARC Asan testing is enabled by PR #107405, many Linux/sparc64 tests just hang like ``` #0 0xf7ae8e90 in syscall () from /usr/lib32/libc.so.6 #1 0x701065e8 in __sanitizer::FutexWait(__sanitizer::atomic_uint32_t*, unsigned int) () at compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:766 #2 0x70107c90 in Wait () at compiler-rt/lib/sanitizer_common/sanitizer_mutex.cpp:35 #3 0x700f7cac in Lock () at compiler-rt/lib/asan/../sanitizer_common/sanitizer_mutex.h:196 #4 Lock () at compiler-rt/lib/asan/../sanitizer_common/sanitizer_thread_registry.h:98 #5 LockThreads () at compiler-rt/lib/asan/asan_thread.cpp:489 #6 0x700e9c8c in __asan::BeforeFork() () at compiler-rt/lib/asan/asan_posix.cpp:157 #7 0xf7ac83f4 in ?? () from /usr/lib32/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) ``` It turns out that this happens in tests using `internal_fork` (e.g. invoking `llvm-symbolizer`): unlike most other Linux targets, which use `clone`, Linux/sparc64 has to use `__fork` instead. While `clone` doesn't trigger `pthread_atfork` handlers, `__fork` obviously does, causing the hang. To avoid this, this patch disables `InstallAtForkHandler` and lets the ASan tests run to completion. Tested on `sparc64-unknown-linux-gnu`.
rorth
added a commit
that referenced
this pull request
Sep 16, 2024
#108206) …p etc. on SPARC When enabling ASan testing on SPARC as per PR #107405, two tests `FAIL`: ``` SanitizerCommon-asan-sparc-SunOS :: sanitizer_coverage_trace_pc_guard-dso.cpp SanitizerCommon-asan-sparc-SunOS :: sanitizer_coverage_trace_pc_guard.cpp ``` The issue is the same in both cases: ``` WARNING: No coverage file for projects/compiler-rt/test/sanitizer_common/asan-sparc-SunOS/Output/sanitizer_coverage_trace_pc_guard.cpp.tmp WARNING: No coverage file for sanitizer_coverage_trace_pc_guard.cpp.tmp.22766.sancov ERROR: No valid coverage files given. ``` Checking the file with `sancov -print` reveals `Wrong magic: 4294967090`. There seems to be an endianess bug somewhere, since the tests are already disabled on other big-endian targets. This patch matches this. Tested on `sparcv9-sun-solaris2.11`.
rorth
added a commit
that referenced
this pull request
Sep 16, 2024
When enabling ASan testing on SPARC as per PR #107405, two tests `FAIL` in similar ways as detailed in Issue #108194: at `-O1` and above, one line of the stacktrace lacks the line number info, causing the tests to `FAIL`. I could trace this to `clang` generating incomplete line number info; `g++` gets this right. To avoid this, this patch `XFAIL`s the affected tests on SPARC. Tested on `sparcv9-sun-solaris2.11`.
rorth
added a commit
to rorth/llvm-project
that referenced
this pull request
Sep 18, 2024
When ASan testing is enabled on SPARC as per PR llvm#107405, the ``` AddressSanitizer-sparc-sunos :: TestCases/Posix/stack-overflow.cpp ``` test `FAIL`s: ``` compiler-rt/test/asan/TestCases/Posix/stack-overflow.cpp:80:12: error: CHECK: expected string not found in input // CHECK: {{stack-overflow on address 0x.* \(pc 0x.* bp 0x.* sp 0x.* T.*\)}} ^ AddressSanitizer:DEADLYSIGNAL AddressSanitizer:DEADLYSIGNAL ================================================================= ==11358==ERROR: AddressSanitizer: SEGV on unknown address 0xff3fff90 (pc 0x000db0c0 bp 0xfeed59f8 sp 0xfeed5978 T0) ==11358==The signal is caused by a READ memory access. AddressSanitizer:DEADLYSIGNAL AddressSanitizer: nested bug in the same thread, aborting. ``` It turns out that `sanitizer_linux.cpp` (`GetPcSpBp`) tries to dereference the stack pointer to get at the saved frame pointer, which cannot work since `sp` has been invalidated by the stack overflow in the test. The access attempt thus leads to a second `SEGV`. Solaris `walkcontext(3C)` doesn't have that problem: in the original OpenSolaris sources (`$SRC/lib/libc/port/gen/walkstack.c`) they used `/proc/self/as` to avoid the fault, which is quite heavy-handed. Solaris 11.4 uses a non-faulting load instead (`load_no_fault_uint32`, which just uses the `lduwa` insn). This patch follows this lead, returning a `NULL` `bp` in the failure case. Unfortunately, this leads to `SEGV`s in the depth of the unwinder, so this patch avoids printing a stack trace in this case. Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`.
rorth
added a commit
to rorth/llvm-project
that referenced
this pull request
Sep 18, 2024
…ceptors When ASan testing is enabled on SPARC as per PR llvm#107405, a couple of tests `FAIL` on Linux/sparc64: ``` AddressSanitizer-sparc-linux :: TestCases/printf-2.c AddressSanitizer-sparc-linux :: TestCases/printf-3.c AddressSanitizer-sparc-linux :: TestCases/printf-4.c AddressSanitizer-sparc-linux :: TestCases/printf-5.c SanitizerCommon-asan-sparc-Linux :: Linux/unexpected_format_specifier_test.cpp ``` It turns out the interceptors aren't used since on Linux/sparc64 `double` and `long double` are the same, and a couple of `stdio` functions are prefixed with `__nldbl_` (no long double) accordingly. This patch handles this. Tested on `sparc64-unknown-linux-gnu`.
rorth
added a commit
that referenced
this pull request
Sep 24, 2024
#109101) When ASan testing is enabled on SPARC as per PR #107405, the ``` AddressSanitizer-sparc-sunos :: TestCases/Posix/stack-overflow.cpp ``` test `FAIL`s: ``` compiler-rt/test/asan/TestCases/Posix/stack-overflow.cpp:80:12: error: CHECK: expected string not found in input // CHECK: {{stack-overflow on address 0x.* \(pc 0x.* bp 0x.* sp 0x.* T.*\)}} ^ AddressSanitizer:DEADLYSIGNAL AddressSanitizer:DEADLYSIGNAL ================================================================= ==11358==ERROR: AddressSanitizer: SEGV on unknown address 0xff3fff90 (pc 0x000db0c0 bp 0xfeed59f8 sp 0xfeed5978 T0) ==11358==The signal is caused by a READ memory access. AddressSanitizer:DEADLYSIGNAL AddressSanitizer: nested bug in the same thread, aborting. ``` It turns out that `sanitizer_linux.cpp` (`GetPcSpBp`) tries to dereference the stack pointer to get at the saved frame pointer, which cannot work since `sp` has been invalidated by the stack overflow in the test. The access attempt thus leads to a second `SEGV`. Solaris `walkcontext(3C)` doesn't have that problem: in the original OpenSolaris sources (`$SRC/lib/libc/port/gen/walkstack.c`) they used `/proc/self/as` to avoid the fault, which is quite heavy-handed. Solaris 11.4 uses a non-faulting load instead (`load_no_fault_uint32`, which just uses the `lduwa` insn). This patch follows this lead, returning a `NULL` `bp` in the failure case. Unfortunately, this leads to `SEGV`s in the depth of the unwinder, so this patch avoids printing a stack trace in this case. Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`.
rorth
added a commit
that referenced
this pull request
Sep 24, 2024
#109106) …ceptors When ASan testing is enabled on SPARC as per PR #107405, a couple of tests `FAIL` on Linux/sparc64: ``` AddressSanitizer-sparc-linux :: TestCases/printf-2.c AddressSanitizer-sparc-linux :: TestCases/printf-3.c AddressSanitizer-sparc-linux :: TestCases/printf-4.c AddressSanitizer-sparc-linux :: TestCases/printf-5.c SanitizerCommon-asan-sparc-Linux :: Linux/unexpected_format_specifier_test.cpp ``` It turns out the interceptors aren't used since on Linux/sparc64 `double` and `long double` are the same, and a couple of `stdio` functions are prefixed with `__nldbl_` (no long double) accordingly. This patch handles this. Tested on `sparc64-unknown-linux-gnu`.
rorth
added a commit
that referenced
this pull request
Sep 24, 2024
When ASan testing is enabled on SPARC as per PR #107405, the ``` AddressSanitizer-sparc-linux :: TestCases/Posix/print_cmdline.cpp ``` test `FAIL`s. Either `ASAN_OPTIONS=print_cmdline=true` yielded binary garbage in the `Command:` output or just an empty string. It turns out one needs to apply an offset to `__libc_stack_end` to get at the actual `argc`/`argv`, as described in `glibc`'s `sysdeps/sparc/sparc{32,64}/dl-machine.h` (`DL_STACK_END`). This patch does this, fixing the test. Tested on `sparc64-unknown-linux-gnu`.
rorth
added a commit
that referenced
this pull request
Sep 24, 2024
With ASan testing enabled on SPARC as per PR #107405, the ``` AddressSanitizer-sparc-sunos-dynamic :: TestCases/Posix/coverage-fork.cpp ``` test occasionally `FAIL`s on Solaris/sparcv9: ``` compiler-rt/test/asan/TestCases/Posix/coverage-fork.cpp:46:15: error: CHECK-DAG: expected string not found in input // CHECK-DAG: Parent PID: [[ParentPID:[0-9]+]] ^ ``` It turns out that the output for parent and child processes is interleaved like ``` Parent PID: Child PID: 27426 27425 ``` Checking with `truss` shows that the `fprintf`s are implemented as 3 separate `write`s: ``` 28489: write(2, " P a r e n t P I D : ", 12) = 12 28489: write(2, " 2 8 4 8 9", 5) = 5 28489: write(2, "\n", 1) = 1 ``` To avoid this, this patch switches the test to use `snprintf`/`write` to guarantee the output is atomic. Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and `x86_64-pc-linux-gnu`.
rorth
added a commit
to rorth/llvm-project
that referenced
this pull request
Sep 24, 2024
When enabling ASan SPARC testing as per PR llvm#107405, 3 stack overflow tests `FAIL` on Linux/sparc64: ``` AddressSanitizer-sparc-linux :: TestCases/Linux/stack-overflow-recovery-mode.cpp AddressSanitizer-sparc-linux :: TestCases/Linux/stack-overflow-sigbus.cpp AddressSanitizer-sparc-linux :: TestCases/Posix/stack-overflow.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Linux/stack-overflow-recovery-mode.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Linux/stack-overflow-sigbus.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Posix/stack-overflow.cpp ``` However, as detailed in Issue llvm#109771, even a Linux equivalent of the Solaris/sparcv9 fix (PR llvm#109101) doesn't improve the situation. Therefore this patch `XFAIL`s the tests until the root cause can be figured out. Tested on `sparc64-unknown-linux-gnu`, `sparcv9-sun-solaris2.11`, and `x86_64-pc-linux-gnu`.
rorth
added a commit
that referenced
this pull request
Sep 25, 2024
When enabling ASan SPARC testing as per PR #107405, 3 stack overflow tests `FAIL` on Linux/sparc64: ``` AddressSanitizer-sparc-linux :: TestCases/Linux/stack-overflow-recovery-mode.cpp AddressSanitizer-sparc-linux :: TestCases/Linux/stack-overflow-sigbus.cpp AddressSanitizer-sparc-linux :: TestCases/Posix/stack-overflow.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Linux/stack-overflow-recovery-mode.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Linux/stack-overflow-sigbus.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Posix/stack-overflow.cpp ``` However, as detailed in Issue #109771, even a Linux equivalent of the Solaris/sparcv9 fix (PR #109101) doesn't improve the situation. Therefore this patch `XFAIL`s the tests until the root cause can be figured out. Tested on `sparc64-unknown-linux-gnu`, `sparcv9-sun-solaris2.11`, and `x86_64-pc-linux-gnu`.
augusto2112
pushed a commit
to augusto2112/llvm-project
that referenced
this pull request
Sep 26, 2024
…vm#109623) With ASan testing enabled on SPARC as per PR llvm#107405, the ``` AddressSanitizer-sparc-linux-dynamic :: TestCases/Linux/preinstalled_signal.cpp ``` test `FAIL`s on Linux/sparc64. See Issue llvm#109573 for all the details, but the core is that `syscall(__NR_rt_sigaction)` cannot be used because it takes an additional argument that isn't accessible outside of `libc`, while switching to `sigaction` instead changes the order of `AsanInitInternal` and `Init`, breaking the test. Therefore this patch `XFAIL`s the test. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
augusto2112
pushed a commit
to augusto2112/llvm-project
that referenced
this pull request
Sep 26, 2024
llvm#109101) When ASan testing is enabled on SPARC as per PR llvm#107405, the ``` AddressSanitizer-sparc-sunos :: TestCases/Posix/stack-overflow.cpp ``` test `FAIL`s: ``` compiler-rt/test/asan/TestCases/Posix/stack-overflow.cpp:80:12: error: CHECK: expected string not found in input // CHECK: {{stack-overflow on address 0x.* \(pc 0x.* bp 0x.* sp 0x.* T.*\)}} ^ AddressSanitizer:DEADLYSIGNAL AddressSanitizer:DEADLYSIGNAL ================================================================= ==11358==ERROR: AddressSanitizer: SEGV on unknown address 0xff3fff90 (pc 0x000db0c0 bp 0xfeed59f8 sp 0xfeed5978 T0) ==11358==The signal is caused by a READ memory access. AddressSanitizer:DEADLYSIGNAL AddressSanitizer: nested bug in the same thread, aborting. ``` It turns out that `sanitizer_linux.cpp` (`GetPcSpBp`) tries to dereference the stack pointer to get at the saved frame pointer, which cannot work since `sp` has been invalidated by the stack overflow in the test. The access attempt thus leads to a second `SEGV`. Solaris `walkcontext(3C)` doesn't have that problem: in the original OpenSolaris sources (`$SRC/lib/libc/port/gen/walkstack.c`) they used `/proc/self/as` to avoid the fault, which is quite heavy-handed. Solaris 11.4 uses a non-faulting load instead (`load_no_fault_uint32`, which just uses the `lduwa` insn). This patch follows this lead, returning a `NULL` `bp` in the failure case. Unfortunately, this leads to `SEGV`s in the depth of the unwinder, so this patch avoids printing a stack trace in this case. Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`.
augusto2112
pushed a commit
to augusto2112/llvm-project
that referenced
this pull request
Sep 26, 2024
llvm#109106) …ceptors When ASan testing is enabled on SPARC as per PR llvm#107405, a couple of tests `FAIL` on Linux/sparc64: ``` AddressSanitizer-sparc-linux :: TestCases/printf-2.c AddressSanitizer-sparc-linux :: TestCases/printf-3.c AddressSanitizer-sparc-linux :: TestCases/printf-4.c AddressSanitizer-sparc-linux :: TestCases/printf-5.c SanitizerCommon-asan-sparc-Linux :: Linux/unexpected_format_specifier_test.cpp ``` It turns out the interceptors aren't used since on Linux/sparc64 `double` and `long double` are the same, and a couple of `stdio` functions are prefixed with `__nldbl_` (no long double) accordingly. This patch handles this. Tested on `sparc64-unknown-linux-gnu`.
augusto2112
pushed a commit
to augusto2112/llvm-project
that referenced
this pull request
Sep 26, 2024
When ASan testing is enabled on SPARC as per PR llvm#107405, the ``` AddressSanitizer-sparc-linux :: TestCases/Posix/print_cmdline.cpp ``` test `FAIL`s. Either `ASAN_OPTIONS=print_cmdline=true` yielded binary garbage in the `Command:` output or just an empty string. It turns out one needs to apply an offset to `__libc_stack_end` to get at the actual `argc`/`argv`, as described in `glibc`'s `sysdeps/sparc/sparc{32,64}/dl-machine.h` (`DL_STACK_END`). This patch does this, fixing the test. Tested on `sparc64-unknown-linux-gnu`.
augusto2112
pushed a commit
to augusto2112/llvm-project
that referenced
this pull request
Sep 26, 2024
With ASan testing enabled on SPARC as per PR llvm#107405, the ``` AddressSanitizer-sparc-sunos-dynamic :: TestCases/Posix/coverage-fork.cpp ``` test occasionally `FAIL`s on Solaris/sparcv9: ``` compiler-rt/test/asan/TestCases/Posix/coverage-fork.cpp:46:15: error: CHECK-DAG: expected string not found in input // CHECK-DAG: Parent PID: [[ParentPID:[0-9]+]] ^ ``` It turns out that the output for parent and child processes is interleaved like ``` Parent PID: Child PID: 27426 27425 ``` Checking with `truss` shows that the `fprintf`s are implemented as 3 separate `write`s: ``` 28489: write(2, " P a r e n t P I D : ", 12) = 12 28489: write(2, " 2 8 4 8 9", 5) = 5 28489: write(2, "\n", 1) = 1 ``` To avoid this, this patch switches the test to use `snprintf`/`write` to guarantee the output is atomic. Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and `x86_64-pc-linux-gnu`.
augusto2112
pushed a commit
to augusto2112/llvm-project
that referenced
this pull request
Sep 26, 2024
When enabling ASan SPARC testing as per PR llvm#107405, 3 stack overflow tests `FAIL` on Linux/sparc64: ``` AddressSanitizer-sparc-linux :: TestCases/Linux/stack-overflow-recovery-mode.cpp AddressSanitizer-sparc-linux :: TestCases/Linux/stack-overflow-sigbus.cpp AddressSanitizer-sparc-linux :: TestCases/Posix/stack-overflow.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Linux/stack-overflow-recovery-mode.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Linux/stack-overflow-sigbus.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Posix/stack-overflow.cpp ``` However, as detailed in Issue llvm#109771, even a Linux equivalent of the Solaris/sparcv9 fix (PR llvm#109101) doesn't improve the situation. Therefore this patch `XFAIL`s the tests until the root cause can be figured out. Tested on `sparc64-unknown-linux-gnu`, `sparcv9-sun-solaris2.11`, and `x86_64-pc-linux-gnu`.
rorth
added a commit
that referenced
this pull request
Sep 30, 2024
When ASan testing is enabled on SPARC as per PR #107405, the ``` AddressSanitizer-sparc-linux :: TestCases/Linux/ptrace.cpp ``` `FAIL`s on Linux/sparc64. This happens because the `ptrace` interceptor has no support for that target at all. This patch adds the missing parts and accounts for a couple of issues specific to this target: - In some cases, SPARC just needs to be included in the list of supported targets. - Besides, the types used by the `PTRACE_GETREGS` and `PTRACE_GETFPREGS` requests need to be filled in. - `ptrace` has a weird quirk on this target: for a couple of requests, the meaning of the `data` and `addr` args is reversed. All of the `Linux/ptrace.cpp` test and the interceptor, pre-syscall and post-syscall hooks need to account for that swap in their checks. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
xgupta
pushed a commit
to xgupta/llvm-project
that referenced
this pull request
Oct 4, 2024
…vm#109623) With ASan testing enabled on SPARC as per PR llvm#107405, the ``` AddressSanitizer-sparc-linux-dynamic :: TestCases/Linux/preinstalled_signal.cpp ``` test `FAIL`s on Linux/sparc64. See Issue llvm#109573 for all the details, but the core is that `syscall(__NR_rt_sigaction)` cannot be used because it takes an additional argument that isn't accessible outside of `libc`, while switching to `sigaction` instead changes the order of `AsanInitInternal` and `Init`, breaking the test. Therefore this patch `XFAIL`s the test. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
xgupta
pushed a commit
to xgupta/llvm-project
that referenced
this pull request
Oct 4, 2024
llvm#109101) When ASan testing is enabled on SPARC as per PR llvm#107405, the ``` AddressSanitizer-sparc-sunos :: TestCases/Posix/stack-overflow.cpp ``` test `FAIL`s: ``` compiler-rt/test/asan/TestCases/Posix/stack-overflow.cpp:80:12: error: CHECK: expected string not found in input // CHECK: {{stack-overflow on address 0x.* \(pc 0x.* bp 0x.* sp 0x.* T.*\)}} ^ AddressSanitizer:DEADLYSIGNAL AddressSanitizer:DEADLYSIGNAL ================================================================= ==11358==ERROR: AddressSanitizer: SEGV on unknown address 0xff3fff90 (pc 0x000db0c0 bp 0xfeed59f8 sp 0xfeed5978 T0) ==11358==The signal is caused by a READ memory access. AddressSanitizer:DEADLYSIGNAL AddressSanitizer: nested bug in the same thread, aborting. ``` It turns out that `sanitizer_linux.cpp` (`GetPcSpBp`) tries to dereference the stack pointer to get at the saved frame pointer, which cannot work since `sp` has been invalidated by the stack overflow in the test. The access attempt thus leads to a second `SEGV`. Solaris `walkcontext(3C)` doesn't have that problem: in the original OpenSolaris sources (`$SRC/lib/libc/port/gen/walkstack.c`) they used `/proc/self/as` to avoid the fault, which is quite heavy-handed. Solaris 11.4 uses a non-faulting load instead (`load_no_fault_uint32`, which just uses the `lduwa` insn). This patch follows this lead, returning a `NULL` `bp` in the failure case. Unfortunately, this leads to `SEGV`s in the depth of the unwinder, so this patch avoids printing a stack trace in this case. Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`.
xgupta
pushed a commit
to xgupta/llvm-project
that referenced
this pull request
Oct 4, 2024
llvm#109106) …ceptors When ASan testing is enabled on SPARC as per PR llvm#107405, a couple of tests `FAIL` on Linux/sparc64: ``` AddressSanitizer-sparc-linux :: TestCases/printf-2.c AddressSanitizer-sparc-linux :: TestCases/printf-3.c AddressSanitizer-sparc-linux :: TestCases/printf-4.c AddressSanitizer-sparc-linux :: TestCases/printf-5.c SanitizerCommon-asan-sparc-Linux :: Linux/unexpected_format_specifier_test.cpp ``` It turns out the interceptors aren't used since on Linux/sparc64 `double` and `long double` are the same, and a couple of `stdio` functions are prefixed with `__nldbl_` (no long double) accordingly. This patch handles this. Tested on `sparc64-unknown-linux-gnu`.
xgupta
pushed a commit
to xgupta/llvm-project
that referenced
this pull request
Oct 4, 2024
When ASan testing is enabled on SPARC as per PR llvm#107405, the ``` AddressSanitizer-sparc-linux :: TestCases/Posix/print_cmdline.cpp ``` test `FAIL`s. Either `ASAN_OPTIONS=print_cmdline=true` yielded binary garbage in the `Command:` output or just an empty string. It turns out one needs to apply an offset to `__libc_stack_end` to get at the actual `argc`/`argv`, as described in `glibc`'s `sysdeps/sparc/sparc{32,64}/dl-machine.h` (`DL_STACK_END`). This patch does this, fixing the test. Tested on `sparc64-unknown-linux-gnu`.
xgupta
pushed a commit
to xgupta/llvm-project
that referenced
this pull request
Oct 4, 2024
With ASan testing enabled on SPARC as per PR llvm#107405, the ``` AddressSanitizer-sparc-sunos-dynamic :: TestCases/Posix/coverage-fork.cpp ``` test occasionally `FAIL`s on Solaris/sparcv9: ``` compiler-rt/test/asan/TestCases/Posix/coverage-fork.cpp:46:15: error: CHECK-DAG: expected string not found in input // CHECK-DAG: Parent PID: [[ParentPID:[0-9]+]] ^ ``` It turns out that the output for parent and child processes is interleaved like ``` Parent PID: Child PID: 27426 27425 ``` Checking with `truss` shows that the `fprintf`s are implemented as 3 separate `write`s: ``` 28489: write(2, " P a r e n t P I D : ", 12) = 12 28489: write(2, " 2 8 4 8 9", 5) = 5 28489: write(2, "\n", 1) = 1 ``` To avoid this, this patch switches the test to use `snprintf`/`write` to guarantee the output is atomic. Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and `x86_64-pc-linux-gnu`.
xgupta
pushed a commit
to xgupta/llvm-project
that referenced
this pull request
Oct 4, 2024
When enabling ASan SPARC testing as per PR llvm#107405, 3 stack overflow tests `FAIL` on Linux/sparc64: ``` AddressSanitizer-sparc-linux :: TestCases/Linux/stack-overflow-recovery-mode.cpp AddressSanitizer-sparc-linux :: TestCases/Linux/stack-overflow-sigbus.cpp AddressSanitizer-sparc-linux :: TestCases/Posix/stack-overflow.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Linux/stack-overflow-recovery-mode.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Linux/stack-overflow-sigbus.cpp AddressSanitizer-sparc-linux-dynamic :: TestCases/Posix/stack-overflow.cpp ``` However, as detailed in Issue llvm#109771, even a Linux equivalent of the Solaris/sparcv9 fix (PR llvm#109101) doesn't improve the situation. Therefore this patch `XFAIL`s the tests until the root cause can be figured out. Tested on `sparc64-unknown-linux-gnu`, `sparcv9-sun-solaris2.11`, and `x86_64-pc-linux-gnu`.
xgupta
pushed a commit
to xgupta/llvm-project
that referenced
this pull request
Oct 4, 2024
When ASan testing is enabled on SPARC as per PR llvm#107405, the ``` AddressSanitizer-sparc-linux :: TestCases/Linux/ptrace.cpp ``` `FAIL`s on Linux/sparc64. This happens because the `ptrace` interceptor has no support for that target at all. This patch adds the missing parts and accounts for a couple of issues specific to this target: - In some cases, SPARC just needs to be included in the list of supported targets. - Besides, the types used by the `PTRACE_GETREGS` and `PTRACE_GETFPREGS` requests need to be filled in. - `ptrace` has a weird quirk on this target: for a couple of requests, the meaning of the `data` and `addr` args is reversed. All of the `Linux/ptrace.cpp` test and the interceptor, pre-syscall and post-syscall hooks need to account for that swap in their checks. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
rorth
changed the title
|
This patch is ready to go once PR #107223 is in. |
|
@rorth Ping. |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/30/builds/9448 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/4/builds/3322 Here is the relevant piece of the build log for the reference |
PhilippRados
pushed a commit
to PhilippRados/llvm-project
that referenced
this pull request
Nov 6, 2024
With PR llvm#107223 and PR llvm#107403, ASan testing can be enabled on SPARC. This patch does so, 32-bit only on both Solaris and Linux. There is no 64-bit support even in GCC. Apart from the obvious CMake changes, this patch includes a couple of testcase adjustments necessary for SPARC: - In `asan_oob_test.cpp`, the `OOB_int` subtest needs to be disabled: it performs unaligned accesses that cannot work on a strict-alignment target like SPARC. - `asan_test.cpp` needs to disable subtests that depend on support for `__builtin_setjmp` and `__builtin_longjmp`. - `zero_page_pc.cpp` reports `0x5` as the faulting address on access to `0x4`. I don't really know why, but it's consistent between Solaris and Linux. Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With PR #107223 and PR #107403, ASan testing can be enabled on SPARC. This patch does so, 32-bit only on both Solaris and Linux. There is no 64-bit support even in GCC.
Apart from the obvious CMake changes, this patch includes a couple of testcase adjustments necessary for SPARC:
asan_oob_test.cpp, theOOB_intsubtest needs to be disabled: it performs unaligned accesses that cannot work on a strict-alignment target like SPARC.asan_test.cppneeds to disable subtests that depend on support for__builtin_setjmpand__builtin_longjmp.zero_page_pc.cppreports0x5as the faulting address on access to0x4. I don't really know why, but it's consistent between Solaris and Linux.Tested on
sparcv9-sun-solaris2.11andsparc64-unknown-linux-gnu.