[sanitizer_common] Don't use syscall(SYS_clone) on Linux/sparc64 #100534
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
``` SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerCommon/StartSubprocessTest ``` and every single test using the `llvm-symbolizer` `FAIL` on Linux/sparc64 in a very weird way: when using `StartSubprocess`, there's a call to `internal_fork`, but we never reach `internal_execve`. `internal_fork` is implemented using `syscall(SYS_clone)`. The calling convention of that syscall already varies considerably between targets, but as documented in `clone(2)`, SPARC again is widely different. Instead of trying to match `glibc` here, this patch just calls `__fork`. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
|
@llvm/pr-subscribers-compiler-rt-sanitizer Author: Rainer Orth (rorth) Changesand every single test using the Tested on Full diff: https://github.com/llvm/llvm-project/pull/100534.diff 1 Files Affected:
diff --git a/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp b/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
index 483a1042a6238..49f57b3404fbc 100644
--- a/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
+++ b/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
@@ -826,10 +826,16 @@ uptr internal_sigaltstack(const void *ss, void *oss) {
return internal_syscall(SYSCALL(sigaltstack), (uptr)ss, (uptr)oss);
}
+extern "C" pid_t __fork(void);
+
int internal_fork() {
# if SANITIZER_LINUX
# if SANITIZER_S390
return internal_syscall(SYSCALL(clone), 0, SIGCHLD);
+# elif SANITIZER_SPARC
+ // The clone syscall interface on SPARC differs massively from the rest,
+ // so fall back to __fork.
+ return __fork();
# else
return internal_syscall(SYSCALL(clone), SIGCHLD, 0);
# endif
|
vitalybuka
approved these changes
Jul 29, 2024
|
/cherry-pick 1c53b90 |
llvmbot
pushed a commit
to llvmbot/llvm-project
that referenced
this pull request
Jul 30, 2024
…m#100534) ``` SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerCommon/StartSubprocessTest ``` and every single test using the `llvm-symbolizer` `FAIL` on Linux/sparc64 in a very weird way: when using `StartSubprocess`, there's a call to `internal_fork`, but we never reach `internal_execve`. `internal_fork` is implemented using `syscall(SYS_clone)`. The calling convention of that syscall already varies considerably between targets, but as documented in `clone(2)`, SPARC again is widely different. Instead of trying to match `glibc` here, this patch just calls `__fork`. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`. (cherry picked from commit 1c53b90)
|
/pull-request #101137 |
banach-space
pushed a commit
to banach-space/llvm-project
that referenced
this pull request
Aug 7, 2024
…m#100534) ``` SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerCommon/StartSubprocessTest ``` and every single test using the `llvm-symbolizer` `FAIL` on Linux/sparc64 in a very weird way: when using `StartSubprocess`, there's a call to `internal_fork`, but we never reach `internal_execve`. `internal_fork` is implemented using `syscall(SYS_clone)`. The calling convention of that syscall already varies considerably between targets, but as documented in `clone(2)`, SPARC again is widely different. Instead of trying to match `glibc` here, this patch just calls `__fork`. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
tru
pushed a commit
to llvmbot/llvm-project
that referenced
this pull request
Aug 10, 2024
…m#100534) ``` SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerCommon/StartSubprocessTest ``` and every single test using the `llvm-symbolizer` `FAIL` on Linux/sparc64 in a very weird way: when using `StartSubprocess`, there's a call to `internal_fork`, but we never reach `internal_execve`. `internal_fork` is implemented using `syscall(SYS_clone)`. The calling convention of that syscall already varies considerably between targets, but as documented in `clone(2)`, SPARC again is widely different. Instead of trying to match `glibc` here, this patch just calls `__fork`. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`. (cherry picked from commit 1c53b90)
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.
and every single test using the
llvm-symbolizerFAILon Linux/sparc64 in a very weird way: when usingStartSubprocess, there's a call tointernal_fork, but we never reachinternal_execve.internal_forkis implemented usingsyscall(SYS_clone). The calling convention of that syscall already varies considerably between targets, but as documented inclone(2), SPARC again is widely different. Instead of trying to matchglibchere, this patch just calls__fork.Tested on
sparc64-unknown-linux-gnuandx86_64-pc-linux-gnu.