| Issue |
109573
|
| Summary |
Linux/preinstalled_signal.cpp FAILs on Linux/sparc64
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
rorth
|
With ASan testing enabled on SPARC as per PR #107405, the
```
AddressSanitizer-sparc-linux-dynamic :: TestCases/Linux/preinstalled_signal.cpp
```
test `FAIL`s on Linux/sparc64. There are several issues here:
- The sparc layout of `struct KernelSigaction`/`struct sigaction` differs from other targets:`
```
@@ -34,6 +34,13 @@ struct KernelSigaction {
#if defined(__mips__)
unsigned long flags;
__sighandler_t handler;
+#elif defined(__sparc__)
+ __sighandler_t handler;
+ __sigset_t mask;
+# if __WORDSIZE == 64
+ int __glibc_reserved0;
+# endif
+ int flags;
#else
__sighandler_t handler;
unsigned long flags;
```
- When using `syscall(__NR_rt_sigaction)`, the `syscall` returns `EINVAL`. As can be seen in glibc `sysdeps/unix/sysv/linux/sparc/sparc{32,64}/libc_sigaction.c` (`STUB)`, the sparc version of the syscall takes an additional arg, however the stub functions passed there aren't exported from `libc` and thus cannot be used outside.
- When using `sigaction` instead, several assertions fail. The problem turns out to be that those `sigaction` calls trigger the interceptor, which again changes the order in which `AsanInitInternal` and `Init` are called.
- The same behaviour can be seen e.g. on Linux/i386 when using `sigaction` instead of `syscall(__NR_rt_sigaction)`.
It seems the test relies heavily on the (undefined!?) relative execution order of `AsanInitInternal` `and `Init`, falling apart if that
changes for whatever reason.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
