Messages in this thread | | | Date | Fri, 27 Jun 2008 13:50:09 -0400 | From | Jeff Dike <> | Subject | Re: [PATCH 0/1] ptrace_vm: let us simplify the code for ptrace and add useful features for VM |
| |
On Sun, Jun 22, 2008 at 11:11:02AM +0200, Renzo Davoli wrote: > There are three events for a syscall: > START - call notification > CALL - run the SYSCALL > EXIT - return notification. > > I think that it is a non sense to write code for useless cases. > Let us see all the combinations of doing/skipping each one of the three > phases: > > 0- DOSTART - DOCALL - DOEXIT - Standard PTRACE_SYSCALL (new option 0) > 1- DOSTART - DOCALL - SKIPEXIT - PTRACE_VM_SKIPEXIT of my proposal > 2- DOSTART - SKIPCALL - DOEXIT - useless, nothing has changed between > the two notifications > 3- DOSTART - SKIPCALL - SKIPEXIT - PTRACE_VM_SKIPCALL in my proposal > 4- SKIPSTART - DOCALL - DOEXIT - is this useful? (Case 4,see below) > 5- SKIPSTART - DOCALL - SKIPEXIT - simply don't use PTRACE_SYSCALL > 6- SKIPSTART - SKIPCALL - DOEXIT - this is the old PTRACE_SYSEMU (case 6) > 7- SKIPSTART - SKIPCALL - SKIPEXIT - nullify completely the syscalls > (case 7). > > case 4: a vm or debugging monitor receives just the return value of a > syscall. In many architectures it not even possible to read the parameters > of the call (e.g. powerpc where the first argument and the return value > use the same register). This choice must be done a-priori, so without > actually know which will be the next system call.
I can see this being useful - this is kind of what strace wants, except that it wouldn't be able to see that a system call is about to sleep. This could be implemented by just stashing any trashed registers off to the side ala x86 orig_eax.
> case 6: this makes sense just for applications which virtualize *all* the > system call, current PTRACE_SYSEMU works exactly in this way. > My patch shows that for these applications it does not matter whether the > virtualization takes place before skipping the call or after having just > skipped the call. So PTRACE_VM_SKIPCALL can be used instead.
Yup.
> case 7: skip the next syscall and give no information about, there is no way > to virtualize or trace what is going on. > Who could be ever interested in an option like this?
No one.
> It seems that the combinations that really make sense are those skipping > a trailing part of the sequence. > > DOSTART - DOCALL - DOEXIT my option 0 > DOSTART - DOCALL - SKIPEXIT my option PTRACE_VM_SKIPEXIT > DOSTART - SKIPCALL - SKIPEXIT my option PTRACE_VM_SKIPCALL
Seems reasonable. In this case, they should be numbered 0, 1, 2 rather than having masks or-ed together. This happens to produce the same numbers, except that 3 is outlawed.
> If you think that it is not clear from the tag name that PTRACE_VM_SKIPCALL > implies PTRACE_VM_SKIPEXIT let us change the name in: > PTRACE_VM_SKIPCALL_SKIPEXIT > Maybe the name is quite long, but in this way it is clear what it > does.
Maybe. How about PTRACE_VM_TRACESTART? Makes the naming somewhat non-orthogonal, but shorter and descriptive.
Jeff
-- Work email - jdike at linux dot intel dot com
| |