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:
parent
14fa8fb307
commit
43d5901ded
9 changed files with 153 additions and 57 deletions
|
@ -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 */
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue