Add debuginfod support to core_target::build_file_mappings and
locate_exec_from_corefile_build_id to enable the downloading of
missing executables and shared libraries referenced in core files.
Also add debuginfod support to solib_map_sections so that previously
downloaded shared libraries can be retrieved from the local debuginfod
cache.
When core file shared libraries are found locally, verify that their
build-ids match the corresponding build-ids found in the core file.
If there is a mismatch, attempt to query debuginfod for the correct
build and print a warning if unsuccessful:
warning: Build-id of /lib64/libc.so.6 does not match core file.
Also disable debuginfod when gcore invokes gdb. Debuginfo is not
needed for core file generation so debuginfod queries will slow down
gcore unnecessarily.
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.
Back when I proposed the '--readnever' feature, I somehow forgot or
decided not to include the bits related to gcore.in in the original
patch. This patch finally updates the gcore script to invoke GDB
using '--readnever'.
We've been carrying this patch on Fedora GDB for quite some time, and
as expected the corefiles generated by gcore on Fedora don't have
problems, which I think is the best indicator that the it's safe to
generate corefiles using '--readnever'.
gdb/ChangeLog:
2019-02-23 Sergio Durigan Junior <sergiodj@redhat.com>
* gcore.in: Add '--readnever' option when invoking GDB.
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.
Ref.: https://bugs.debian.org/904628
It has been reported that gcore's manpage is a bit imprecise when it
comes to two things:
- It doesn't explicity say that the command accepts more than one PID
on its CLI.
- It fails to mention that the argument passed through the "-o" option
is actually a prefix that will be used to compose the corefile's
filename, and not the actual filename.
I decided to give it a try and rewrite parts of the text to further
clarify these two points. I ended up rewording the "Description"
section because, IMHO, it was a bit confuse to understand.
To make things consistent, I've also renamed the "$name" variable in
the gcore.in script, and expanded the usage text.
gdb/doc/ChangeLog:
2018-07-27 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.texinfo (gcore man): Rewrite "Description" and "-o"
option sections to further clarify that gcore can take more
than one PID, and that "-o" is used to specify a prefix, not a
filename.
gdb/ChangeLog:
2018-07-27 Sergio Durigan Junior <sergiodj@redhat.com>
* gcore.in: Rename variable "name" to "prefix". Expand
"usage" text.
The gcore shell script (gdb/gcore.in) doesn't quote its variables
enough.
For example, trying to write a core file with - say - a space
ungraciously fails like this:
$ gcore -o 'foo bar' 6270
/usr/bin/gcore: line 92: [: foo: binary operator expected
gcore: failed to create foo bar.6270
Similarly, one can inject meta characters like * (by accident)
that may yield unexpected results, e.g. as in:
$ gcore -o foobar '*'
This change fixes these issues in several places.
Aso, since the script uses array syntax, the patch changes the
the shell in the first line from `/bin/sh` to /bin/bash`.
POSIX doesn't specify the array syntax for shell, thus, the
script doesn't work on systems where /bin/sh is linked to - say -
dash.
Since the source gcore.in already is processed by a pre-processor
one could even auto-detect the path to bash and thus dynamically
generate the first line. For systems where bash isn't available
via /bin/bash. But I think this would be overkill and /bin/bash
is good enough as most systems probably have it.
gdb/ChangeLog:
PR gdb/22888
* gcore.in: Quote variables and switch interpreter to bash.
With the new "-a" command line option, the user may request gcore to
actually dump all present memory mappings. The actual effect of this
argument is OS dependent.
On GNU/Linux, it will disable use-coredump-filter and enable
dump-excluded-mappings.
gdb/ChangeLog:
2017-11-29 Sergio Lopez <slp@redhat.com>
* gcore.in: Add "-a" command line option for instructing gdb to
dump all memory mappings (OS dependent).
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.
