Hi Roland, David !
I noticed kernel/ptrace.c has ptrace_readdata/writedata functions that
are only used by sparc and sparc64 which implements the ptrace requests
PTRACE_READ_DATA, PTRACE_WRITE_DATA (and _TEXT variants).
Any reason not to make everybody benefit from these and moving the sparc
implementation to the generic ptrace_request (&compat) ?
It's more efficient than read/writing one word at a time... I thought
about it in the light of some work Rik is doing to make
access_process_vm useable on video ram mappings done by the X server...
If you are ok, I'll do a patch.
From: Benjamin Herrenschmidt <email@example.com>
It's kind of pointless because what gdb does these days on Linux is
use the procfs 'mem' file to directly read in parts of the inferior's
See linux_proc_xfer_partial() in gdb/linux-nat.c
On Mon, 28 Apr 2008 21:34:16 -0700 (PDT)
Strange, changing access_process_vm on Fedora 9 made gdb able to
see video memory that the X server had mmapped.
Are you sure gdb behaves as you suggest?
On x86 my patch seems to work as I expected...
All rights reversed.
I don't see any sense in adding that. Using /proc/pid/mem is already the
"efficient" API for this known to userland. I don't think keeping the fd
around for that is any great burden, and if you do then the one pread64
call is just as efficient as one ptrace call to do the same thing.