Bug 14466 - unable to load symbols for linux-gate.so.1 (vdso)
Summary: unable to load symbols for linux-gate.so.1 (vdso)
Alias: None
Product: gdb
Classification: Unclassified
Component: symtab (show other bugs)
Version: 7.4
: P2 normal
Target Milestone: 7.9
Assignee: Not yet assigned to anyone
Depends on: 13097
  Show dependency treegraph
Reported: 2012-08-14 12:45 UTC by shentino
Modified: 2016-08-22 19:33 UTC (History)
7 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description shentino 2012-08-14 12:45:27 UTC
I updated my system to glibc-2.15 and gdb started spitting this out whenever
I loaded a program to debug:

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

It seems that linux-gate.so.1 is a VDSO not present in the file system
Comment 1 Jan Kratochvil 2012-08-14 12:52:49 UTC
This glibc change PR 13097 has never been justified by glibc maintainers.

It was posted (never checked in) as:
  [RFC] Work around PR libc/13097 "linux-vdso.so.1" #2

It is present in Fedora GDB patchset:
Comment 2 shentino 2012-08-14 15:49:34 UTC
Who is the official maintainer for gdb?
Comment 3 Tom Tromey 2012-08-15 14:34:51 UTC
(In reply to comment #1)

>   http://sourceware.org/ml/gdb-patches/2011-08/msg00331.html

I think this patch would be more acceptable upstream if it
were somehow glibc- or linux-specific, not generic.
Comment 4 Jan Kratochvil 2012-08-15 15:03:04 UTC
In which distro version / gdb version / operation does it happen?
I tried now FSF GDB in Fedora 16/17/18 i686/x86_64 and it does not happen anywhere for me now.
Comment 5 shentino 2012-08-15 15:15:23 UTC
gdb version: 7.4.1

I reported the bug on their bugzilla but they've decided to wait for 7.5.1 to come down from upstream (which I assume means you guys)
Comment 6 shentino 2012-08-15 15:33:11 UTC
Ooops, for got to say

it happens whenever I load a freshly compiled program for debugging, right after I hit the "run" command.

My guess based on downstream's actions to wait for 7.5.1 is that this has already been fixed.
Comment 7 Gary Benson 2012-08-15 16:52:29 UTC
FWIW I've seen this message, but only when running against a locally built glibc installed in a non-standard location.
Comment 8 Jan Kratochvil 2012-11-22 20:19:23 UTC
[patch+7.5.1] Work around PR libc/13097 "linux-vdso.so.1" #3
Comment 9 Shawn Landden 2013-11-21 15:58:20 UTC
arm64 also has vdso support and likely suffers from the same issue 
Comment 10 Jackie Rosen 2014-02-16 17:51:18 UTC
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.
Comment 11 Sourceware Commits 2014-10-10 16:14:34 UTC
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 -----------------------------------------------------------------

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


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:
    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
     - 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
    Tested on x86_64 Fedora 20.
    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.
    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.


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
    Tested on x86_64 Fedora 20.
    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
Comment 12 Pedro Alves 2014-10-10 17:08:02 UTC
Comment 13 Sourceware Commits 2014-12-25 00:45:35 UTC Comment hidden (spam)