On 08/07/2007 06:43 PM, Eelis van der Weegen wrote: > How can a parent process intercepting a ptraced child's system calls using > PTRACE_SYSCALL know which SIGTRAP's are system call entries and which are > system > call exits? > > Since there does not seem to be a way for the parent to get this information > from the system, ptrace examples floating around on the web generally use a > boolean in_syscall flag that they toggle at each SIGTRAP. This mechanism seems > perfectly adequate, but for it to work correctly the flag must obviously be > appropriately initialized, and that is where things get vague. > > Let's assume that the child's ptrace-ing begins after it first does > PTRACE_TRACEME and then calls execve. According to the ptrace man page, after > doing PTRACE_TRACEME "all subsequent calls to exec() by this process will > cause > a SIGTRAP to be sent to it, giving the parent a chance to gain control before > the new program begins execution". The problem is that this does not specify > whether the parent will see SIGTRAP's for both entry to and exit from execve, > or > only for exit from it. To my great surprise, I observed both behaviors on > actual > machines (in particular, I observed the former on an x86_64 dual core > machine). > > This inconsistency foils the in_syscall flag approach, as there is no way to > know whether the parent should initialize that flag to true or false (since > apparently both can occur). Hence, my question is: is this behavior > intentional? > Should there not be a guarantee that /either/ only the execve exit, /or/ both > entry and exit, are SIGTRAPed? >
Did you try PTRACE_SETOPTIONS and set PTRACE_O_TRACEEXEC? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
