PTRACE_{READ,WRITE}{TEXT,DATA} - Kernel

This is a discussion on PTRACE_{READ,WRITE}{TEXT,DATA} - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: PTRACE_{READ,WRITE}{TEXT,DATA}

  1. PTRACE_{READ,WRITE}{TEXT,DATA}

    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.

    Cheers,
    Ben

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: PTRACE_{READ,WRITE}{TEXT,DATA}

    From: Benjamin Herrenschmidt
    Date: Tue, 29 Apr 2008 13:54:08 +1000

    > 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...


    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
    address space.

    See linux_proc_xfer_partial() in gdb/linux-nat.c
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: PTRACE_{READ,WRITE}{TEXT,DATA}

    On Mon, 28 Apr 2008 21:34:16 -0700 (PDT)
    David Miller wrote:

    > From: Benjamin Herrenschmidt
    > Date: Tue, 29 Apr 2008 13:54:08 +1000
    >
    > > 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...

    >
    > 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
    > address space.
    >
    > See linux_proc_xfer_partial() in gdb/linux-nat.c


    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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: PTRACE_{READ,WRITE}{TEXT,DATA}


    On Mon, 2008-04-28 at 21:34 -0700, David Miller wrote:
    > From: Benjamin Herrenschmidt
    > Date: Tue, 29 Apr 2008 13:54:08 +1000
    >
    > > 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...

    >
    > 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
    > address space.
    >
    > See linux_proc_xfer_partial() in gdb/linux-nat.c=


    Good point. That still uses access_process_vm() so Rik and I work
    is still valid tho.

    Thanks,
    Ben.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: PTRACE_{READ,WRITE}{TEXT,DATA}


    > 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...


    Because /proc//mem also uses access_process_vm(). See
    fs/proc/base.c

    Cheers,
    Ben.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: PTRACE_{READ,WRITE}{TEXT,DATA}

    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.


    Thanks,
    Roland
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: PTRACE_{READ,WRITE}{TEXT,DATA}


    On Tue, 2008-04-29 at 15:07 -0700, Roland McGrath wrote:
    > 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.


    Yup, I didn't know gdb used /proc/pid/mem to be honest ... as long as it
    goes through access_process_vm(), I'm fine anyway.

    Cheers,
    Ben.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: PTRACE_{READ,WRITE}{TEXT,DATA}

    > Yup, I didn't know gdb used /proc/pid/mem to be honest ... as long as it
    > goes through access_process_vm(), I'm fine anyway.


    All user ABIs for this have always boiled down to access_process_vm.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread