aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h
diff options
context:
space:
mode:
authorRainer Orth <ro@gcc.gnu.org>2024-07-30 08:57:25 +0200
committerGitHub <noreply@github.com>2024-07-30 08:57:25 +0200
commit1c53b907bd6348138a59da270836fc9b4c161a07 (patch)
treee71699c7345a53669ad8c8ef8b2a80da701843c6 /lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h
parent9eefe065bb2752b0db9ed553d2406e9a15ce349e (diff)
downloadllvm-1c53b907bd6348138a59da270836fc9b4c161a07.zip
llvm-1c53b907bd6348138a59da270836fc9b4c161a07.tar.gz
llvm-1c53b907bd6348138a59da270836fc9b4c161a07.tar.bz2
[sanitizer_common] Don't use syscall(SYS_clone) on Linux/sparc64 (#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`.
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h')
0 files changed, 0 insertions, 0 deletions