| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files
|
|
This applies the second part of GDB's End of Year Procedure, which
updates the copyright year range in all of GDB's files.
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
gdb/ChangeLog:
Update year range in copyright notice of all files.
|
|
gdb/ChangeLog:
Update year range in copyright notice of all files.
|
|
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.
|
