[Bug gdb/21220] "restore" for large data structures extremely slow on GNU/Linux

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21220

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andreas Arnez <arnez@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=87c336f60eccc6506ff19369c29575f43fea02ea

commit 87c336f60eccc6506ff19369c29575f43fea02ea
Author: Andreas Arnez <arnez@linux.vnet.ibm.com>
Date:   Tue Mar 14 19:20:46 2017 +0100

    inf-ptrace: Do not stop memory transfers after a single word

    When inf_ptrace_xfer_partial performs a memory transfer via ptrace with
    PT_READ_I, PT_WRITE_I (aka PTRACE_PEEKTEXT, PTRACE_POKETEXT), etc., then
    it currently transfers at most one word.  This behavior yields degraded
    performance, particularly if the caller has significant preparation work
    for each invocation.  And indeed it has for writing, in
    memory_xfer_partial in target.c, where all of the remaining data to be
    transferred is copied to a temporary buffer each time, for breakpoint
    shadow handling.  Thus large writes have quadratic runtime and can take
    hours.

    Note: On GNU/Linux targets GDB usually does not use
    inf_ptrace_xfer_partial for large memory transfers, but attempts a single
    read/write from/to /proc/<pid>/mem instead.  However, the kernel may
    reject writes to /proc/<pid>/mem (such as kernels prior to 2.6.39), or
    /proc may not be mounted.  In both cases GDB falls back to the ptrace
    mechanism.

    This patch fixes the performance issue by attempting to fulfill the whole
    transfer request in inf_ptrace_xfer_partial, using a loop around the
    ptrace call.

    gdb/ChangeLog:

        PR gdb/21220
        * inf-ptrace.c (inf_ptrace_xfer_partial): In "case
        TARGET_OBJECT_MEMORY", extract the logic for ptrace peek/poke...
        (inf_ptrace_peek_poke): ...here.  New function.  Now also loop
        over ptrace peek/poke until end of buffer or error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.