I noticed that trying to print the contents of a struct main_type
would fail when the type was a TYPE_CODE_RANGE:
(gdb) p *type.main_type
$1 = Python Exception <class 'gdb.error'> There is no member named low_undefined.:
And indeed, Python is right, fields "low_undefined" has been removed
from struct range_bounds back in ... 2014! It was done when we introduced
dynamic bounds handling. This patch fixes gdb-gdb.py.in according to
the new structure.
gdb/ChangeLog:
* gdb-gdb.py.in (StructMainTypePrettyPrinter.bound_img): New method.
(StructMainTypePrettyPrinter.bounds_img): Use new "bound_img"
method to compute the bounds of range types. Also print "[evaluated]"
if the bounds' values come from a dynamic evaluation.
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.
Add a pretty-printer that prints CORE_ADDR values in hex.
gdb/ChangeLog:
* gdb-gdb.py.in (CoreAddrPrettyPrinter): New class.
(type_lookup_function): Recognize CORE_ADDR values.
Python 3 doesn't use __cmp__ to order objects, it uses __lt__. Because
of this, we get this exception when trying to pretty-print "type"
objects:
I tested it with Python 2.7 as well.
gdb/ChangeLog:
* gdb-gdb.py.in (TypeFlag) <__cmp__>: Remove.
<__lt__>: Add.
I have thought for a long time how nice it would be to have cool pretty
printers for GDB's internal types. Well, turns out there are few
already in gdb-gdb.py! Unfortunately, if you build GDB outside of the
source directory, that file never gets loaded. top-gdb will look for a
file called
../path/to/build/gdb/gdb-gdb.py
but that file is in the source directory at
../path/to/src/gdb/gdb-gdb.py
This patch makes it so we copy it to the build directory, just like we
do for gdb-gdb.gdb. With this, I can at least see the file getting
automatically loaded:
(top-gdb) info pretty-printer
global pretty-printers:
builtin
mpx_bound128
objfile /home/emaisin/build/binutils-gdb/gdb/gdb pretty-printers:
type_lookup_function
I noticed that running "make" didn't re-generate gdb-gdb.py from
gdb-gdb.py.in. That's because it's copied when running the configure
script and that's it. I added a rule in the Makefile for that (and for
gdb-gdb.gdb too) and added them as a dependency to the "all" target.
gdb/ChangeLog:
* gdb-gdb.py: Move to...
* gdb-gdb.py.in: ... here.
* configure.ac (AC_CONFIG_FILES): Add gdb-gdb.py.
* Makefile.in (all): Add gdb-gdb.gdb and gdb-gdb.py as
dependencies.
(distclean): Remove gdb-gdb.py when cleaning.
(gdb-gdb.py, gdb-gdb.gdb): New rules.
* configure: Re-generate.
Joel Brobecker
Simon Marchi