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"?
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.
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;
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
This is still an issue; how could listing a library under a valid but non-existent filename not confuse tools?
(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
*** 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.
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.