Summary: | gdb regression: Excessive linux-vdso.so.1 name | ||
---|---|---|---|
Product: | glibc | Reporter: | Jan Kratochvil <jan> |
Component: | dynamic-link | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | WAITING --- | ||
Severity: | normal | CC: | carlos, jan, kalvdans, ldv, naesten, ovidiu.b13, pedro |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | 2.14 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Bug Depends on: | |||
Bug Blocks: | 14466 |
Description
Jan Kratochvil
2011-08-16 12:36:36 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. 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. |