gdb/python: make more use of RegisterDescriptors

This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.

Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number.  I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind.  However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.

Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.

This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.

The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly.  However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.

As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.

After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.

gdb/ChangeLog:

	* python/py-frame.c: Remove 'user-regs.h' include.
	(frapy_read_register): Rewrite to make use of
	gdbpy_parse_register_id.
	* python/py-registers.c (gdbpy_parse_register_id): New function,
	moved here from python/py-unwind.c.  Updated the return type, and
	also accepts register descriptor objects.
	* python/py-unwind.c: Remove 'user-regs.h' include.
	(pyuw_parse_register_id): Moved to python/py-registers.c.
	(unwind_infopy_add_saved_register): Update to use
	gdbpy_parse_register_id.
	(pending_framepy_read_register): Likewise.
	* python/python-internal.h (gdbpy_parse_register_id): Declare.

gdb/testsuite/ChangeLog:

	* gdb.python/py-unwind.py: Update to make use of a register
	descriptor.

gdb/doc/ChangeLog:

	* python.texi (Unwinding Frames in Python): Update descriptions
	for PendingFrame.read_register and
	gdb.UnwindInfo.add_saved_register.
	(Frames In Python): Update description of Frame.read_register.
This commit is contained in:
Andrew Burgess 2020-07-22 12:13:11 +01:00
parent 14fa8fb307
commit 43d5901ded
9 changed files with 153 additions and 57 deletions

View file

@ -776,4 +776,23 @@ struct Py_buffer_deleter
/* A unique_ptr specialization for Py_buffer. */
typedef std::unique_ptr<Py_buffer, Py_buffer_deleter> Py_buffer_up;
/* Parse a register number from PYO_REG_ID and place the register number
into *REG_NUM. The register is a register for GDBARCH.
If a register is parsed successfully then *REG_NUM will have been
updated, and true is returned. Otherwise the contents of *REG_NUM are
undefined, and false is returned.
The PYO_REG_ID object can be a string, the name of the register. This
is the slowest approach as GDB has to map the name to a number for each
call. Alternatively PYO_REG_ID can be an internal GDB register
number. This is quick but should not be encouraged as this means
Python scripts are now dependent on GDB's internal register numbering.
Final PYO_REG_ID can be a gdb.RegisterDescriptor object, these objects
can be looked up by name once, and then cache the register number so
should be as quick as using a register number. */
extern bool gdbpy_parse_register_id (struct gdbarch *gdbarch,
PyObject *pyo_reg_id, int *reg_num);
#endif /* PYTHON_PYTHON_INTERNAL_H */