Messages in this thread | | | Date | Sun, 11 Apr 1999 11:16:17 -0400 | From | mukesh agrawal <> | Subject | Re: PTRACE_SYSCALL questions |
| |
At 9:57 AM -0400 4/7/99, Daniel Nash wrote:
Hi.
[Daniel] >Does it seem reasonable to change the test to check against PF_PTRACED, >and have the slow path then check for PF_TRACESYS, or any other >necessary flag(s) both before and after the system call itself? This >would only slow down ptraced programs, and then only by a small amount.
[Michael] >>But I think you can just do everything you want in user-space anyways. >>Why don't you just turn on PF_TRACESYS at the beginning of execution, >>and then keep your own state in your parent process about which traps >>to take action on and which to pass through?
[Daniel] >Unfortunately, for my purposes, this is far too slow. Two traps per >system call would kill any performance my program has. I'd be happy to >find a user space solution to this which didn't require PF_TRACESYS to >be on for the entire execution of the program, though.
I've been playing around with ptrace a little bit myself, and have some changes that might be what you're looking for. I don't think they affect the fast path.
Specifically, the changes I have allow you to - specify that you are only interested in certain system calls - specify that you only want to be trapped if the system call fails - specify that you only want to be trapped at entry, or failure, or exit (or any combination you specify) they also provide a crude implementation of block copies, and some other miscellaneous stuff.
If you'd like, I can send you a diff against 2.0.36 (it shouldn't be too much work to bring it to 2.2.x if that's what you're working with).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |