diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-10-15 22:48:42 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-11-14 12:02:47 +0000 |
commit | 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416 (patch) | |
tree | 18a5900e6c34450d6c941c210f7540183693d110 /gdb/python/python.c | |
parent | 661d98a33318e06e0a6715eec5e6d0e140d8f337 (diff) | |
download | binutils-8f6c452b5a4e50fbb55ff1d13328b392ad1fd416.zip binutils-8f6c452b5a4e50fbb55ff1d13328b392ad1fd416.tar.gz binutils-8f6c452b5a4e50fbb55ff1d13328b392ad1fd416.tar.bz2 |
gdb: implement missing debug handler hook for Python
This commit builds on the previous commit, and implements the
extension_language_ops::handle_missing_debuginfo function for Python.
This hook will give user supplied Python code a chance to help find
missing debug information.
The implementation of the new hook is pretty minimal within GDB's C++
code; most of the work is out-sourced to a Python implementation which
is modelled heavily on how GDB's Python frame unwinders are
implemented.
The following new commands are added as commands implemented in
Python, this is similar to how the Python unwinder commands are
implemented:
info missing-debug-handlers
enable missing-debug-handler LOCUS HANDLER
disable missing-debug-handler LOCUS HANDLER
To make use of this extension hook a user will create missing debug
information handler objects, and registers these handlers with GDB.
When GDB encounters an objfile that is missing debug information, each
handler is called in turn until one is able to help. Here is a
minimal handler that does nothing useful:
import gdb
import gdb.missing_debug
class MyFirstHandler(gdb.missing_debug.MissingDebugHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, objfile):
# This handler does nothing useful.
return None
gdb.missing_debug.register_handler(None, MyFirstHandler())
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing debug information, and GDB should ask
any other registered handlers.
By extending the __call__ method it is possible for the Python
extension to locate the debug information for objfile and return a
value that tells GDB how to use the information that has been located.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the debug information
for the objfile still couldn't be found. GDB will not call
any other handlers, and will continue without the debug
information for objfile.
- True: The handler has installed the debug information into a
location where GDB would normally expect to find it. GDB
should look again for the debug information.
- A string: The handler can return a filename, which is the file
containing the missing debug information. GDB will load
this file.
When a handler returns True, GDB will look again for the debug
information, but only using the standard built-in build-id and
.gnu_debuglink based lookup strategies. It is not possible for an
extension to trigger another debuginfod lookup; the assumption is that
the debuginfod server is remote, and out of the control of extensions
running within GDB.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the objfile, at which point GDB continues.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/python/python.c')
-rw-r--r-- | gdb/python/python.c | 83 |
1 files changed, 82 insertions, 1 deletions
diff --git a/gdb/python/python.c b/gdb/python/python.c index d569fb5..4523e30 100644 --- a/gdb/python/python.c +++ b/gdb/python/python.c @@ -127,7 +127,9 @@ static enum ext_lang_rc gdbpy_before_prompt_hook static gdb::optional<std::string> gdbpy_colorize (const std::string &filename, const std::string &contents); static gdb::optional<std::string> gdbpy_colorize_disasm - (const std::string &content, gdbarch *gdbarch); +(const std::string &content, gdbarch *gdbarch); +static ext_lang_missing_debuginfo_result gdbpy_handle_missing_debuginfo + (const struct extension_language_defn *extlang, struct objfile *objfile); /* The interface between gdb proper and loading of python scripts. */ @@ -173,6 +175,8 @@ static const struct extension_language_ops python_extension_ops = gdbpy_colorize_disasm, gdbpy_print_insn, + + gdbpy_handle_missing_debuginfo }; #endif /* HAVE_PYTHON */ @@ -1688,6 +1692,83 @@ gdbpy_get_current_objfile (PyObject *unused1, PyObject *unused2) return objfile_to_objfile_object (gdbpy_current_objfile).release (); } +/* Implement the 'handle_missing_debuginfo' hook for Python. GDB has + failed to find any debug information for OBJFILE. The extension has a + chance to record this, or even install the required debug information. + See the description of ext_lang_missing_debuginfo_result in + extension-priv.h for details of the return value. */ + +static ext_lang_missing_debuginfo_result +gdbpy_handle_missing_debuginfo (const struct extension_language_defn *extlang, + struct objfile *objfile) +{ + /* Early exit if Python is not initialised. */ + if (!gdb_python_initialized) + return {}; + + struct gdbarch *gdbarch = objfile->arch (); + + gdbpy_enter enter_py (gdbarch); + + /* Convert OBJFILE into the corresponding Python object. */ + gdbpy_ref<> pyo_objfile = objfile_to_objfile_object (objfile); + if (pyo_objfile == nullptr) + { + gdbpy_print_stack (); + return {}; + } + + /* Lookup the helper function within the GDB module. */ + gdbpy_ref<> pyo_handler + (PyObject_GetAttrString (gdb_python_module, "_handle_missing_debuginfo")); + if (pyo_handler == nullptr) + { + gdbpy_print_stack (); + return {}; + } + + /* Call the function, passing in the Python objfile object. */ + gdbpy_ref<> pyo_execute_ret + (PyObject_CallFunctionObjArgs (pyo_handler.get (), pyo_objfile.get (), + nullptr)); + if (pyo_execute_ret == nullptr) + { + /* If the handler is cancelled due to a Ctrl-C, then propagate + the Ctrl-C as a GDB exception instead of swallowing it. */ + gdbpy_print_stack_or_quit (); + return {}; + } + + /* Parse the result, and convert it back to the C++ object. */ + if (pyo_execute_ret == Py_None) + return {}; + + if (PyBool_Check (pyo_execute_ret.get ())) + { + bool try_again = PyObject_IsTrue (pyo_execute_ret.get ()); + return ext_lang_missing_debuginfo_result (try_again); + } + + if (!gdbpy_is_string (pyo_execute_ret.get ())) + { + PyErr_SetString (PyExc_ValueError, + "return value from _handle_missing_debuginfo should " + "be None, a Bool, or a String"); + gdbpy_print_stack (); + return {}; + } + + gdb::unique_xmalloc_ptr<char> filename + = python_string_to_host_string (pyo_execute_ret.get ()); + if (filename == nullptr) + { + gdbpy_print_stack (); + return {}; + } + + return ext_lang_missing_debuginfo_result (std::string (filename.get ())); +} + /* Compute the list of active python type printers and store them in EXT_PRINTERS->py_type_printers. The product of this function is used by gdbpy_apply_type_printers, and freed by gdbpy_free_type_printers. |