aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/python.c
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-10-15 22:48:42 +0100
committerAndrew Burgess <aburgess@redhat.com>2023-11-14 12:02:47 +0000
commit8f6c452b5a4e50fbb55ff1d13328b392ad1fd416 (patch)
tree18a5900e6c34450d6c941c210f7540183693d110 /gdb/python/python.c
parent661d98a33318e06e0a6715eec5e6d0e140d8f337 (diff)
downloadbinutils-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.c83
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.