> 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.
What's the problem? Why is it not working?
> 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!
The man page has been corrected already - wait for the next man-page
version.
Please note that these are not kernel problems - but glibc and manual
issues. Let's continue the discussion privatly.
Andreas
-- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de- 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/