uefi-ref/binutils-gdb
1
0
Fork 0
mirror of https://sourceware.org/git/binutils-gdb.git synced 2026-08-27 00:26:02 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions
binutils-gdb/gdb/python/py-micmd.c

594 lines
19 KiB
C
Raw Permalink Normal View History

gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
/* MI Command Set for GDB, the GNU debugger.
Update copyright dates to include 2026 This updates the copyright headers to include 2026. I did this by running gdb/copyright.py and then manually modifying a few files as noted by the script.
2026-01-05 08:13:29 -07:00
Copyright (C) 2019-2026 Free Software Foundation, Inc.
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
/* GDB/MI commands implemented in Python. */
#include "python-internal.h"
#include "arch-utils.h"
#include "charset.h"
#include "language.h"
#include "mi/mi-cmds.h"
#include "mi/mi-parse.h"
#include "cli/cli-cmds.h"
#include <string>
/* Debugging of Python MI commands. */
static bool pymicmd_debug;
/* Implementation of "show debug py-micmd". */
static void
show_pymicmd_debug (struct ui_file *file, int from_tty,
struct cmd_list_element *c, const char *value)
{
Unify gdb printf functions Now that filtered and unfiltered output can be treated identically, we can unify the printf family of functions. This is done under the name "gdb_printf". Most of this patch was written by script.
2022-01-02 11:46:15 -07:00
gdb_printf (file, _("Python MI command debugging is %s.\n"), value);
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
}
/* Print a "py-micmd" debug statement. */
#define pymicmd_debug_printf(fmt, ...) \
debug_prefixed_printf_cond (pymicmd_debug, "py-micmd", fmt, ##__VA_ARGS__)
/* Print a "py-micmd" enter/exit debug statements. */
#define PYMICMD_SCOPED_DEBUG_ENTER_EXIT \
scoped_debug_enter_exit (pymicmd_debug, "py-micmd")
struct mi_command_py;
/* Representation of a Python gdb.MICommand object. */
gdb: cast all Python extension objects passed to gdbpy_ref_policy to PyObject* When enabling the Python limited API, pointers to Python C extension objects can no longer be implicitly converted to 'PyObject *' by the compiler. gdbpy_ref_policy is a templated class that provides a generic interface for incrementing and decrementing the reference counter on the given object. It is used as a specialisation of the policy parameter in gdb::ref_ptr, together with PyObject as the parameter type. As a result, gdbpy_ref_policy always expects an argument derived from PyObject. This patch fixes the resulting compilation issue by adding an explicit static_cast to 'PyObject *' before passing the value to Py_INCREF and Py_DECREF. As a side effect, these casts enforce, at compile time, that the template type passed to gdbpy_ref_policy is a subclass of PyObject. To provide a clearer diagnostic when an incorrect type is used, a static_assert is added to gdbpy_ref_policy, avoiding obscure errors originating from the static_cast. Finally, all C Python extension types passed to gdbpy_ref_policy are updated to inherit from PyObject. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
2025-10-25 23:55:29 +01:00
struct micmdpy_object : public PyObject
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
{
/* The object representing this command in the MI command table. This
pointer can be nullptr if the command is not currently installed into
the MI command table (see gdb.MICommand.installed property). */
struct mi_command_py *mi_command;
/* The string representing the name of this command, without the leading
dash. This string is never nullptr once the Python object has been
initialised.
The memory for this string was allocated with malloc, and needs to be
deallocated with free when the Python object is deallocated.
When the MI_COMMAND field is not nullptr, then the mi_command_py
object's name will point back to this string. */
char *mi_command_name;
};
gdb/python: add type traits check for all PyObject sub-classes All of our custom Python types are created as structs, like this: struct some_new_type : public PyObject { ... various fields ... }; Then instances of this struct are created by calling PyObject_New, either directly within GDB's C++ code, or within Python when a user's Python script creates an instance of that class. The problem is that Python is written in C, and PyObject_New doesn't call any constructors for `some_new_type`, nor for any of the fields within `some_new_type`. If `some_new_type` is Plain Old Data (POD), then this is fine. Or, to be more C++ specific, if `some_new_type` is trivially default constructable, then we're fine. But if a field within `some_new_type` has a non-trivial constructor, then we're in trouble as that constructor will never be run. An example of a problematic field type is frame_info_ptr. The constructor for this type registers the new object with a central management object, recording the `this` pointer, using this type within `some_new_type` will not work as expected; frame invalidation will not show up within the frame_info_ptr as you might expect. And so, this type trait exists. Whenever a struct is created to define a new Python type we should add a line like: static_assert (gdb::is_python_allocatable_v<some_new_type>); This will fail if any field of `some_new_type` are unsuitable for this use. We don't actually check is_trivially_default_constructible here. Some types, e.g. ui_file_style::color, have non-trivial (or no default) constructors, but are still safe to use within `some_new_type` because their constructors just initialise data fields; there's nothing "special" that the constructor does that cannot be achieved by assigning the fields after creation with PyObject_New. What actually matters is that the type is trivially destructible (Python won't call C++ destructors, so destructors with side effects, like deregistering from a list, would be skipped) and trivially copyable (Python may copy objects with memcpy). Types like frame_info_ptr, whose constructors and destructors have side effects such as registering with a central management object, will be caught because they are neither trivially destructible nor trivially copyable. Simple POD types like ui_file_style are trivially destructible and copyable, so pass this trait. This commit adds the new type trait, and makes use of it in all cases but one, pending_frame_object in python/py-unwind.c, has a field of type frame_info_ptr, which is currently broken. This will be fixed, and the static_assert added, in the next commit. Approved-By: Tom Tromey <tom@tromey.com>
2026-05-14 09:39:57 +01:00
static_assert (gdb::is_python_allocatable_v<micmdpy_object>);
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
/* The MI command implemented in Python. */
struct mi_command_py : public mi_command
{
/* Constructs a new mi_command_py object. NAME is command name without
leading dash. OBJECT is a reference to a Python object implementing
the command. This object must inherit from gdb.MICommand and must
implement the invoke method. */
mi_command_py (const char *name, micmdpy_object *object)
: mi_command (name, nullptr),
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
m_pyobj (gdbpy_ref<micmdpy_object>::new_reference (object))
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
{
pymicmd_debug_printf ("this = %p", this);
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
m_pyobj->mi_command = this;
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
}
~mi_command_py ()
{
/* The Python object representing a MI command contains a pointer back
to this c++ object. We can safely set this pointer back to nullptr
now, to indicate the Python object no longer references a valid c++
object.
However, the Python object also holds the storage for our name
string. We can't clear that here as our parent's destructor might
still want to reference that string. Instead we rely on the Python
object deallocator to free that memory, and reset the pointer. */
m_pyobj->mi_command = nullptr;
pymicmd_debug_printf ("this = %p", this);
};
/* Validate that CMD_OBJ, a non-nullptr pointer, is installed into the MI
command table correctly. This function looks up the command in the MI
command table and checks that the object we get back references
CMD_OBJ. This function is only intended for calling within a
gdb_assert. This function performs many assertions internally, and
then always returns true. */
static void validate_installation (micmdpy_object *cmd_obj);
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
/* Update M_PYOBJ to NEW_PYOBJ. The pointer from M_PYOBJ that points
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
back to this object is swapped with the pointer in NEW_PYOBJ, which
must be nullptr, so that NEW_PYOBJ now points back to this object.
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
Additionally our parent's name string is stored in M_PYOBJ, so we
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
swap the name string with NEW_PYOBJ.
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
Before this call M_PYOBJ is the Python object representing this MI
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
command object. After this call has completed, NEW_PYOBJ now
represents this MI command object. */
void swap_python_object (micmdpy_object *new_pyobj)
{
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
/* Current object has a backlink, new object doesn't have a backlink. */
gdb_assert (m_pyobj->mi_command != nullptr);
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
gdb_assert (new_pyobj->mi_command == nullptr);
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
/* Clear the current M_PYOBJ's backlink, set NEW_PYOBJ's backlink. */
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
std::swap (new_pyobj->mi_command, m_pyobj->mi_command);
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
/* Both object have names. */
gdb_assert (m_pyobj->mi_command_name != nullptr);
gdb_assert (new_pyobj->mi_command_name != nullptr);
/* mi_command::m_name is the string owned by the current object. */
gdb_assert (m_pyobj->mi_command_name == this->name ());
/* The name in mi_command::m_name is owned by the current object. Rather
than changing the value of mi_command::m_name (which is not accessible
from here) to point to the name owned by the new object, swap the names
of the two objects, since we know they are identical strings. */
gdb, gdbserver, gdbsupport: replace many uses of strcmp with streq Replace all occurrences of: strcmp (...) == 0 strcmp (...) != 0 !strcmp (...) 0 == strcmp (...) strcmp (...) directly used as a boolean predicate with the equivalent expression using streq. This is for consistency (we already use streq as some places in the testsuite) but also for clarity. I think that streq is clearer on the intent than strcmp. It's also a bit shorter. Change-Id: Ibbf5261b1872c240bc0c982c147f6a5477275a91 Approved-By: Andrew Burgess <aburgess@redhat.com>
2026-03-16 11:23:19 -04:00
gdb_assert (streq (new_pyobj->mi_command_name, m_pyobj->mi_command_name));
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
std::swap (new_pyobj->mi_command_name, m_pyobj->mi_command_name);
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
/* Take a reference to the new object, drop the reference to the current
object. */
m_pyobj = gdbpy_ref<micmdpy_object>::new_reference (new_pyobj);
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
}
/* Called when the MI command is invoked. */
gdb/mi: consistently notify user when GDB/MI client uses -thread-select GDB notifies users about user selected thread changes somewhat inconsistently as mentioned on gdb-patches mailing list here: https://sourceware.org/pipermail/gdb-patches/2022-February/185989.html Consider GDB debugging a multi-threaded inferior with both CLI and GDB/MI interfaces connected to separate terminals. Assuming inferior is stopped and thread 1 is selected, when a thread 2 is selected using '-thread-select 2' command on GDB/MI terminal: -thread-select 2 ^done,new-thread-id="2",frame={level="0",addr="0x00005555555551cd",func="child_sub_function",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="30",arch="i386:x86-64"} (gdb) and on CLI terminal we get the notification (as expected): [Switching to thread 2 (Thread 0x7ffff7daa640 (LWP 389659))] #0 child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30 30 volatile int dummy = 0; However, now that thread 2 is selected, if thread 1 is selected using 'thread-select --thread 1 1' command on GDB/MI terminal terminal: -thread-select --thread 1 1 ^done,new-thread-id="1",frame={level="0",addr="0x0000555555555294",func="main",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="66",arch="i386:x86-64"} (gdb) but no notification is printed on CLI terminal, despite the fact that user selected thread has changed. The problem is that when `-thread-select --thread 1 1` is executed then thread is switched to thread 1 before mi_cmd_thread_select () is called, therefore the condition "inferior_ptid != previous_ptid" there does not hold. To address this problem, we have to move notification logic up to mi_cmd_execute () where --thread option is processed and notify user selected contents observers there if context changes. However, this in itself breaks GDB/MI because it would cause context notification to be sent on MI channel. This is because by the time we notify, MI notification suppression is already restored (done in mi_command::invoke(). Therefore we had to lift notification suppression logic also up to mi_cmd_execute (). This change in made distinction between mi_command::invoke() and mi_command::do_invoke() unnecessary as all mi_command::invoke() did (after the change) was to call do_invoke(). So this patches removes do_invoke() and moves the command execution logic directly to invoke(). With this change, all gdb.mi tests pass, tested on x86_64-linux. Co-authored-by: Andrew Burgess <aburgess@redhat.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20631
2022-03-16 15:08:22 +00:00
virtual void invoke(struct mi_parse *parse) const override;
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
private:
/* The Python object representing this MI command. */
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
gdbpy_ref<micmdpy_object> m_pyobj;
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
};
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
using mi_command_py_up = std::unique_ptr<mi_command_py>;
Remove Python API checker defines The GCC plugin that implements the Python API checker does not appear to really be maintained. And, as far as I know, it never really worked for C++ code anyway. Considering those factors, and that no one has tried to run it in years, I think it's time to remove the macros from the gdb source. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-10-21 10:00:20 -06:00
extern PyTypeObject micmdpy_object_type;
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
/* Holds a Python object containing the string 'invoke'. */
static PyObject *invoke_cst;
/* Called when the MI command is invoked. PARSE contains the parsed
command line arguments from the user. */
void
gdb/mi: consistently notify user when GDB/MI client uses -thread-select GDB notifies users about user selected thread changes somewhat inconsistently as mentioned on gdb-patches mailing list here: https://sourceware.org/pipermail/gdb-patches/2022-February/185989.html Consider GDB debugging a multi-threaded inferior with both CLI and GDB/MI interfaces connected to separate terminals. Assuming inferior is stopped and thread 1 is selected, when a thread 2 is selected using '-thread-select 2' command on GDB/MI terminal: -thread-select 2 ^done,new-thread-id="2",frame={level="0",addr="0x00005555555551cd",func="child_sub_function",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="30",arch="i386:x86-64"} (gdb) and on CLI terminal we get the notification (as expected): [Switching to thread 2 (Thread 0x7ffff7daa640 (LWP 389659))] #0 child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30 30 volatile int dummy = 0; However, now that thread 2 is selected, if thread 1 is selected using 'thread-select --thread 1 1' command on GDB/MI terminal terminal: -thread-select --thread 1 1 ^done,new-thread-id="1",frame={level="0",addr="0x0000555555555294",func="main",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="66",arch="i386:x86-64"} (gdb) but no notification is printed on CLI terminal, despite the fact that user selected thread has changed. The problem is that when `-thread-select --thread 1 1` is executed then thread is switched to thread 1 before mi_cmd_thread_select () is called, therefore the condition "inferior_ptid != previous_ptid" there does not hold. To address this problem, we have to move notification logic up to mi_cmd_execute () where --thread option is processed and notify user selected contents observers there if context changes. However, this in itself breaks GDB/MI because it would cause context notification to be sent on MI channel. This is because by the time we notify, MI notification suppression is already restored (done in mi_command::invoke(). Therefore we had to lift notification suppression logic also up to mi_cmd_execute (). This change in made distinction between mi_command::invoke() and mi_command::do_invoke() unnecessary as all mi_command::invoke() did (after the change) was to call do_invoke(). So this patches removes do_invoke() and moves the command execution logic directly to invoke(). With this change, all gdb.mi tests pass, tested on x86_64-linux. Co-authored-by: Andrew Burgess <aburgess@redhat.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20631
2022-03-16 15:08:22 +00:00
mi_command_py::invoke (struct mi_parse *parse) const
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
{
PYMICMD_SCOPED_DEBUG_ENTER_EXIT;
pymicmd_debug_printf ("this = %p, name = %s", this, name ());
Change mi_parse_argv to a method This changes mi_parse_argv to be a method of mi_parse. This is just a minor cleanup.
2023-03-20 10:48:50 -06:00
parse->parse_argv ();
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
if (parse->argv == nullptr)
Use unique_xmalloc_ptr for mi_parse::command This changes mi_parse::command to be a unique_xmalloc_ptr and fixes up all the uses. This avoids some manual memory management. std::string is not used here due to how the Python API works -- this approach avoids an extra copy there. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-06-09 10:35:20 -06:00
error (_("Problem parsing arguments: %s %s"), parse->command.get (),
Use accessor for mi_parse::args This changes mi_parse::args to be a private member, retrieved via accessor. It also changes this member to be a std::string. This makes it simpler for a subsequent patch to implement different behavior for argument parsing.
2023-03-20 10:42:43 -06:00
parse->args ());
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
gdbpy_enter enter_py;
/* Place all the arguments into a list which we pass as a single argument
to the MI command's invoke method. */
gdbpy_ref<> argobj (PyList_New (parse->argc));
if (argobj == nullptr)
gdbpy_handle_exception ();
for (int i = 0; i < parse->argc; ++i)
{
gdbpy_ref<> str (PyUnicode_Decode (parse->argv[i],
strlen (parse->argv[i]),
host_charset (), nullptr));
if (PyList_SetItem (argobj.get (), i, str.release ()) < 0)
gdbpy_handle_exception ();
}
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
gdb_assert (this->m_pyobj != nullptr);
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
gdb_assert (PyErr_Occurred () == nullptr);
gdb/python: generalize serialize_mi_result() This commit generalizes serialize_mi_result() to make usable in different contexts than printing result of custom MI command. To do so, the check whether passed Python object is a dictionary has been moved to the caller - at the very least, different uses require different error messages. Also it has been renamed to serialize_mi_results() to better match GDB/MI output syntax (see corresponding section in documentation, in particular rules 'result-record' and 'async-output'. Since it is now more generic function, it has been moved to py-mi.c. This is a preparation for implementing Python support for sending custom MI async events. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10 11:22:56 +01:00
gdbpy_ref<> results
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
(PyObject_CallMethodObjArgs ((PyObject *) this->m_pyobj.get (), invoke_cst,
argobj.get (), nullptr));
gdb/python: generalize serialize_mi_result() This commit generalizes serialize_mi_result() to make usable in different contexts than printing result of custom MI command. To do so, the check whether passed Python object is a dictionary has been moved to the caller - at the very least, different uses require different error messages. Also it has been renamed to serialize_mi_results() to better match GDB/MI output syntax (see corresponding section in documentation, in particular rules 'result-record' and 'async-output'. Since it is now more generic function, it has been moved to py-mi.c. This is a preparation for implementing Python support for sending custom MI async events. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10 11:22:56 +01:00
if (results == nullptr)
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
gdbpy_handle_exception ();
gdb/python: generalize serialize_mi_result() This commit generalizes serialize_mi_result() to make usable in different contexts than printing result of custom MI command. To do so, the check whether passed Python object is a dictionary has been moved to the caller - at the very least, different uses require different error messages. Also it has been renamed to serialize_mi_results() to better match GDB/MI output syntax (see corresponding section in documentation, in particular rules 'result-record' and 'async-output'. Since it is now more generic function, it has been moved to py-mi.c. This is a preparation for implementing Python support for sending custom MI async events. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10 11:22:56 +01:00
if (results != Py_None)
{
/* At the top-level, the results must be a dictionary. */
if (!PyDict_Check (results.get ()))
gdbpy_error (_("Result from invoke must be a dictionary"));
serialize_mi_results (results.get ());
}
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
}
/* See declaration above. */
void
mi_command_py::validate_installation (micmdpy_object *cmd_obj)
{
gdb_assert (cmd_obj != nullptr);
mi_command_py *cmd = cmd_obj->mi_command;
gdb_assert (cmd != nullptr);
const char *name = cmd_obj->mi_command_name;
gdb_assert (name != nullptr);
gdb_assert (name == cmd->name ());
mi_command *mi_cmd = mi_cmd_lookup (name);
gdb_assert (mi_cmd == cmd);
gdb_assert (cmd->m_pyobj == cmd_obj);
}
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
/* Return CMD as an mi_command_py if it is a Python MI command, else
nullptr. */
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
static mi_command_py *
as_mi_command_py (mi_command *cmd)
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
{
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
return dynamic_cast<mi_command_py *> (cmd);
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
}
/* Uninstall OBJ, making the MI command represented by OBJ unavailable for
use by the user. On success 0 is returned, otherwise -1 is returned
and a Python exception will be set. */
static int
micmdpy_uninstall_command (micmdpy_object *obj)
{
PYMICMD_SCOPED_DEBUG_ENTER_EXIT;
gdb_assert (obj->mi_command != nullptr);
gdb_assert (obj->mi_command_name != nullptr);
pymicmd_debug_printf ("name = %s", obj->mi_command_name);
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
/* Remove the command from the internal MI table of commands. This will
cause the mi_command_py object to be deleted, which will clear the
backlink in OBJ. */
bool removed = remove_mi_cmd_entry (obj->mi_command->name ());
gdb_assert (removed);
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
gdb_assert (obj->mi_command == nullptr);
return 0;
}
/* Install OBJ as a usable MI command. Return 0 on success, and -1 on
error, in which case, a Python error will have been set.
After successful completion the command name associated with OBJ will
be installed in the MI command table (so it can be found if the user
enters that command name), additionally, OBJ will have been added to
the gdb._mi_commands dictionary (using the command name as its key),
this will ensure that OBJ remains live even if the user gives up all
references. */
static int
micmdpy_install_command (micmdpy_object *obj)
{
PYMICMD_SCOPED_DEBUG_ENTER_EXIT;
gdb_assert (obj->mi_command == nullptr);
gdb_assert (obj->mi_command_name != nullptr);
pymicmd_debug_printf ("name = %s", obj->mi_command_name);
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
/* Look up this command name in MI_COMMANDS, a command with this name may
already exist. */
mi_command *cmd = mi_cmd_lookup (obj->mi_command_name);
mi_command_py *cmd_py = as_mi_command_py (cmd);
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
if (cmd != nullptr && cmd_py == nullptr)
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
{
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
/* There is already an MI command registered with that name, and it's not
gdb, gdbserver, gdbsupport: fix whitespace issues Replace spaces with tabs in a bunch of places. Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
2023-03-09 14:56:09 -05:00
a Python one. Forbid replacing a non-Python MI command. */
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
PyErr_SetString (PyExc_RuntimeError,
_("unable to add command, name is already in use"));
return -1;
}
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
if (cmd_py != nullptr)
{
/* There is already a Python MI command registered with that name, swap
gdb, gdbserver, gdbsupport: fix whitespace issues Replace spaces with tabs in a bunch of places. Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
2023-03-09 14:56:09 -05:00
in the new gdb.MICommand implementation. */
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
cmd_py->swap_python_object (obj);
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
}
else
{
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
/* There's no MI command registered with that name at all, create one. */
mi_command_py_up mi_cmd (new mi_command_py (obj->mi_command_name, obj));
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
/* Add the command to the gdb internal MI command table. */
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
bool result = insert_mi_cmd_entry (std::move (mi_cmd));
gdb_assert (result);
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
}
return 0;
}
/* Implement gdb.MICommand.__init__. The init method takes the name of
the MI command as the first argument, which must be a string, starting
with a single dash. */
static int
micmdpy_init (PyObject *self, PyObject *args, PyObject *kwargs)
{
PYMICMD_SCOPED_DEBUG_ENTER_EXIT;
micmdpy_object *cmd = (micmdpy_object *) self;
static const char *keywords[] = { "name", nullptr };
const char *name;
if (!gdb_PyArg_ParseTupleAndKeywords (args, kwargs, "s", keywords,
&name))
return -1;
/* Validate command name */
const int name_len = strlen (name);
if (name_len == 0)
{
PyErr_SetString (PyExc_ValueError, _("MI command name is empty."));
return -1;
}
Use gnulib c-ctype module in gdb PR ada/33217 points out that gdb incorrectly calls the <ctype.h> functions. In particular, gdb feels free to pass a 'char' like: char *str = ...; ... isdigit (*str) This is incorrect as isdigit only accepts EOF and values that can be represented as 'unsigned char' -- that is, a cast is needed here to avoid undefined behavior when 'char' is signed and a character in the string might be sign-extended. (As an aside, I think this API seems obviously bad, but unfortunately this is what the standard says, and some systems check this.) Rather than adding casts everywhere, this changes all the code in gdb that uses any <ctype.h> API to instead call the corresponding c-ctype function. Now, c-ctype has some limitations compared to <ctype.h>. It works as if the C locale is in effect, so in theory some non-ASCII characters may be misclassified. This would only affect a subset of character sets, though, and in most places I think ASCII is sufficient -- for example the many places in gdb that check for whitespace. Furthermore, in practice most users are using UTF-8-based locales, where these functions aren't really informative for non-ASCII characters anyway; see the existing workarounds in gdb/c-support.h. Note that safe-ctype.h cannot be used because it causes conflicts with readline.h. And, we canot poison the <ctype.h> identifiers as this provokes errors from some libstdc++ headers. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33217 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-08-04 10:39:02 -06:00
else if ((name_len < 2) || (name[0] != '-') || !c_isalnum (name[1]))
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
{
PyErr_SetString (PyExc_ValueError,
_("MI command name does not start with '-'"
" followed by at least one letter or digit."));
return -1;
}
else
{
for (int i = 2; i < name_len; i++)
{
Use gnulib c-ctype module in gdb PR ada/33217 points out that gdb incorrectly calls the <ctype.h> functions. In particular, gdb feels free to pass a 'char' like: char *str = ...; ... isdigit (*str) This is incorrect as isdigit only accepts EOF and values that can be represented as 'unsigned char' -- that is, a cast is needed here to avoid undefined behavior when 'char' is signed and a character in the string might be sign-extended. (As an aside, I think this API seems obviously bad, but unfortunately this is what the standard says, and some systems check this.) Rather than adding casts everywhere, this changes all the code in gdb that uses any <ctype.h> API to instead call the corresponding c-ctype function. Now, c-ctype has some limitations compared to <ctype.h>. It works as if the C locale is in effect, so in theory some non-ASCII characters may be misclassified. This would only affect a subset of character sets, though, and in most places I think ASCII is sufficient -- for example the many places in gdb that check for whitespace. Furthermore, in practice most users are using UTF-8-based locales, where these functions aren't really informative for non-ASCII characters anyway; see the existing workarounds in gdb/c-support.h. Note that safe-ctype.h cannot be used because it causes conflicts with readline.h. And, we canot poison the <ctype.h> identifiers as this provokes errors from some libstdc++ headers. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33217 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-08-04 10:39:02 -06:00
if (!c_isalnum (name[i]) && name[i] != '-')
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
{
PyErr_Format
(PyExc_ValueError,
_("MI command name contains invalid character: %c."),
name[i]);
return -1;
}
}
/* Skip over the leading dash. For the rest of this function the
dash is not important. */
++name;
}
/* If this object already has a name set, then this object has been
initialized before. We handle this case a little differently. */
if (cmd->mi_command_name != nullptr)
{
/* First, we don't allow the user to change the MI command name.
Supporting this would be tricky as we would need to delete the
mi_command_py from the MI command table, however, the user might
be trying to perform this reinitialization from within the very
command we're about to delete... it all gets very messy.
So, for now at least, we don't allow this. This doesn't seem like
an excessive restriction. */
gdb, gdbserver, gdbsupport: replace many uses of strcmp with streq Replace all occurrences of: strcmp (...) == 0 strcmp (...) != 0 !strcmp (...) 0 == strcmp (...) strcmp (...) directly used as a boolean predicate with the equivalent expression using streq. This is for consistency (we already use streq as some places in the testsuite) but also for clarity. I think that streq is clearer on the intent than strcmp. It's also a bit shorter. Change-Id: Ibbf5261b1872c240bc0c982c147f6a5477275a91 Approved-By: Andrew Burgess <aburgess@redhat.com>
2026-03-16 11:23:19 -04:00
if (!streq (cmd->mi_command_name, name))
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
{
PyErr_SetString
(PyExc_ValueError,
_("can't reinitialize object with a different command name"));
return -1;
}
/* If there's already an object registered with the MI command table,
then we're done. That object must be a mi_command_py, which
should reference back to this micmdpy_object. */
if (cmd->mi_command != nullptr)
{
mi_command_py::validate_installation (cmd);
return 0;
}
}
else
cmd->mi_command_name = xstrdup (name);
/* Now we can install this mi_command_py in the MI command table. */
return micmdpy_install_command (cmd);
}
/* Called when a gdb.MICommand object is deallocated. */
static void
micmdpy_dealloc (PyObject *obj)
{
PYMICMD_SCOPED_DEBUG_ENTER_EXIT;
micmdpy_object *cmd = (micmdpy_object *) obj;
/* If the Python object failed to initialize, then the name field might
be nullptr. */
pymicmd_debug_printf ("obj = %p, name = %s", cmd,
(cmd->mi_command_name == nullptr
? "(null)" : cmd->mi_command_name));
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
/* As the mi_command_py object holds a reference to the micmdpy_object,
the only way the dealloc function can be called is if the mi_command_py
object has been deleted, in which case the following assert will
hold. */
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
gdb_assert (cmd->mi_command == nullptr);
/* Free the memory that holds the command name. */
xfree (cmd->mi_command_name);
cmd->mi_command_name = nullptr;
/* Finally, free the memory for this Python object. */
Py_TYPE (obj)->tp_free (obj);
}
/* Python initialization for the MI commands components. */
Remove Python API checker defines The GCC plugin that implements the Python API checker does not appear to really be maintained. And, as far as I know, it never really worked for C++ code anyway. Considering those factors, and that no one has tried to run it in years, I think it's time to remove the macros from the gdb source. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-10-21 10:00:20 -06:00
static int
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
gdbpy_initialize_micommands ()
{
micmdpy_object_type.tp_new = PyType_GenericNew;
Automatically add types to Python modules PR python/32163 points out that various types provided by gdb are not added to the gdb module, so they aren't available for interactive inspection. I think this is just an oversight. This patch fixes the problem by introducing a new helper function that both readies the type and then adds it to the appropriate module. The patch also poisons PyType_Ready, the idea being to avoid this bug in the future. v2: * Fixed a bug in original patch in gdb.Architecture registration * Added regression test for the types mentioned in the bug Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32163 Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
2024-09-11 10:35:20 -06:00
if (gdbpy_type_ready (&micmdpy_object_type) < 0)
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
return -1;
gdb/python: remove Python 2/3 compatibility macros New in this version: - Rebase on master, fix a few more issues that appeared. python-internal.h contains a number of macros that helped make the code work with both Python 2 and 3. Remove them and adjust the code to use the Python 3 functions. Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d
2022-03-21 10:07:41 -04:00
invoke_cst = PyUnicode_FromString ("invoke");
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
if (invoke_cst == nullptr)
return -1;
return 0;
}
gdb/python: add mechanism to manage Python initialization functions Currently, when we add a new python sub-system to GDB, e.g. py-inferior.c, we end up having to create a new function like gdbpy_initialize_inferior, which then has to be called from the function do_start_initialization in python.c. In some cases (py-micmd.c and py-tui.c), we have two functions gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called from finalize_python which is also in python.c. This commit proposes a mechanism to manage these initialization and finalization calls, this means that adding a new Python subsystem will no longer require changes to python.c or python-internal.h, instead, the initialization and finalization functions will be registered directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c. The initialization and finalization functions are managed through a new class gdbpy_initialize_file in python-internal.h. This class contains a single global vector of all the initialization and finalization functions. In each Python sub-system we create a new gdbpy_initialize_file object, the object constructor takes care of registering the two callback functions. Now from python.c we can call static functions on the gdbpy_initialize_file class which take care of walking the callback list and invoking each callback in turn. To slightly simplify the Python sub-system files I added a new macro GDBPY_INITIALIZE_FILE, which hides the need to create an object. We can now just do this: GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers); One possible problem with this change is that there is now no guaranteed ordering of how the various sub-systems are initialized (or finalized). To try and avoid dependencies creeping in I have added a use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is the same environment variable used in the generated init.c file. Just like with init.c, when this environment variable is set we reverse the list of Python initialization (and finalization) functions. As there is already a test that starts GDB with the environment variable set then this should offer some level of protection against dependencies creeping in - though for full protection I guess we'd need to run all gdb.python/*.exp tests with the variable set. I have tested this patch with the environment variable set, and saw no regressions, so I think we are fine right now. One other change of note was for gdbpy_initialize_gdb_readline, this function previously returned void. In order to make this function have the correct signature I've updated its return type to int, and we now return 0 to indicate success. All of the other initialize (and finalize) functions have been made static within their respective sub-system files. There should be no user visible changes after this commit.
2022-09-16 16:08:17 +01:00
/* Cleanup just before GDB shuts down the Python interpreter. */
static void
gdb/python: remove gdb._mi_commands dict The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-18 15:55:26 -04:00
gdbpy_finalize_micommands ()
{
/* mi_command_py objects hold references to micmdpy_object objects. They must
be dropped before the Python interpreter is finalized. Do so by removing
those MI command entries, thus deleting the mi_command_py objects. */
remove_mi_cmd_entries ([] (mi_command *cmd)
{
return as_mi_command_py (cmd) != nullptr;
});
}
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
/* Get the gdb.MICommand.name attribute, returns a string, the name of this
MI command. */
static PyObject *
micmdpy_get_name (PyObject *self, void *closure)
{
struct micmdpy_object *micmd_obj = (struct micmdpy_object *) self;
gdb_assert (micmd_obj->mi_command_name != nullptr);
std::string name_str = string_printf ("-%s", micmd_obj->mi_command_name);
gdb/python: remove Python 2/3 compatibility macros New in this version: - Rebase on master, fix a few more issues that appeared. python-internal.h contains a number of macros that helped make the code work with both Python 2 and 3. Remove them and adjust the code to use the Python 3 functions. Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d
2022-03-21 10:07:41 -04:00
return PyUnicode_FromString (name_str.c_str ());
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
}
/* Get the gdb.MICommand.installed property. Returns true if this MI
command is installed into the MI command table, otherwise returns
false. */
static PyObject *
micmdpy_get_installed (PyObject *self, void *closure)
{
struct micmdpy_object *micmd_obj = (struct micmdpy_object *) self;
if (micmd_obj->mi_command == nullptr)
[gdb/python] Remove Py_RETURN_{NONE,TRUE,FALSE,NOTIMPLEMENTED} Result of: ... $ sed -i 's/Py_RETURN_NONE/return py_none ().release ()/' gdb/python/*.{c,h} ... with the changes in py_none reverted. Likewise for Py_RETURN_TRUE,Py_RETURN_FALSE and Py_RETURN_NOTIMPLEMENTED. Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34145
2026-05-15 21:38:12 +02:00
return py_false ().release ();
return py_true ().release ();
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
}
/* Set the gdb.MICommand.installed property. The property can be set to
either true or false. Setting the property to true will cause the
command to be installed into the MI command table (if it isn't
already), while setting this property to false will cause the command
to be removed from the MI command table (if it is present). */
static int
micmdpy_set_installed (PyObject *self, PyObject *newvalue, void *closure)
{
struct micmdpy_object *micmd_obj = (struct micmdpy_object *) self;
gdb/python: missing PyObject_IsTrue error check in micmdpy_set_installed Like the previous commit, I discovered that in micmdpy_set_installed we were calling PyObject_IsTrue, but not checking for a possible error value being returned. The micmdpy_set_installed function implements the gdb.MICommand.installed attribute, and the documentation indicates that this attribute should only be assigned a bool: This attribute is read-write, setting this attribute to 'False' will uninstall the command, removing it from the set of available commands. Setting this attribute to 'True' will install the command for use. So I propose that instead of using PyObject_IsTrue we use PyBool_Check, and if the new value fails this check we raise an error. We can then compare the new value to Py_True directly instead of calling PyObject_IsTrue. This is a potentially breaking change to the Python API, but hopefully this will not impact too many people, and the fix is pretty easy (switch to using a bool). I've added a NEWS entry to draw attention to this change. Approved-By: Tom Tromey <tom@tromey.com>
2024-11-10 15:50:26 +00:00
if (!PyBool_Check (newvalue))
{
PyErr_Format (PyExc_TypeError,
_("gdb.MICommand.installed must be set to a bool, not %s"),
gdb/python: fix memory leak in gdb_py_tp_name The current implementation of gdb_py_tp_name() leaks a reference to the object returned by PyType_GetFullyQualifiedName() for Python >= 3.13, and PyType_GetQualName() for Python >= 3.11. Managing the strong reference on the returned PyObject* with a gdbpy_ref<> fixes the reference count, but also causes the temporary object to be deallocated on function exit. As a consequence, the 'const char *' returned by PyUnicode_AsUTF8AndSize() becomes dangling and can no longer safely be returned. The proposed approach consists in changing gdb_py_tp_name() to return a std::string, and forcing a copy of the 'const char *' value, statically or dynamically allocated, stored in a temporary or non-temporary PyObject, depending on the version of Python it was compiled with. An unfortunate side effect of this fix is that every call sites where the tp_name is printed, must now use `.c_str()' because PyErr_Format() and its siblings cannot handle std::string. Approved-By: Andrew Burgess <aburgess@redhat.com>
2026-05-26 11:46:29 +01:00
(newvalue == Py_None
? "None"
: gdbpy_py_obj_tp_name (newvalue).c_str ()));
gdb/python: missing PyObject_IsTrue error check in micmdpy_set_installed Like the previous commit, I discovered that in micmdpy_set_installed we were calling PyObject_IsTrue, but not checking for a possible error value being returned. The micmdpy_set_installed function implements the gdb.MICommand.installed attribute, and the documentation indicates that this attribute should only be assigned a bool: This attribute is read-write, setting this attribute to 'False' will uninstall the command, removing it from the set of available commands. Setting this attribute to 'True' will install the command for use. So I propose that instead of using PyObject_IsTrue we use PyBool_Check, and if the new value fails this check we raise an error. We can then compare the new value to Py_True directly instead of calling PyObject_IsTrue. This is a potentially breaking change to the Python API, but hopefully this will not impact too many people, and the fix is pretty easy (switch to using a bool). I've added a NEWS entry to draw attention to this change. Approved-By: Tom Tromey <tom@tromey.com>
2024-11-10 15:50:26 +00:00
return -1;
}
bool installed_p = newvalue == Py_True;
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
if (installed_p == (micmd_obj->mi_command != nullptr))
return 0;
if (installed_p)
return micmdpy_install_command (micmd_obj);
else
return micmdpy_uninstall_command (micmd_obj);
}
/* The gdb.MICommand properties. */
static gdb_PyGetSetDef micmdpy_object_getset[] = {
{ "name", micmdpy_get_name, nullptr, "The command's name.", nullptr },
{ "installed", micmdpy_get_installed, micmdpy_set_installed,
"Is this command installed for use.", nullptr },
{ nullptr } /* Sentinel. */
};
/* The gdb.MICommand descriptor. */
PyTypeObject micmdpy_object_type = {
PyVarObject_HEAD_INIT (nullptr, 0) "gdb.MICommand", /*tp_name */
sizeof (micmdpy_object), /*tp_basicsize */
0, /*tp_itemsize */
micmdpy_dealloc, /*tp_dealloc */
0, /*tp_print */
0, /*tp_getattr */
0, /*tp_setattr */
0, /*tp_compare */
0, /*tp_repr */
0, /*tp_as_number */
0, /*tp_as_sequence */
0, /*tp_as_mapping */
0, /*tp_hash */
0, /*tp_call */
0, /*tp_str */
0, /*tp_getattro */
0, /*tp_setattro */
0, /*tp_as_buffer */
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, /*tp_flags */
"GDB mi-command object", /* tp_doc */
0, /* tp_traverse */
0, /* tp_clear */
0, /* tp_richcompare */
0, /* tp_weaklistoffset */
0, /* tp_iter */
0, /* tp_iternext */
0, /* tp_methods */
0, /* tp_members */
micmdpy_object_getset, /* tp_getset */
0, /* tp_base */
0, /* tp_dict */
0, /* tp_descr_get */
0, /* tp_descr_set */
0, /* tp_dictoffset */
micmdpy_init, /* tp_init */
0, /* tp_alloc */
};
Change file initialization to use INIT_GDB_FILE macro This patch introduces a new macro, INIT_GDB_FILE. This is used to replace the current "_initialize_" idiom when introducing a per-file initialization function. That is, rather than write: void _initialize_something (); void _initialize_something () { ... } ... now you would write: INIT_GDB_FILE (something) { ... } The macro handles both the declaration and definition of the function. The point of this approach is that it makes it harder to accidentally cause an initializer to be omitted; see commit 2711e475 ("Ensure cooked_index_entry self-tests are run"). Specifically, the regexp now used by make-init-c seems harder to trick. New in v2: un-did some erroneous changes made by the script. The bulk of this patch was written by script. Regression tested on x86-64 Fedora 41.
2025-05-22 11:54:16 -06:00
INIT_GDB_FILE (py_micmd)
gdb/python/mi: create MI commands using python This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2020-06-23 14:45:38 +01:00
{
add_setshow_boolean_cmd
("py-micmd", class_maintenance, &pymicmd_debug,
_("Set Python micmd debugging."),
_("Show Python micmd debugging."),
_("When on, Python micmd debugging is enabled."),
nullptr,
show_pymicmd_debug,
&setdebuglist, &showdebuglist);
}
gdb/python: add mechanism to manage Python initialization functions Currently, when we add a new python sub-system to GDB, e.g. py-inferior.c, we end up having to create a new function like gdbpy_initialize_inferior, which then has to be called from the function do_start_initialization in python.c. In some cases (py-micmd.c and py-tui.c), we have two functions gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called from finalize_python which is also in python.c. This commit proposes a mechanism to manage these initialization and finalization calls, this means that adding a new Python subsystem will no longer require changes to python.c or python-internal.h, instead, the initialization and finalization functions will be registered directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c. The initialization and finalization functions are managed through a new class gdbpy_initialize_file in python-internal.h. This class contains a single global vector of all the initialization and finalization functions. In each Python sub-system we create a new gdbpy_initialize_file object, the object constructor takes care of registering the two callback functions. Now from python.c we can call static functions on the gdbpy_initialize_file class which take care of walking the callback list and invoking each callback in turn. To slightly simplify the Python sub-system files I added a new macro GDBPY_INITIALIZE_FILE, which hides the need to create an object. We can now just do this: GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers); One possible problem with this change is that there is now no guaranteed ordering of how the various sub-systems are initialized (or finalized). To try and avoid dependencies creeping in I have added a use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is the same environment variable used in the generated init.c file. Just like with init.c, when this environment variable is set we reverse the list of Python initialization (and finalization) functions. As there is already a test that starts GDB with the environment variable set then this should offer some level of protection against dependencies creeping in - though for full protection I guess we'd need to run all gdb.python/*.exp tests with the variable set. I have tested this patch with the environment variable set, and saw no regressions, so I think we are fine right now. One other change of note was for gdbpy_initialize_gdb_readline, this function previously returned void. In order to make this function have the correct signature I've updated its return type to int, and we now return 0 to indicate success. All of the other initialize (and finalize) functions have been made static within their respective sub-system files. There should be no user visible changes after this commit.
2022-09-16 16:08:17 +01:00
GDBPY_INITIALIZE_FILE (gdbpy_initialize_micommands, gdbpy_finalize_micommands);
Reference in a new issue Copy permalink