[Bug corefiles/25631] GDB cannot access unwritten-to mmap'd buffer from core file

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

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

--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kevin Buettner <kevinb@sourceware.org>:

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

commit 973695d6bb824a1e724d5ea24e7ece013109dc74
Author: Kevin Buettner <kevinb@redhat.com>
Date:   Fri Aug 7 13:07:44 2020 -0700

    Work around incorrect/broken pathnames in NT_FILE note

    Luis Machado reported some regressions after I pushed recent core file
    related patches fixing BZ 25631:

        FAIL: gdb.base/corefile.exp: backtrace in corefile.exp
        FAIL: gdb.base/corefile.exp: core-file warning-free
        FAIL: gdb.base/corefile.exp: print func2::coremaker_local
        FAIL: gdb.base/corefile.exp: up in corefile.exp
        FAIL: gdb.base/corefile.exp: up in corefile.exp (reinit)

    This commit fixes these regressions.  Thanks to Luis for testing
    an earlier version of the patch.  (I was unable to reproduce these
    regressions in various test environments that I created.)

    Luis is testing in a docker container which is using the AUFS storage
    driver.  It turns out that the kernel is placing docker host paths in
    the NT_FILE note instead of paths within the container.

    I've made a similar docker environment (though apparently not similar
    enough to reproduce the regressions).  This is one of the paths that
    I see mentioned in the warning messages printed while loading the
    core file during NT_FILE note processing - note that I've shortened
    the path component starting with "d07c4":

    /var/lib/docker/aufs/diff/d07c4...21/lib/x86_64-linux-gnu/ld-2.27.so

    This is a path on the docker host; it does not exist in the
    container.  In the docker container, this is the path:

    /lib/x86_64-linux-gnu/ld-2.27.so

    My first thought was to disable all NT_FILE mappings when any path was
    found to be bad.  This would have caused GDB to fall back to accessing
    memory using the file stratum as it did before I added the NT_FILE
    note loading code.  After further consideration, I realized that we
    could do better than this.  For file-backed memory access, we can
    still use the NT_FILE mappings when available, and then attempt to
    access memory using the file stratum constrained to those address
    ranges corresponding to the "broken" mappings.

    In order to test it, I made some additions to corefile2.exp in which
    the test case's executable is renamed.  The core file is then loaded;
    due to the fact that the executable has been renamed, those mappings
    will be unavailable.  After loading the core file, the executable is
    renamed back to its original name at which point it is loaded using
    GDB's "file" command.  The "interesting" tests are then run.  These
    tests will print out values in file-backed memory regions along with
    mmap'd regions placed within/over the file-backed regions.  Despite
    the fact that the executable could not be found during the NT_FILE
    note processing, these tests still work correctly due to the fact that
    memory is available from the file stratum combined with the fact that
    the broken NT_FILE mappings are used to prevent file-backed access
    outside of the "broken" mappings.

    gdb/ChangeLog:

            * corelow.c (unordered_set): Include.
            (class core_target): Add field 'm_core_unavailable_mappings'.
            (core_target::build_file_mappings): Print only one warning
            per inaccessible file.  Add unavailable/broken mappings
            to m_core_unavailable_mappings.
            (core_target::xfer_partial): Call...
            (core_target::xfer_memory_via_mappings): New method.

    gdb/testsuite/ChangeLog:

            * gdb.base/corefile2.exp (renamed binfile): New tests.

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