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.
