Reworked trace-loop & adding support for the 27 syscalls from 424 to 450 #26
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.
Heya, this PR lays some first groundwork in order to get to tracing parity with
strace
itself.I've rewritten the main tracing-loop, to more robustly handle signals and the various other
ptrace
events (documented in code for now). It's still far fromstrace
's main tracing-loop, but already manages to fix some important bugs.exit
andexit_group
are now properly handled.-f, --follow-forks
now actually follows forks.-f
is not supplied.Some notes of things that aren't yet (properly) implemented:
Signals are passed to the child via
ptrace(PTRACE_CONT, ...)
.This needs some work (more complex fall-through logic for
WIFSTOPPED(status)
and various other edge-cases).exec
-family syscalls can't report their arguments.lurk
usesexec
fromstd::os::unix::process
to load it's tracee into the forked process. Thisexec
fromstd::os::unix::process
issues various other syscalls (likedup2
) before actuallyexecve
'ing. This makes it quite hard to properly implement logic to catch the arguments of anyexec
-family syscall. The usual trick to justkill(getpid(), SIGSTOP)
after aptrace(PTRACE_TRACEME, ...)
request to give the parent a chance to catch theexecve
, won't do it in this case.seccomp
Additionaly I've also added the missing 27 syscalls from number 424 to 450.
Due to the syscall gap from 334 to 424 the solution's probably a bit iffy, but it works. Refactoring definitely welcome. This fixes #24 and probably a bunch of other binaries which rely on these newer syscalls.