I understand that strace
command uses ptrace(PTRACE_PEEKUSER, child, __builtin_offsetof(struct user, regs.orig_eax))
to find the index of a system call the tracee child is trapped at. Then to translate the index into the syscall function name, it has built up tables made from grepping the linux source code headers present in the installation.
This method must be undocumented and prone to failure because the location and syntax of source code declarations are not documented, must be found by grepping and may change in unknown ways. Am I correct to say that?
If that is so, then why would strace
not use the following method, with seems to me, is simpler, relies only on documentation and is thus foolproof.
At the start of the first run after reboot, strace
sends out a test syscall, one for each syscall function, traps that, and observes what syscall index that child uses. That gives a complete and correct custom table which can be stored in a file known to further invocations of strace
.
I am sure this method must have been considered, as it is not anything particularly ingenious. So there must be something wrong with it. What is wrong??
open(foobar.txt, O_RDONLY)
no undocumented stuff neededstrace
I believe). So I need to make sure if I store the table, because I don't want to compute it each timestrace
is called, then it is wiped out upon reboot. Surely there must be a way in Linux to tell, whether I am being called first time after reboot. Surely there must be some file which is touched/created upon reboot, so that I can compare my timestamp with it?open(foobar.txt, O_RDONLY)
results in exactly one syscall and that'sSYS_open
? It might useSYS_openat
. It might result in other system calls taking place as part of lazy binding in the dynamic linker, if this is the first call toopen
. Or it might involve other system calls internally for some other purpose. There is no trivial one-to-one mapping you can assume between library calls and system calls.