Messages in this thread | | | Date | Tue, 26 Oct 1999 15:02:00 -0500 | From | Brian Grayson <> | Subject | ptrace in glibc vs. ptrace syscall |
| |
I notice that the ptrace() function in glibc is hard-coded to only deal with 32-bit data, and that it returns the data on peeks (which goes against the man page for the ptrace syscall).
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/
| |