For performance reasons, there are times when it would be handy
to do ptrace(PT_GETREGS, ...) or ptrace(PT_SETREGS, ...), i.e.,
read/write more than one word in one syscall what would
otherwise require ~32 syscalls.
I figure there must be a good reason that the glibc interface
was written the way it was. Does anyone know what it is? :) Is
there a good reason to not extend it to allow multi-word
transfers, say, if the ptrace command is higher than
PTRACE_DETACH (which would preserve full backwards compatibility)?
Similarly, is there a good reason that the glibc ptrace doesn't
return the syscall return code for the PEEK operations? It might
be a convenient programming paradigm, but having a function that
sometimes returns the syscall return code, and sometimes returns
a value (which may be -1), just seems Evil to me. It's already
bitten me and others, since it violates the man page for ptrace!
Thanks.
Brian Grayson
-
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/