gdb/python: implement Python find_exec_by_build_id hook

Implement extension_language_ops::find_objfile_from_buildid within
GDB's Python API.  Doing this allows users to write Python extensions
that can help locate missing objfiles when GDB opens a core file.  A
handler might perform some project- or site-specific actions to find a
missing objfile.  Or might provide some project- or site-specific
advice to the user on how they can obtain the missing objfile.

The implementation is very similar to the approach taken in:

  commit 8f6c452b5a
  Date:   Sun Oct 15 22:48:42 2023 +0100

      gdb: implement missing debug handler hook for Python

The following new commands are added as commands implemented in
Python, this is similar to how the Python missing debug and unwinder
commands are implemented:

  info missing-objfile-handlers
  enable missing-objfile-handler LOCUS HANDLER
  disable missing-objfile-handler LOCUS HANDLER

To make use of this extension hook a user will create missing objfile
handler objects, and registers these handlers with GDB.  When GDB
opens a core file and encounters a missing objfile 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_objfile

  class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler):
      def __init__(self):
          super().__init__("my_first_handler")

      def __call__(self, pspace, build_id, filename):
          # This handler does nothing useful.
          return None

  gdb.missing_objfile.register_handler(None, MyFirstHandler())

Returning None from the __call__ method tells GDB that this handler
was unable to find the missing objfile, and GDB should ask any other
registered handlers.

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 objfile couldn't
            be found.  GDB will not call any other handlers, and will
	    continue without the objfile.

  - True: The handler has installed the objfile into a location where
          GDB would normally expect to find it.  GDB should repeat its
	  normal lookup process and the objfile should now be found.

  - A string: The handler can return a filename, which is the missing
              objfile.  GDB will load this file.

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 missing objfile, at which point GDB continues.

The implementation of this feature is mostly straight forward.  I have
reworked some of the missing debug file related code so that it can be
shared with this feature.  E.g. gdb/python/lib/gdb/missing_files.py is
mostly content moved from gdb/python/lib/gdb/missing_debug.py, but
updated to be more generic.  Now gdb/python/lib/gdb/missing_debug.py
and the new file gdb/python/lib/gdb/missing_objfile.py both call into
the missing_files.py file.

For gdb/python/lib/gdb/command/missing_files.py this is even more
extreme, gdb/python/lib/gdb/command/missing_debug.py is completely
gone now and gdb/python/lib/gdb/command/missing_files.py provides all
of the new commands in a generic way.

I have made one change to the existing Python API, I renamed the
attribute Progspace.missing_debug_handlers to
Progspace.missing_file_handlers.  I don't see this as too
problematic.  This attribute was only used to implement the missing
debug feature and was never documented beyond the fact that it
existed.  There was no reason for users to be touching this attribute.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
This commit is contained in:
Andrew Burgess
2024-07-31 15:55:57 +01:00
parent ef1a41f20b
commit 5cabc8098e
15 changed files with 1615 additions and 235 deletions

View File

@@ -35,6 +35,7 @@
#include "location.h"
#include "run-on-main-thread.h"
#include "observable.h"
#include "build-id.h"
#if GDB_SELF_TEST
#include "gdbsupport/selftest.h"
@@ -130,6 +131,9 @@ static std::optional<std::string> gdbpy_colorize_disasm
(const std::string &content, gdbarch *gdbarch);
static ext_lang_missing_file_result gdbpy_handle_missing_debuginfo
(const struct extension_language_defn *extlang, struct objfile *objfile);
static ext_lang_missing_file_result gdbpy_find_objfile_from_buildid
(const struct extension_language_defn *extlang, program_space *pspace,
const struct bfd_build_id *build_id, const char *missing_filename);
/* The interface between gdb proper and loading of python scripts. */
@@ -179,7 +183,8 @@ static const struct extension_language_ops python_extension_ops =
gdbpy_print_insn,
gdbpy_handle_missing_debuginfo
gdbpy_handle_missing_debuginfo,
gdbpy_find_objfile_from_buildid
};
#endif /* HAVE_PYTHON */
@@ -1829,6 +1834,107 @@ gdbpy_handle_missing_debuginfo (const struct extension_language_defn *extlang,
return ext_lang_missing_file_result (std::string (filename.get ()));
}
/* Implement the find_objfile_from_buildid hook for Python. PSPACE is the
program space in which GDB is trying to find an objfile, BUILD_ID is the
build-id for the missing objfile, and EXPECTED_FILENAME is a non-NULL
string which can be used (if needed) in messages to the user, and
represents the file GDB is looking for. */
static ext_lang_missing_file_result
gdbpy_find_objfile_from_buildid (const struct extension_language_defn *extlang,
program_space *pspace,
const struct bfd_build_id *build_id,
const char *missing_filename)
{
gdb_assert (pspace != nullptr);
gdb_assert (build_id != nullptr);
gdb_assert (missing_filename != nullptr);
/* Early exit if Python is not initialised. */
if (!gdb_python_initialized || gdb_python_module == nullptr)
return {};
gdbpy_enter enter_py;
/* Convert BUILD_ID into a Python object. */
std::string hex_form = bin2hex (build_id->data, build_id->size);
gdbpy_ref<> pyo_buildid = host_string_to_python_string (hex_form.c_str ());
if (pyo_buildid == nullptr)
{
gdbpy_print_stack ();
return {};
}
/* Convert MISSING_FILENAME to a Python object. */
gdbpy_ref<> pyo_filename = host_string_to_python_string (missing_filename);
if (pyo_filename == nullptr)
{
gdbpy_print_stack ();
return {};
}
/* Convert PSPACE to a Python object. */
gdbpy_ref<> pyo_pspace = pspace_to_pspace_object (pspace);
if (pyo_pspace == nullptr)
{
gdbpy_print_stack ();
return {};
}
/* Lookup the helper function within the GDB module. */
gdbpy_ref<> pyo_handler
(PyObject_GetAttrString (gdb_python_module, "_handle_missing_objfile"));
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_pspace.get (),
pyo_buildid.get (), pyo_filename.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 ()))
{
/* We know the value is a bool, so it must be either Py_True or
Py_False. Anything else would not get past the above check. */
bool try_again = pyo_execute_ret.get () == Py_True;
return ext_lang_missing_file_result (try_again);
}
if (!gdbpy_is_string (pyo_execute_ret.get ()))
{
PyErr_SetString (PyExc_ValueError,
"return value from _find_objfile_by_buildid should "
"be None, a bool, or a str");
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_file_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.