[Bug symtab/14466] unable to load symbols for linux-gate.so.1 (vdso)

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

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

--- Comment #11 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  cdfa0b0ac16739350360b29b05223655d3b9b740 (commit)
       via  8b9a549d3a9176f92b4cac5b388eb473919f80e6 (commit)
       via  3437254d7b5bc57d3a298df8640ae2f55bdbff2a (commit)
      from  31cc0b807b2fde7d0110175418a6eea01a982489 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

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

commit cdfa0b0ac16739350360b29b05223655d3b9b740
Author: Pedro Alves <palves@redhat.com>
Date:   Fri Oct 10 15:57:14 2014 +0100

    Cache the vsyscall/vDSO range per-inferior

    We're now doing a vsyscall/vDSO address range lookup whenever we fetch
    shared libraries, either through an explicit "info shared", or when
    the target reports new libraries have been loaded, in order to filter
    out the vDSO from glibc's DSO list.  Before we started doing that, GDB
    would only ever lookup the vsyscall's address range once in the
    process's lifetime.

    Looking up the vDSO address range requires an auxv lookup (which is
    already cached, so no problem), but also reading the process's
    mappings from /proc to find out the vDSO's mapping's size.  That
    generates extra RSP traffic when remote debugging.  Particularly
    annoying when the process's mappings grow linearly as more libraries
    are mapped in, and we went through the trouble of making incremental
    DSO list updates work against gdbserver (when the probes-based dynamic
    linker interface is available).

    The vsyscall/vDSO is mapped by the kernel when the process is
    initially mapped in, and doesn't change throughout the process's
    lifetime, so we can cache its address range.

    Caching at this level brings GDB back to one and only one vsyscall
    address range lookup per process.

    Tested on x86_64 Fedora 20.

    gdb/
    2014-10-10  Pedro Alves  <palves@redhat.com>

        * linux-tdep.c: Include observer.h.
        (linux_inferior_data): New global.
        (struct linux_info): New structure.
        (invalidate_linux_cache_inf, linux_inferior_data_cleanup)
        (get_linux_inferior_data): New functions.
        (linux_vsyscall_range): Rename to ...
        (linux_vsyscall_range_raw): ... this.
        (linux_vsyscall_range): New function; handles caching.
        (_initialize_linux_tdep): Register linux_inferior_data.  Install
        inferior_exit and inferior_appeared observers.

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

commit 8b9a549d3a9176f92b4cac5b388eb473919f80e6
Author: Pedro Alves <palves@redhat.com>
Date:   Fri Oct 10 15:57:13 2014 +0100

    PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1"

    With upstream glibc, GDB prints:

      warning: Could not load shared library symbols for linux-vdso.so.1.
      Do you need "set solib-search-path" or "set sysroot"?

    A bug's been filed for glibc a few years back:

      http://sourceware.org/bugzilla/show_bug.cgi?id=13097

    but it's still not resolved.  It's not clear whether there's even
    consensus that this is indeed a glibc bug.  It would actually be nice
    if GDB also listed the vDSO in the shared library list, but there are
    some design considerations with that:

     - the vDSO is mapped by the kernel, not userspace, therefore we
       should load its symbols right from the process's start of life,
       even before glibc / the userspace loader sets up the initial DSO
       list.  The program might even be using a custom loader or no
       loader.

     - that kind of hints at that solib.c should handle retrieving shared
       library lists from more than one source, and that symfile-mem.c's
       loading of the vDSO would be converted to load and relocate the
       vDSO's bfd behind the target_so_ops interface.

     - and then, once glibc links in the vDSO to its DSO list, we'd need
       to either:

        a) somehow hand over the vDSO from one target_so_ops to the other

        b) simply keep hiding glibc's entry.

    And then b) seems the simplest.

    With that in mind, this patch simply discards the vDSO from glibc's
    reported shared library list.

    We can match the vDSO address range with the addresses found iterating
    the dynamic linker list, to tell which dynamic linker entry is the
    vDSO.

    Tested on x86_64 Fedora 20.

    gdb/
    2014-10-10  Jan Kratochvil  <jan.kratochvil@redhat.com>
            Pedro Alves  <palves@redhat.com>

        PR symtab/14466
        * solib-svr4.c (svr4_read_so_list): Rename to ...
        (svr4_current_sos_1): ... this and change the function comment.
        (svr4_current_sos): New function.

    gdb/testsuite/
    2014-10-10  Jan Kratochvil  <jan.kratochvil@redhat.com>
            Pedro Alves  <palves@redhat.com>

        PR symtab/14466
        * gdb.base/vdso-warning.c: New file.
        * gdb.base/vdso-warning.exp: New file.

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

commit 3437254d7b5bc57d3a298df8640ae2f55bdbff2a
Author: Pedro Alves <palves@redhat.com>
Date:   Fri Oct 10 15:57:13 2014 +0100

    Split vDSO range lookup to a gdbarch hook

    We have a case in solib-svr4.c where we could reuse symfile-mem.c's
    vDSO range lookup.  Since symfile-mem.c is not present in all
    configurations solib-svr4.c is, move that lookup to a gdbarch hook.

    This has the minor (good) side effect that we stop even trying the
    target_auxv_search lookup against targets that don't have a concept of
    a vDSO, in case symfile-mem.c happens to be linked in the build
    (--enable-targets=all).

    Tested on x86_64 Fedora 20.

    gdb/
    2014-10-10  Pedro Alves  <palves@redhat.com>

        * arch-utils.c (default_vsyscall_range): New function.
        * arch-utils.h (default_vsyscall_range): New declaration.
        * gdbarch.sh (vsyscall_range): New hook.
        * gdbarch.h, gdbarch.c: Regenerate.
        * linux-tdep.c (linux_vsyscall_range): New function.
        (linux_init_abi): Install linux_vsyscall_range as
        vsyscall_range gdbarch hook.
        * memrange.c (address_in_mem_range): New function.
        * memrange.h (address_in_mem_range): New declaration.
        * symfile-mem.c (find_vdso_size): Delete function.
        (add_vsyscall_page): Use gdbarch_vsyscall_range.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                                      |   35 +++++
 gdb/arch-utils.c                                   |    8 ++
 gdb/arch-utils.h                                   |    4 +
 gdb/gdbarch.c                                      |   23 ++++
 gdb/gdbarch.h                                      |   10 ++
 gdb/gdbarch.sh                                     |    7 +
 gdb/linux-tdep.c                                   |  133 ++++++++++++++++++++
 gdb/memrange.c                                     |    9 ++
 gdb/memrange.h                                     |    5 +
 gdb/solib-svr4.c                                   |   81 ++++++++++++-
 gdb/symfile-mem.c                                  |   31 +----
 gdb/testsuite/ChangeLog                            |    7 +
 .../gdb.base/{auto-load.c => vdso-warning.c}       |    0
 gdb/testsuite/gdb.base/vdso-warning.exp            |   54 ++++++++
 14 files changed, 379 insertions(+), 28 deletions(-)
 copy gdb/testsuite/gdb.base/{auto-load.c => vdso-warning.c} (100%)
 create mode 100644 gdb/testsuite/gdb.base/vdso-warning.exp

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