Bug 13097 - gdb regression: Excessive linux-vdso.so.1 name
Summary: gdb regression: Excessive linux-vdso.so.1 name
Status: WAITING
Alias: None
Product: glibc
Classification: Unclassified
Component: dynamic-link (show other bugs)
Version: 2.14
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks: 14466
  Show dependency treegraph
 
Reported: 2011-08-16 12:36 UTC by Jan Kratochvil
Modified: 2016-08-22 19:41 UTC (History)
7 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kratochvil 2011-08-16 12:36:36 UTC
Description of problem:
GDB has started to print on each `run':
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

Version-Release number of selected component (if applicable):
FAIL: glibc-2.14.90-5.x86_64
PASS: glibc-2.14.90-4.x86_64
Guessing it is due to:
commit 73d7af4f4c2b394063cb0b3a33ee2b00b5ad80b4
    Implement LD_DEBUG=scopes

How reproducible:
Always.

Steps to Reproduce:
echo 'main(){}'|gcc -x c -;../gdb -nx ./a.out -ex start -ex 'info shared' -ex c
-ex q

Actual results:
Starting program: .../a.out 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Temporary breakpoint 1, 0x0000000000400478 in main ()
From                To                  Syms Read   Shared Object Library
0x00007ffff7ddbb20  0x00007ffff7df513a  Yes         /lib64/ld-linux-x86-64.so.2
                                        No          linux-vdso.so.1
0x00007ffff7a4adc0  0x00007ffff7b80050  Yes         /lib64/libc.so.6
Continuing.

Expected results:
Starting program: .../a.out 
Temporary breakpoint 1, 0x0000000000400478 in main ()
From                To                  Syms Read   Shared Object Library
0x00007ffff7ddbb20  0x00007ffff7df4eda  Yes         /lib64/ld-linux-x86-64.so.2
0x00007ffff7a4ad30  0x00007ffff7b7ff60  Yes         /lib64/libc.so.6
Continuing.

Additional info:
glibc vdso had its name in the link map "" before.
I do not see why the name should be different when there is no corresponding
on-disk file for it.  Should GDB ignore for symbol resolution libraries with literal path-less name "linux-vdso.so.1"?
Comment 1 Ulrich Drepper 2011-09-06 01:39:26 UTC
Why on earth would you think this is a problem in glibc?  Make gdb handle whatever glibc does.  You must already have magic code in gdb to handle this DSO.
Comment 2 Jan Kratochvil 2012-11-24 19:09:46 UTC
For the record it is reverted in Fedora rpm glibc-fedora.patch:
In glibc GIT fedora/master branch:
commit 0c95ab64cb4ec0d22bb222647d9d20c7b4903e38
Author: Andreas Schwab <schwab@redhat.com>
Date:   Fri Oct 7 09:31:27 2011 +0200
-             l->l_libname->name = l->l_name = memcpy (copy, dsoname, len);
+             l->l_libname->name = memcpy (copy, dsoname, len);
+             if (GLRO(dl_debug_mask))
+               l->l_name = copy;
Comment 3 Dmitry V. Levin 2012-11-24 21:40:16 UTC
That patch(In reply to comment #2)
> For the record it is reverted in Fedora rpm glibc-fedora.patch:

Also for the record, it was later factored out from glibc-fedora.patch as http://pkgs.fedoraproject.org/cgit/glibc.git/tree/glibc-fedora-elf-rh737223.patch?id=fb633eaa14bb4c2b35f26c6ec2f4d829f27819ac
Comment 4 Samuel Bronson 2013-05-27 21:10:33 UTC
This is still an issue; how could listing a library under a valid but non-existent filename not confuse tools?
Comment 5 Carlos O'Donell 2013-05-28 20:02:16 UTC
(In reply to Samuel Bronson from comment #4)
> This is still an issue; how could listing a library under a valid but
> non-existent filename not confuse tools?

We aren't likely to get to work on this any time soon. We don't have enough resources.

The code in question is now in elf/setup-vdso.h, and I would be more than happy to review a patch that fixes this bug.

You'd need to run the testsuite on master to make sure you don't introduce any regressions and then show that LD_DEBUG=all still works, and that the debugger which was previously reporting bogus warnings doesn't report any more bogus warnings.

The best possible patch avoids this hack:
+             if (GLRO(dl_debug_mask))
+               l->l_name = copy;

and instead adjusts the debug code to inform the user that this DSO has no associated file e.g. a virtual dso.

Notes:
http://sourceware.org/glibc/wiki/Contribution%20checklist
Comment 6 Jackie Rosen 2014-02-16 17:50:35 UTC Comment hidden (spam)
Comment 7 Pedro Alves 2016-08-22 19:41:11 UTC
FYI,

- since gdb 7.9, gdb no longer warns about the missing vDSO when debugging live programs.

- starting with 7.12, gdb will no longer warn about the same when debugging core dumps.

gdb knows recognizes the vDSO by matching addresses of all DSOs found in the dynamic loader list with the address range of the vDSO, as retrieved from the auxv/AT_SYSINFO_EHDR and the process'es mappings (live inferiors) and PT_LOAD segments (core dumps).

See bug #14466 and bug #20505.

Feel free to reassign "product" to gdb.