2025-02-04 13:56:49 +00:00
|
|
|
@c Copyright (C) 2008--2025 Free Software Foundation, Inc.
|
2014-02-17 10:35:03 -08:00
|
|
|
@c Permission is granted to copy, distribute and/or modify this document
|
|
|
|
|
@c under the terms of the GNU Free Documentation License, Version 1.3 or
|
|
|
|
|
@c any later version published by the Free Software Foundation; with the
|
|
|
|
|
@c Invariant Sections being ``Free Software'' and ``Free Software Needs
|
|
|
|
|
@c Free Documentation'', with the Front-Cover Texts being ``A GNU Manual,''
|
|
|
|
|
@c and with the Back-Cover Texts as in (a) below.
|
|
|
|
|
@c
|
|
|
|
|
@c (a) The FSF's Back-Cover Text is: ``You are free to copy and modify
|
|
|
|
|
@c this GNU Manual. Buying copies from GNU Press supports the FSF in
|
|
|
|
|
@c developing GNU and promoting software freedom.''
|
|
|
|
|
|
|
|
|
|
@node Python
|
|
|
|
|
@section Extending @value{GDBN} using Python
|
|
|
|
|
@cindex python scripting
|
|
|
|
|
@cindex scripting with python
|
|
|
|
|
|
|
|
|
|
You can extend @value{GDBN} using the @uref{http://www.python.org/,
|
|
|
|
|
Python programming language}. This feature is available only if
|
|
|
|
|
@value{GDBN} was configured using @option{--with-python}.
|
|
|
|
|
|
|
|
|
|
@cindex python directory
|
|
|
|
|
Python scripts used by @value{GDBN} should be installed in
|
|
|
|
|
@file{@var{data-directory}/python}, where @var{data-directory} is
|
|
|
|
|
the data directory as determined at @value{GDBN} startup (@pxref{Data Files}).
|
|
|
|
|
This directory, known as the @dfn{python directory},
|
|
|
|
|
is automatically added to the Python Search Path in order to allow
|
|
|
|
|
the Python interpreter to locate all scripts installed at this location.
|
|
|
|
|
|
|
|
|
|
Additionally, @value{GDBN} commands and convenience functions which
|
|
|
|
|
are written in Python and are located in the
|
|
|
|
|
@file{@var{data-directory}/python/gdb/command} or
|
|
|
|
|
@file{@var{data-directory}/python/gdb/function} directories are
|
|
|
|
|
automatically imported when @value{GDBN} starts.
|
|
|
|
|
|
|
|
|
|
@menu
|
|
|
|
|
* Python Commands:: Accessing Python from @value{GDBN}.
|
|
|
|
|
* Python API:: Accessing @value{GDBN} from Python.
|
|
|
|
|
* Python Auto-loading:: Automatically loading Python code.
|
|
|
|
|
* Python modules:: Python modules provided by @value{GDBN}.
|
|
|
|
|
@end menu
|
|
|
|
|
|
|
|
|
|
@node Python Commands
|
|
|
|
|
@subsection Python Commands
|
|
|
|
|
@cindex python commands
|
|
|
|
|
@cindex commands to access python
|
|
|
|
|
|
|
|
|
|
@value{GDBN} provides two commands for accessing the Python interpreter,
|
|
|
|
|
and one related setting:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@kindex python-interactive
|
|
|
|
|
@kindex pi
|
|
|
|
|
@item python-interactive @r{[}@var{command}@r{]}
|
|
|
|
|
@itemx pi @r{[}@var{command}@r{]}
|
|
|
|
|
Without an argument, the @code{python-interactive} command can be used
|
|
|
|
|
to start an interactive Python prompt. To return to @value{GDBN},
|
|
|
|
|
type the @code{EOF} character (e.g., @kbd{Ctrl-D} on an empty prompt).
|
|
|
|
|
|
|
|
|
|
Alternatively, a single-line Python command can be given as an
|
|
|
|
|
argument and evaluated. If the command is an expression, the result
|
|
|
|
|
will be printed; otherwise, nothing will be printed. For example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(@value{GDBP}) python-interactive 2 + 3
|
|
|
|
|
5
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@kindex python
|
|
|
|
|
@kindex py
|
|
|
|
|
@item python @r{[}@var{command}@r{]}
|
|
|
|
|
@itemx py @r{[}@var{command}@r{]}
|
|
|
|
|
The @code{python} command can be used to evaluate Python code.
|
|
|
|
|
|
|
|
|
|
If given an argument, the @code{python} command will evaluate the
|
|
|
|
|
argument as a Python command. For example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(@value{GDBP}) python print 23
|
|
|
|
|
23
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
If you do not provide an argument to @code{python}, it will act as a
|
|
|
|
|
multi-line command, like @code{define}. In this case, the Python
|
|
|
|
|
script is made up of subsequent command lines, given after the
|
|
|
|
|
@code{python} command. This command list is terminated using a line
|
|
|
|
|
containing @code{end}. For example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(@value{GDBP}) python
|
|
|
|
|
>print 23
|
|
|
|
|
>end
|
|
|
|
|
23
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
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
|
|
|
@anchor{set_python_print_stack}
|
2014-02-17 10:35:03 -08:00
|
|
|
@kindex set python print-stack
|
|
|
|
|
@item set python print-stack
|
|
|
|
|
By default, @value{GDBN} will print only the message component of a
|
|
|
|
|
Python exception when an error occurs in a Python script. This can be
|
|
|
|
|
controlled using @code{set python print-stack}: if @code{full}, then
|
|
|
|
|
full Python stack printing is enabled; if @code{none}, then Python stack
|
|
|
|
|
and message printing is disabled; if @code{message}, the default, only
|
|
|
|
|
the message component of the error is printed.
|
2020-08-27 16:53:13 +01:00
|
|
|
|
|
|
|
|
@kindex set python ignore-environment
|
|
|
|
|
@item set python ignore-environment @r{[}on@r{|}off@r{]}
|
|
|
|
|
By default this option is @samp{off}, and, when @value{GDBN}
|
|
|
|
|
initializes its internal Python interpreter, the Python interpreter
|
|
|
|
|
will check the environment for variables that will effect how it
|
|
|
|
|
behaves, for example @env{PYTHONHOME}, and
|
|
|
|
|
@env{PYTHONPATH}@footnote{See the ENVIRONMENT VARIABLES section of
|
|
|
|
|
@command{man 1 python} for a comprehensive list.}.
|
|
|
|
|
|
|
|
|
|
If this option is set to @samp{on} before Python is initialized then
|
|
|
|
|
Python will ignore all such environment variables. As Python is
|
|
|
|
|
initialized early during @value{GDBN}'s startup process, then this
|
|
|
|
|
option must be placed into the early initialization file
|
|
|
|
|
(@pxref{Initialization Files}) to have the desired effect.
|
|
|
|
|
|
|
|
|
|
This option is equivalent to passing @option{-E} to the real
|
|
|
|
|
@command{python} executable.
|
|
|
|
|
|
|
|
|
|
@kindex set python dont-write-bytecode
|
|
|
|
|
@item set python dont-write-bytecode @r{[}auto@r{|}on@r{|}off@r{]}
|
|
|
|
|
When this option is @samp{off}, then, once @value{GDBN} has
|
|
|
|
|
initialized the Python interpreter, the interpreter will byte-compile
|
|
|
|
|
any Python modules that it imports and write the byte code to disk in
|
|
|
|
|
@file{.pyc} files.
|
|
|
|
|
|
|
|
|
|
If this option is set to @samp{on} before Python is initialized then
|
|
|
|
|
Python will no longer write the byte code to disk. As Python is
|
|
|
|
|
initialized early during @value{GDBN}'s startup process, then this
|
|
|
|
|
option must be placed into the early initialization file
|
|
|
|
|
(@pxref{Initialization Files}) to have the desired effect.
|
|
|
|
|
|
2022-07-25 12:04:10 -07:00
|
|
|
By default this option is set to @samp{auto}. In this mode, provided
|
|
|
|
|
the @code{python ignore-environment} setting is @samp{off}, the
|
|
|
|
|
environment variable @env{PYTHONDONTWRITEBYTECODE} is examined to see
|
2020-08-27 16:53:13 +01:00
|
|
|
if it should write out byte-code or not.
|
2022-07-25 12:04:10 -07:00
|
|
|
@env{PYTHONDONTWRITEBYTECODE} is considered to be off/disabled either
|
|
|
|
|
when set to the empty string or when the environment variable doesn't
|
|
|
|
|
exist. All other settings, including those which don't seem to make
|
|
|
|
|
sense, indicate that it's on/enabled.
|
2020-08-27 16:53:13 +01:00
|
|
|
|
|
|
|
|
This option is equivalent to passing @option{-B} to the real
|
|
|
|
|
@command{python} executable.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end table
|
|
|
|
|
|
|
|
|
|
It is also possible to execute a Python script from the @value{GDBN}
|
|
|
|
|
interpreter:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@item source @file{script-name}
|
|
|
|
|
The script name must end with @samp{.py} and @value{GDBN} must be configured
|
|
|
|
|
to recognize the script language based on filename extension using
|
|
|
|
|
the @code{script-extension} setting. @xref{Extending GDB, ,Extending GDB}.
|
|
|
|
|
@end table
|
|
|
|
|
|
2021-05-05 13:46:36 +01:00
|
|
|
The following commands are intended to help debug @value{GDBN} itself:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@kindex set debug py-breakpoint
|
|
|
|
|
@kindex show debug py-breakpoint
|
|
|
|
|
@item set debug py-breakpoint on@r{|}off
|
|
|
|
|
@itemx show debug py-breakpoint
|
|
|
|
|
When @samp{on}, @value{GDBN} prints debug messages related to the
|
|
|
|
|
Python breakpoint API. This is @samp{off} by default.
|
2021-05-08 18:02:36 +01:00
|
|
|
|
|
|
|
|
@kindex set debug py-unwind
|
|
|
|
|
@kindex show debug py-unwind
|
|
|
|
|
@item set debug py-unwind on@r{|}off
|
|
|
|
|
@itemx show debug py-unwind
|
|
|
|
|
When @samp{on}, @value{GDBN} prints debug messages related to the
|
|
|
|
|
Python unwinder API. This is @samp{off} by default.
|
2021-05-05 13:46:36 +01:00
|
|
|
@end table
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Python API
|
|
|
|
|
@subsection Python API
|
|
|
|
|
@cindex python api
|
|
|
|
|
@cindex programming in python
|
|
|
|
|
|
|
|
|
|
You can get quick online help for @value{GDBN}'s Python API by issuing
|
|
|
|
|
the command @w{@kbd{python help (gdb)}}.
|
|
|
|
|
|
|
|
|
|
Functions and methods which have two or more optional arguments allow
|
|
|
|
|
them to be specified using keyword syntax. This allows passing some
|
|
|
|
|
optional arguments while skipping others. Example:
|
|
|
|
|
@w{@code{gdb.some_function ('foo', bar = 1, baz = 2)}}.
|
|
|
|
|
|
|
|
|
|
@menu
|
|
|
|
|
* Basic Python:: Basic Python Functions.
|
2023-07-04 09:15:54 -06:00
|
|
|
* Threading in GDB:: Using Python threads in GDB.
|
2014-02-17 10:35:03 -08:00
|
|
|
* Exception Handling:: How Python exceptions are translated.
|
|
|
|
|
* Values From Inferior:: Python representation of values.
|
|
|
|
|
* Types In Python:: Python representation of types.
|
|
|
|
|
* Pretty Printing API:: Pretty-printing values.
|
|
|
|
|
* Selecting Pretty-Printers:: How GDB chooses a pretty-printer.
|
|
|
|
|
* Writing a Pretty-Printer:: Writing a Pretty-Printer.
|
2023-01-10 00:06:41 -05:00
|
|
|
* Type Printing API:: Pretty-printing types.
|
2014-02-17 10:35:03 -08:00
|
|
|
* Frame Filter API:: Filtering Frames.
|
|
|
|
|
* Frame Decorator API:: Decorating Frames.
|
|
|
|
|
* Writing a Frame Filter:: Writing a Frame Filter.
|
2015-04-01 11:49:12 -07:00
|
|
|
* Unwinding Frames in Python:: Writing frame unwinder.
|
2014-03-30 16:24:50 -07:00
|
|
|
* Xmethods In Python:: Adding and replacing methods of C++ classes.
|
|
|
|
|
* Xmethod API:: Xmethod types.
|
|
|
|
|
* Writing an Xmethod:: Writing an xmethod.
|
2014-02-17 10:35:03 -08:00
|
|
|
* Inferiors In Python:: Python representation of inferiors (processes)
|
|
|
|
|
* Events In Python:: Listening for events from @value{GDBN}.
|
|
|
|
|
* Threads In Python:: Accessing inferior threads from Python.
|
2016-11-21 16:39:57 +01:00
|
|
|
* Recordings In Python:: Accessing recordings from Python.
|
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
|
|
|
* CLI Commands In Python:: Implementing new CLI commands in Python.
|
2023-05-18 12:15:59 -06:00
|
|
|
* GDB/MI Commands In Python:: Implementing new @sc{gdb/mi} commands in Python.
|
2023-10-10 11:22:56 +01:00
|
|
|
* GDB/MI Notifications In Python:: Implementing new @sc{gdb/mi} notifications in Python.
|
2014-02-17 10:35:03 -08:00
|
|
|
* Parameters In Python:: Adding new @value{GDBN} parameters.
|
|
|
|
|
* Functions In Python:: Writing new convenience functions.
|
|
|
|
|
* Progspaces In Python:: Program spaces.
|
|
|
|
|
* Objfiles In Python:: Object files.
|
|
|
|
|
* Frames In Python:: Accessing inferior stack frames from Python.
|
|
|
|
|
* Blocks In Python:: Accessing blocks from Python.
|
|
|
|
|
* Symbols In Python:: Python representation of symbols.
|
|
|
|
|
* Symbol Tables In Python:: Python representation of symbol tables.
|
|
|
|
|
* Line Tables In Python:: Python representation of line tables.
|
|
|
|
|
* Breakpoints In Python:: Manipulating breakpoints using Python.
|
|
|
|
|
* Finish Breakpoints in Python:: Setting Breakpoints on function return
|
|
|
|
|
using Python.
|
|
|
|
|
* Lazy Strings In Python:: Python representation of lazy strings.
|
2024-10-05 22:27:44 +03:00
|
|
|
* Colors In Python:: Python representation of colors.
|
2014-02-17 10:35:03 -08:00
|
|
|
* Architectures In Python:: Python representation of architectures.
|
gdb/python: Add gdb.Architecture.registers method
This commit adds a new method gdb.Architecture.registers that returns
an object of the new type gdb.RegisterDescriptorIterator. This
iterator returns objects of the new type gdb.RegisterDescriptor.
A RegisterDescriptor is not a way to read the value of a register,
this is already covered by Frame.read_register, a RegisterDescriptor
is simply a way to discover from Python, which registers are
available for a given architecture.
I did consider just returning a string, the name of each register,
instead of a RegisterDescriptor, however, I'm aware that it we don't
want to break the existing Python API in any way, so if I return just
a string now, but in the future we want more information about a
register then we would have to add a second API to get that
information. By going straight to a descriptor object now, it is easy
to add additional properties in the future should we wish to.
Right now the only property of a register that a user can access is
the name of the register.
In future we might want to be able to ask the register about is
register groups, or its type.
gdb/ChangeLog:
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c
* python/py-arch.c (archpy_registers): New function.
(arch_object_methods): Add 'registers' method.
* python/py-registers.c: New file.
* python/python-internal.h
(gdbpy_new_register_descriptor_iterator): Declare.
(gdbpy_initialize_registers): Declare.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_registers.
* NEWS: Mention additions to the Python API.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: New file.
gdb/doc/ChangeLog:
* python.texi (Python API): Add new section the menu.
(Frames In Python): Add new @anchor.
(Architectures In Python): Document new registers method.
(Registers In Python): New section.
2020-06-05 17:52:10 +01:00
|
|
|
* Registers In Python:: Python representation of registers.
|
2023-01-10 00:06:41 -05:00
|
|
|
* Connections In Python:: Python representation of connections.
|
2020-02-22 11:48:26 -07:00
|
|
|
* TUI Windows In Python:: Implementing new TUI windows.
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
* Disassembly In Python:: Instruction Disassembly In Python
|
gdb: implement missing debug handler hook for Python
This commit builds on the previous commit, and implements the
extension_language_ops::handle_missing_debuginfo function for Python.
This hook will give user supplied Python code a chance to help find
missing debug information.
The implementation of the new hook is pretty minimal within GDB's C++
code; most of the work is out-sourced to a Python implementation which
is modelled heavily on how GDB's Python frame unwinders are
implemented.
The following new commands are added as commands implemented in
Python, this is similar to how the Python unwinder commands are
implemented:
info missing-debug-handlers
enable missing-debug-handler LOCUS HANDLER
disable missing-debug-handler LOCUS HANDLER
To make use of this extension hook a user will create missing debug
information handler objects, and registers these handlers with GDB.
When GDB encounters an objfile that is missing debug information, each
handler is called in turn until one is able to help. Here is a
minimal handler that does nothing useful:
import gdb
import gdb.missing_debug
class MyFirstHandler(gdb.missing_debug.MissingDebugHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, objfile):
# This handler does nothing useful.
return None
gdb.missing_debug.register_handler(None, MyFirstHandler())
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing debug information, and GDB should ask
any other registered handlers.
By extending the __call__ method it is possible for the Python
extension to locate the debug information for objfile and return a
value that tells GDB how to use the information that has been located.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the debug information
for the objfile still couldn't be found. GDB will not call
any other handlers, and will continue without the debug
information for objfile.
- True: The handler has installed the debug information into a
location where GDB would normally expect to find it. GDB
should look again for the debug information.
- A string: The handler can return a filename, which is the file
containing the missing debug information. GDB will load
this file.
When a handler returns True, GDB will look again for the debug
information, but only using the standard built-in build-id and
.gnu_debuglink based lookup strategies. It is not possible for an
extension to trigger another debuginfod lookup; the assumption is that
the debuginfod server is remote, and out of the control of extensions
running within GDB.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the objfile, at which point GDB continues.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
2023-10-15 22:48:42 +01:00
|
|
|
* Missing Debug Info In Python:: Handle missing debug info from Python.
|
gdb/python: implement Python find_exec_by_build_id hook
Implement extension_language_ops::find_objfile_from_buildid within
GDB's Python API. Doing this allows users to write Python extensions
that can help locate missing objfiles when GDB opens a core file. A
handler might perform some project- or site-specific actions to find a
missing objfile. Or might provide some project- or site-specific
advice to the user on how they can obtain the missing objfile.
The implementation is very similar to the approach taken in:
commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416
Date: Sun Oct 15 22:48:42 2023 +0100
gdb: implement missing debug handler hook for Python
The following new commands are added as commands implemented in
Python, this is similar to how the Python missing debug and unwinder
commands are implemented:
info missing-objfile-handlers
enable missing-objfile-handler LOCUS HANDLER
disable missing-objfile-handler LOCUS HANDLER
To make use of this extension hook a user will create missing objfile
handler objects, and registers these handlers with GDB. When GDB
opens a core file and encounters a missing objfile each handler is
called in turn until one is able to help. Here is a minimal handler
that does nothing useful:
import gdb
import gdb.missing_objfile
class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, pspace, build_id, filename):
# This handler does nothing useful.
return None
gdb.missing_objfile.register_handler(None, MyFirstHandler())
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing objfile, and GDB should ask any other
registered handlers.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the objfile couldn't
be found. GDB will not call any other handlers, and will
continue without the objfile.
- True: The handler has installed the objfile into a location where
GDB would normally expect to find it. GDB should repeat its
normal lookup process and the objfile should now be found.
- A string: The handler can return a filename, which is the missing
objfile. GDB will load this file.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the missing objfile, at which point GDB continues.
The implementation of this feature is mostly straight forward. I have
reworked some of the missing debug file related code so that it can be
shared with this feature. E.g. gdb/python/lib/gdb/missing_files.py is
mostly content moved from gdb/python/lib/gdb/missing_debug.py, but
updated to be more generic. Now gdb/python/lib/gdb/missing_debug.py
and the new file gdb/python/lib/gdb/missing_objfile.py both call into
the missing_files.py file.
For gdb/python/lib/gdb/command/missing_files.py this is even more
extreme, gdb/python/lib/gdb/command/missing_debug.py is completely
gone now and gdb/python/lib/gdb/command/missing_files.py provides all
of the new commands in a generic way.
I have made one change to the existing Python API, I renamed the
attribute Progspace.missing_debug_handlers to
Progspace.missing_file_handlers. I don't see this as too
problematic. This attribute was only used to implement the missing
debug feature and was never documented beyond the fact that it
existed. There was no reason for users to be touching this attribute.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-07-31 15:55:57 +01:00
|
|
|
* Missing Objfiles In Python:: Handle objfiles from Python.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end menu
|
|
|
|
|
|
|
|
|
|
@node Basic Python
|
|
|
|
|
@subsubsection Basic Python
|
|
|
|
|
|
|
|
|
|
@cindex python stdout
|
|
|
|
|
@cindex python pagination
|
|
|
|
|
At startup, @value{GDBN} overrides Python's @code{sys.stdout} and
|
|
|
|
|
@code{sys.stderr} to print using @value{GDBN}'s output-paging streams.
|
|
|
|
|
A Python program which outputs to one of these streams may have its
|
|
|
|
|
output interrupted by the user (@pxref{Screen Size}). In this
|
|
|
|
|
situation, a Python @code{KeyboardInterrupt} exception is thrown.
|
|
|
|
|
|
|
|
|
|
Some care must be taken when writing Python code to run in
|
|
|
|
|
@value{GDBN}. Two things worth noting in particular:
|
|
|
|
|
|
|
|
|
|
@itemize @bullet
|
|
|
|
|
@item
|
2023-09-11 09:21:26 -06:00
|
|
|
@value{GDBN} installs handlers for @code{SIGCHLD} and @code{SIGINT}.
|
2014-02-17 10:35:03 -08:00
|
|
|
Python code must not override these, or even change the options using
|
|
|
|
|
@code{sigaction}. If your program changes the handling of these
|
|
|
|
|
signals, @value{GDBN} will most likely stop working correctly. Note
|
|
|
|
|
that it is unfortunately common for GUI toolkits to install a
|
2023-09-11 09:21:26 -06:00
|
|
|
@code{SIGCHLD} handler. When creating a new Python thread, you can
|
2025-04-24 07:36:19 -06:00
|
|
|
use @code{gdb.blocked_signals} or @code{gdb.Thread} to handle this
|
2023-09-11 09:21:26 -06:00
|
|
|
correctly; see @ref{Threading in GDB}.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@item
|
|
|
|
|
@value{GDBN} takes care to mark its internal file descriptors as
|
|
|
|
|
close-on-exec. However, this cannot be done in a thread-safe way on
|
|
|
|
|
all platforms. Your Python programs should be aware of this and
|
|
|
|
|
should both create new file descriptors with the close-on-exec flag
|
|
|
|
|
set and arrange to close unneeded file descriptors before starting a
|
|
|
|
|
child process.
|
|
|
|
|
@end itemize
|
|
|
|
|
|
|
|
|
|
@cindex python functions
|
|
|
|
|
@cindex python module
|
|
|
|
|
@cindex gdb module
|
|
|
|
|
@value{GDBN} introduces a new Python module, named @code{gdb}. All
|
|
|
|
|
methods and classes added by @value{GDBN} are placed in this module.
|
|
|
|
|
@value{GDBN} automatically @code{import}s the @code{gdb} module for
|
|
|
|
|
use in all scripts evaluated by the @code{python} command.
|
|
|
|
|
|
2018-09-13 11:53:22 -04:00
|
|
|
Some types of the @code{gdb} module come with a textual representation
|
|
|
|
|
(accessible through the @code{repr} or @code{str} functions). These are
|
|
|
|
|
offered for debugging purposes only, expect them to change over time.
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar gdb.PYTHONDIR
|
|
|
|
|
A string containing the python directory (@pxref{Python}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/python: new styling argument to gdb.execute
Currently, gdb.execute emits styled output when the command is sending
its output to GDB's stdout, and produces unstyled output when the
output is going to a string.
But it is not unreasonable that a user might wish to capture styled
output from a gdb.execute call, for example, the user might want to
display the styled output are part of some larger UI output block.
At the same time, I don't think it makes sense to always produce
styled output when capturing the output in a string; if what the user
wants is to parse the output, then the style escape sequences make
this far harder.
I propose that gdb.execute gain a new argument 'styling'. When False
we would always produce unstyled output, and when True we would
produce styled output if styling is not disabled by some other means.
For example, if GDB's 'set style enabled' is off, then I think
gdb.execute() should respect that. My assumption here is that
gdb.execute() might be executed by some extension. If the extension
thinks "styled output world work here", but the user hates styled
output, and has turned it off, then the extension should not be
forcing styled output on the user.
I chose 'styling' instead of 'styled' as the Python argument name
because we already use 'styling' in gdb.Value.format_string, and we
don't use 'styled' anywhere else. This is only a little bit of
consistency, but I still think it's a good thing.
The default for 'styling' will change depending on where the output is
going. When gdb.execute is sending the output to GDB's stdout then
the default for 'styling' is True. When the output is going to a
string, then the default for 'styling' will be False. Not only does
this match the existing behaviour, but I think this makes sense. By
default we assume that output captured in a string is going to be
parsed, and therefore styling markup is unhelpful, while output going
to stdout should receive styling.
This fixes part of the problem described in PR gdb/32676. That bug
tries to capture styled source listing in a string, which wasn't
previously possible.
There are some additional issues with capturing source code; GDB
caches the source code in the source code cache. However, GDB doesn't
check if the cached content is styled or not. As a consequence, if
the first time the source of a file is shown it is unstyled, then the
cached will hold the unstyled source code, and future requests will
return that unstyled source. I'll address this issue in a separate
patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676
Approved-By: Tom Tromey <tom@tromey.com>
2025-02-13 15:39:31 +00:00
|
|
|
@defun gdb.execute (command @r{[}, from_tty @r{[}, to_string @w{@r{[}, styling @r{]]]}})
|
2014-02-17 10:35:03 -08:00
|
|
|
Evaluate @var{command}, a string, as a @value{GDBN} CLI command.
|
|
|
|
|
If a GDB exception happens while @var{command} runs, it is
|
|
|
|
|
translated as described in @ref{Exception Handling,,Exception Handling}.
|
|
|
|
|
|
Don't use @var at the beginning of a sentence in GDB documentation.
gdb/doc/guile.texi (Types In Guile, Basic Guile, Frames In Guile)
(Breakpoints In Guile, Guile Printing Module)
(Guile Exception Handling, Values From Inferior In Guile)
(Objfiles In Guile, Breakpoints In Guile, Memory Ports in Guile):
Don't use @var at the beginning of a sentence.
gdb/doc/gdb.texinfo (Frame Filter Management, Trace Files)
(C Operators, Ada Tasks, Calling, Bootstrapping, ARM)
(PowerPC Embedded, Define, Annotations for Running)
(IPA Protocol Commands, Packets, General Query Packets)
(Tracepoint Packets, Notification Packets, Environment)
(Inferiors and Programs, Set Breaks, Set Catchpoints)
(Continuing and Stepping, Signals, Thread-Specific Breakpoints)
(Frames, Backtrace, Selection, Expressions, Registers)
(Trace State Variables, Built-In Func/Proc, Signaling, Files)
(Numbers, GDB/MI Async Records, GDB/MI Data Manipulation)
(Source Annotations, Using JIT Debug Info Readers, Packets)
(Stop Reply Packets, Host I/O Packets)
(Target Description Format): Don't use @var at the beginning of a
sentence.
gdb/doc/python.texi (Basic Python, Types In Python)
(Commands In Python, Frames In Python, Line Tables In Python)
(Breakpoints In Python, gdb.printing, gdb.types)
(Type Printing API): Don't use @var at the beginning of a
sentence.
2014-05-24 13:02:42 +03:00
|
|
|
The @var{from_tty} flag specifies whether @value{GDBN} ought to consider this
|
2014-02-17 10:35:03 -08:00
|
|
|
command as having originated from the user invoking it interactively.
|
|
|
|
|
It must be a boolean value. If omitted, it defaults to @code{False}.
|
|
|
|
|
|
|
|
|
|
By default, any output produced by @var{command} is sent to
|
2014-05-17 09:13:00 -07:00
|
|
|
@value{GDBN}'s standard output (and to the log output if logging is
|
|
|
|
|
turned on). If the @var{to_string} parameter is
|
2014-02-17 10:35:03 -08:00
|
|
|
@code{True}, then output will be collected by @code{gdb.execute} and
|
|
|
|
|
returned as a string. The default is @code{False}, in which case the
|
|
|
|
|
return value is @code{None}. If @var{to_string} is @code{True}, the
|
|
|
|
|
@value{GDBN} virtual terminal will be temporarily set to unlimited width
|
|
|
|
|
and height, and its pagination will be disabled; @pxref{Screen Size}.
|
gdb/python: new styling argument to gdb.execute
Currently, gdb.execute emits styled output when the command is sending
its output to GDB's stdout, and produces unstyled output when the
output is going to a string.
But it is not unreasonable that a user might wish to capture styled
output from a gdb.execute call, for example, the user might want to
display the styled output are part of some larger UI output block.
At the same time, I don't think it makes sense to always produce
styled output when capturing the output in a string; if what the user
wants is to parse the output, then the style escape sequences make
this far harder.
I propose that gdb.execute gain a new argument 'styling'. When False
we would always produce unstyled output, and when True we would
produce styled output if styling is not disabled by some other means.
For example, if GDB's 'set style enabled' is off, then I think
gdb.execute() should respect that. My assumption here is that
gdb.execute() might be executed by some extension. If the extension
thinks "styled output world work here", but the user hates styled
output, and has turned it off, then the extension should not be
forcing styled output on the user.
I chose 'styling' instead of 'styled' as the Python argument name
because we already use 'styling' in gdb.Value.format_string, and we
don't use 'styled' anywhere else. This is only a little bit of
consistency, but I still think it's a good thing.
The default for 'styling' will change depending on where the output is
going. When gdb.execute is sending the output to GDB's stdout then
the default for 'styling' is True. When the output is going to a
string, then the default for 'styling' will be False. Not only does
this match the existing behaviour, but I think this makes sense. By
default we assume that output captured in a string is going to be
parsed, and therefore styling markup is unhelpful, while output going
to stdout should receive styling.
This fixes part of the problem described in PR gdb/32676. That bug
tries to capture styled source listing in a string, which wasn't
previously possible.
There are some additional issues with capturing source code; GDB
caches the source code in the source code cache. However, GDB doesn't
check if the cached content is styled or not. As a consequence, if
the first time the source of a file is shown it is unstyled, then the
cached will hold the unstyled source code, and future requests will
return that unstyled source. I'll address this issue in a separate
patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676
Approved-By: Tom Tromey <tom@tromey.com>
2025-02-13 15:39:31 +00:00
|
|
|
|
|
|
|
|
When @var{styling} is @code{True}, the output, whether sent to
|
|
|
|
|
standard output, or to a string, will have styling applied, if
|
|
|
|
|
@value{GDBN}'s standard output supports styling, and @kbd{show style
|
|
|
|
|
enabled} is @kbd{on}. When @var{styling} is @code{False} then no
|
|
|
|
|
styling is applied. The default for @var{styling} is @code{True} when
|
|
|
|
|
@var{to_string} is @code{False}, and @code{False} when @var{to_string}
|
|
|
|
|
is @code{True}.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.breakpoints ()
|
|
|
|
|
Return a sequence holding all of @value{GDBN}'s breakpoints.
|
2016-05-18 21:41:28 -06:00
|
|
|
@xref{Breakpoints In Python}, for more information. In @value{GDBN}
|
|
|
|
|
version 7.11 and earlier, this function returned @code{None} if there
|
|
|
|
|
were no breakpoints. This peculiarity was subsequently fixed, and now
|
|
|
|
|
@code{gdb.breakpoints} returns an empty sequence in this case.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
2017-11-16 14:14:03 +00:00
|
|
|
@defun gdb.rbreak (regex @r{[}, minsyms @r{[}, throttle, @r{[}, symtabs @r{]]]})
|
|
|
|
|
Return a Python list holding a collection of newly set
|
|
|
|
|
@code{gdb.Breakpoint} objects matching function names defined by the
|
|
|
|
|
@var{regex} pattern. If the @var{minsyms} keyword is @code{True}, all
|
|
|
|
|
system functions (those not explicitly defined in the inferior) will
|
|
|
|
|
also be included in the match. The @var{throttle} keyword takes an
|
|
|
|
|
integer that defines the maximum number of pattern matches for
|
|
|
|
|
functions matched by the @var{regex} pattern. If the number of
|
|
|
|
|
matches exceeds the integer value of @var{throttle}, a
|
|
|
|
|
@code{RuntimeError} will be raised and no breakpoints will be created.
|
|
|
|
|
If @var{throttle} is not defined then there is no imposed limit on the
|
|
|
|
|
maximum number of matches and breakpoints to be created. The
|
|
|
|
|
@var{symtabs} keyword takes a Python iterable that yields a collection
|
|
|
|
|
of @code{gdb.Symtab} objects and will restrict the search to those
|
|
|
|
|
functions only contained within the @code{gdb.Symtab} objects.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun gdb.parameter (parameter)
|
Don't use @var at the beginning of a sentence in GDB documentation.
gdb/doc/guile.texi (Types In Guile, Basic Guile, Frames In Guile)
(Breakpoints In Guile, Guile Printing Module)
(Guile Exception Handling, Values From Inferior In Guile)
(Objfiles In Guile, Breakpoints In Guile, Memory Ports in Guile):
Don't use @var at the beginning of a sentence.
gdb/doc/gdb.texinfo (Frame Filter Management, Trace Files)
(C Operators, Ada Tasks, Calling, Bootstrapping, ARM)
(PowerPC Embedded, Define, Annotations for Running)
(IPA Protocol Commands, Packets, General Query Packets)
(Tracepoint Packets, Notification Packets, Environment)
(Inferiors and Programs, Set Breaks, Set Catchpoints)
(Continuing and Stepping, Signals, Thread-Specific Breakpoints)
(Frames, Backtrace, Selection, Expressions, Registers)
(Trace State Variables, Built-In Func/Proc, Signaling, Files)
(Numbers, GDB/MI Async Records, GDB/MI Data Manipulation)
(Source Annotations, Using JIT Debug Info Readers, Packets)
(Stop Reply Packets, Host I/O Packets)
(Target Description Format): Don't use @var at the beginning of a
sentence.
gdb/doc/python.texi (Basic Python, Types In Python)
(Commands In Python, Frames In Python, Line Tables In Python)
(Breakpoints In Python, gdb.printing, gdb.types)
(Type Printing API): Don't use @var at the beginning of a
sentence.
2014-05-24 13:02:42 +03:00
|
|
|
Return the value of a @value{GDBN} @var{parameter} given by its name,
|
|
|
|
|
a string; the parameter name string may contain spaces if the parameter has a
|
|
|
|
|
multi-part name. For example, @samp{print object} is a valid
|
|
|
|
|
parameter name.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
If the named parameter does not exist, this function throws a
|
|
|
|
|
@code{gdb.error} (@pxref{Exception Handling}). Otherwise, the
|
|
|
|
|
parameter's value is converted to a Python value of the appropriate
|
|
|
|
|
type, and returned.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2022-01-04 11:00:52 -07:00
|
|
|
@defun gdb.set_parameter (name, value)
|
|
|
|
|
Sets the gdb parameter @var{name} to @var{value}. As with
|
|
|
|
|
@code{gdb.parameter}, the parameter name string may contain spaces if
|
|
|
|
|
the parameter has a multi-part name.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.with_parameter (name, value)
|
|
|
|
|
Create a Python context manager (for use with the Python
|
|
|
|
|
@command{with} statement) that temporarily sets the gdb parameter
|
|
|
|
|
@var{name} to @var{value}. On exit from the context, the previous
|
|
|
|
|
value will be restored.
|
|
|
|
|
|
|
|
|
|
This uses @code{gdb.parameter} in its implementation, so it can throw
|
|
|
|
|
the same exceptions as that function.
|
|
|
|
|
|
|
|
|
|
For example, it's sometimes useful to evaluate some Python code with a
|
|
|
|
|
particular gdb language:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
with gdb.with_parameter('language', 'pascal'):
|
|
|
|
|
... language-specific operations
|
|
|
|
|
@end smallexample
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun gdb.history (number)
|
|
|
|
|
Return a value from @value{GDBN}'s value history (@pxref{Value
|
Don't use @var at the beginning of a sentence in GDB documentation.
gdb/doc/guile.texi (Types In Guile, Basic Guile, Frames In Guile)
(Breakpoints In Guile, Guile Printing Module)
(Guile Exception Handling, Values From Inferior In Guile)
(Objfiles In Guile, Breakpoints In Guile, Memory Ports in Guile):
Don't use @var at the beginning of a sentence.
gdb/doc/gdb.texinfo (Frame Filter Management, Trace Files)
(C Operators, Ada Tasks, Calling, Bootstrapping, ARM)
(PowerPC Embedded, Define, Annotations for Running)
(IPA Protocol Commands, Packets, General Query Packets)
(Tracepoint Packets, Notification Packets, Environment)
(Inferiors and Programs, Set Breaks, Set Catchpoints)
(Continuing and Stepping, Signals, Thread-Specific Breakpoints)
(Frames, Backtrace, Selection, Expressions, Registers)
(Trace State Variables, Built-In Func/Proc, Signaling, Files)
(Numbers, GDB/MI Async Records, GDB/MI Data Manipulation)
(Source Annotations, Using JIT Debug Info Readers, Packets)
(Stop Reply Packets, Host I/O Packets)
(Target Description Format): Don't use @var at the beginning of a
sentence.
gdb/doc/python.texi (Basic Python, Types In Python)
(Commands In Python, Frames In Python, Line Tables In Python)
(Breakpoints In Python, gdb.printing, gdb.types)
(Type Printing API): Don't use @var at the beginning of a
sentence.
2014-05-24 13:02:42 +03:00
|
|
|
History}). The @var{number} argument indicates which history element to return.
|
2014-02-17 10:35:03 -08:00
|
|
|
If @var{number} is negative, then @value{GDBN} will take its absolute value
|
|
|
|
|
and count backward from the last element (i.e., the most recent element) to
|
|
|
|
|
find the value to return. If @var{number} is zero, then @value{GDBN} will
|
|
|
|
|
return the most recent element. If the element specified by @var{number}
|
|
|
|
|
doesn't exist in the value history, a @code{gdb.error} exception will be
|
|
|
|
|
raised.
|
|
|
|
|
|
|
|
|
|
If no exception is raised, the return value is always an instance of
|
|
|
|
|
@code{gdb.Value} (@pxref{Values From Inferior}).
|
|
|
|
|
@end defun
|
|
|
|
|
|
2021-07-30 12:56:34 +01:00
|
|
|
@defun gdb.add_history (value)
|
|
|
|
|
Takes @var{value}, an instance of @code{gdb.Value} (@pxref{Values From
|
|
|
|
|
Inferior}), and appends the value this object represents to
|
|
|
|
|
@value{GDBN}'s value history (@pxref{Value History}), and return an
|
|
|
|
|
integer, its history number. If @var{value} is not a
|
|
|
|
|
@code{gdb.Value}, it is is converted using the @code{gdb.Value}
|
|
|
|
|
constructor. If @var{value} can't be converted to a @code{gdb.Value}
|
|
|
|
|
then a @code{TypeError} is raised.
|
|
|
|
|
|
|
|
|
|
When a command implemented in Python prints a single @code{gdb.Value}
|
|
|
|
|
as its result, then placing the value into the history will allow the
|
|
|
|
|
user convenient access to those values via CLI history facilities.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2022-01-24 15:19:43 +00:00
|
|
|
@defun gdb.history_count ()
|
|
|
|
|
Return an integer indicating the number of values in @value{GDBN}'s
|
|
|
|
|
value history (@pxref{Value History}).
|
|
|
|
|
@end defun
|
|
|
|
|
|
2018-04-22 15:13:09 -06:00
|
|
|
@defun gdb.convenience_variable (name)
|
|
|
|
|
Return the value of the convenience variable (@pxref{Convenience
|
|
|
|
|
Vars}) named @var{name}. @var{name} must be a string. The name
|
|
|
|
|
should not include the @samp{$} that is used to mark a convenience
|
|
|
|
|
variable in an expression. If the convenience variable does not
|
|
|
|
|
exist, then @code{None} is returned.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.set_convenience_variable (name, value)
|
|
|
|
|
Set the value of the convenience variable (@pxref{Convenience Vars})
|
|
|
|
|
named @var{name}. @var{name} must be a string. The name should not
|
|
|
|
|
include the @samp{$} that is used to mark a convenience variable in an
|
|
|
|
|
expression. If @var{value} is @code{None}, then the convenience
|
|
|
|
|
variable is removed. Otherwise, if @var{value} is not a
|
|
|
|
|
@code{gdb.Value} (@pxref{Values From Inferior}), it is is converted
|
|
|
|
|
using the @code{gdb.Value} constructor.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-04-28 09:11:23 -06:00
|
|
|
@defun gdb.parse_and_eval (expression @r{[}, global_context@r{]})
|
Don't use @var at the beginning of a sentence in GDB documentation.
gdb/doc/guile.texi (Types In Guile, Basic Guile, Frames In Guile)
(Breakpoints In Guile, Guile Printing Module)
(Guile Exception Handling, Values From Inferior In Guile)
(Objfiles In Guile, Breakpoints In Guile, Memory Ports in Guile):
Don't use @var at the beginning of a sentence.
gdb/doc/gdb.texinfo (Frame Filter Management, Trace Files)
(C Operators, Ada Tasks, Calling, Bootstrapping, ARM)
(PowerPC Embedded, Define, Annotations for Running)
(IPA Protocol Commands, Packets, General Query Packets)
(Tracepoint Packets, Notification Packets, Environment)
(Inferiors and Programs, Set Breaks, Set Catchpoints)
(Continuing and Stepping, Signals, Thread-Specific Breakpoints)
(Frames, Backtrace, Selection, Expressions, Registers)
(Trace State Variables, Built-In Func/Proc, Signaling, Files)
(Numbers, GDB/MI Async Records, GDB/MI Data Manipulation)
(Source Annotations, Using JIT Debug Info Readers, Packets)
(Stop Reply Packets, Host I/O Packets)
(Target Description Format): Don't use @var at the beginning of a
sentence.
gdb/doc/python.texi (Basic Python, Types In Python)
(Commands In Python, Frames In Python, Line Tables In Python)
(Breakpoints In Python, gdb.printing, gdb.types)
(Type Printing API): Don't use @var at the beginning of a
sentence.
2014-05-24 13:02:42 +03:00
|
|
|
Parse @var{expression}, which must be a string, as an expression in
|
|
|
|
|
the current language, evaluate it, and return the result as a
|
|
|
|
|
@code{gdb.Value}.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2023-04-28 09:11:23 -06:00
|
|
|
@var{global_context}, if provided, is a boolean indicating whether the
|
|
|
|
|
parsing should be done in the global context. The default is
|
|
|
|
|
@samp{False}, meaning that the current frame or current static context
|
|
|
|
|
should be used.
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
This function can be useful when implementing a new command
|
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
|
|
|
(@pxref{CLI Commands In Python}, @pxref{GDB/MI Commands In Python}),
|
|
|
|
|
as it provides a way to parse the
|
2014-02-17 10:35:03 -08:00
|
|
|
command's argument as an expression. It is also useful simply to
|
2018-04-22 15:13:09 -06:00
|
|
|
compute values.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.find_pc_line (pc)
|
|
|
|
|
Return the @code{gdb.Symtab_and_line} object corresponding to the
|
|
|
|
|
@var{pc} value. @xref{Symbol Tables In Python}. If an invalid
|
|
|
|
|
value of @var{pc} is passed as an argument, then the @code{symtab} and
|
|
|
|
|
@code{line} attributes of the returned @code{gdb.Symtab_and_line} object
|
Add more methods to gdb.Progspace
There are a number of global functions in the gdb Python module which
really should be methods on Progspace. This patch adds new methods to
Progspace and then redefines these globals in terms of these new
methods.
This version has been rebased on the related changes that Simon
recently put in.
Built and regtested on x86-64 Fedora 28.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/lib/gdb/__init__.py (current_progspace, objfiles)
(solib_name, block_for_pc, find_pc_line): New functions.
(execute_unwinders): Update.
* python/py-block.c (gdbpy_block_for_pc): Remove.
* python/py-inferior.c (infpy_get_progspace): New function.
(inferior_object_getset) <progspace>: Add.
* python/py-progspace.c (pspy_objfiles): Rewrite.
(pspy_solib_name, pspy_block_for_pc)
(pspy_find_pc_line, pspy_is_valid): New functions.
(progspace_object_methods): Add entries for solib_name,
block_for_pc, find_pc_line, is_valid.
* python/python-internal.h (gdbpy_block_for_pc)
(build_objfiles_list): Don't declare.
* python/python.c: Don't include solib.h.
(gdbpy_solib_name, gdbpy_find_pc_line)
(gdbpy_get_current_progspace, build_objfiles_list)
(gdbpy_objfiles): Remove.
(GdbMethods) <current_progspace, objfiles, block_for_pc,
solib_name, find_pc_line>: Remove entries.
gdb/doc/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python.texi (Basic Python): Update docs for find_pc_line,
solib_name.
(Progspaces In Python): Update docs for current_progspace.
Document block_for_pc, find_pc_line, is_valid, nsolib_name.
Move method documentation before example.
2013-12-26 19:50:05 -07:00
|
|
|
will be @code{None} and 0 respectively. This is identical to
|
|
|
|
|
@code{gdb.current_progspace().find_pc_line(pc)} and is included for
|
|
|
|
|
historical compatibility.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
2022-01-21 12:49:48 +00:00
|
|
|
@defun gdb.write (string @r{[}, stream@r{]})
|
2014-02-17 10:35:03 -08:00
|
|
|
Print a string to @value{GDBN}'s paginated output stream. The
|
|
|
|
|
optional @var{stream} determines the stream to print to. The default
|
|
|
|
|
stream is @value{GDBN}'s standard output stream. Possible stream
|
|
|
|
|
values are:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@findex STDOUT
|
|
|
|
|
@findex gdb.STDOUT
|
|
|
|
|
@item gdb.STDOUT
|
|
|
|
|
@value{GDBN}'s standard output stream.
|
|
|
|
|
|
|
|
|
|
@findex STDERR
|
|
|
|
|
@findex gdb.STDERR
|
|
|
|
|
@item gdb.STDERR
|
|
|
|
|
@value{GDBN}'s standard error stream.
|
|
|
|
|
|
|
|
|
|
@findex STDLOG
|
|
|
|
|
@findex gdb.STDLOG
|
|
|
|
|
@item gdb.STDLOG
|
|
|
|
|
@value{GDBN}'s log stream (@pxref{Logging Output}).
|
|
|
|
|
@end table
|
|
|
|
|
|
|
|
|
|
Writing to @code{sys.stdout} or @code{sys.stderr} will automatically
|
|
|
|
|
call this function and will automatically direct the output to the
|
|
|
|
|
relevant stream.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2022-08-15 12:44:53 -06:00
|
|
|
@defun gdb.flush (@r{[}, stream@r{]})
|
2014-02-17 10:35:03 -08:00
|
|
|
Flush the buffer of a @value{GDBN} paginated stream so that the
|
|
|
|
|
contents are displayed immediately. @value{GDBN} will flush the
|
|
|
|
|
contents of a stream automatically when it encounters a newline in the
|
|
|
|
|
buffer. The optional @var{stream} determines the stream to flush. The
|
|
|
|
|
default stream is @value{GDBN}'s standard output stream. Possible
|
|
|
|
|
stream values are:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@findex STDOUT
|
|
|
|
|
@findex gdb.STDOUT
|
|
|
|
|
@item gdb.STDOUT
|
|
|
|
|
@value{GDBN}'s standard output stream.
|
|
|
|
|
|
|
|
|
|
@findex STDERR
|
|
|
|
|
@findex gdb.STDERR
|
|
|
|
|
@item gdb.STDERR
|
|
|
|
|
@value{GDBN}'s standard error stream.
|
|
|
|
|
|
|
|
|
|
@findex STDLOG
|
|
|
|
|
@findex gdb.STDLOG
|
|
|
|
|
@item gdb.STDLOG
|
|
|
|
|
@value{GDBN}'s log stream (@pxref{Logging Output}).
|
|
|
|
|
|
|
|
|
|
@end table
|
|
|
|
|
|
|
|
|
|
Flushing @code{sys.stdout} or @code{sys.stderr} will automatically
|
|
|
|
|
call this function for the relevant stream.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.target_charset ()
|
|
|
|
|
Return the name of the current target character set (@pxref{Character
|
|
|
|
|
Sets}). This differs from @code{gdb.parameter('target-charset')} in
|
|
|
|
|
that @samp{auto} is never returned.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.target_wide_charset ()
|
|
|
|
|
Return the name of the current target wide character set
|
|
|
|
|
(@pxref{Character Sets}). This differs from
|
|
|
|
|
@code{gdb.parameter('target-wide-charset')} in that @samp{auto} is
|
|
|
|
|
never returned.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2022-01-12 11:52:19 +00:00
|
|
|
@defun gdb.host_charset ()
|
|
|
|
|
Return a string, the name of the current host character set
|
|
|
|
|
(@pxref{Character Sets}). This differs from
|
|
|
|
|
@code{gdb.parameter('host-charset')} in that @samp{auto} is never
|
|
|
|
|
returned.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun gdb.solib_name (address)
|
|
|
|
|
Return the name of the shared library holding the given @var{address}
|
Add more methods to gdb.Progspace
There are a number of global functions in the gdb Python module which
really should be methods on Progspace. This patch adds new methods to
Progspace and then redefines these globals in terms of these new
methods.
This version has been rebased on the related changes that Simon
recently put in.
Built and regtested on x86-64 Fedora 28.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/lib/gdb/__init__.py (current_progspace, objfiles)
(solib_name, block_for_pc, find_pc_line): New functions.
(execute_unwinders): Update.
* python/py-block.c (gdbpy_block_for_pc): Remove.
* python/py-inferior.c (infpy_get_progspace): New function.
(inferior_object_getset) <progspace>: Add.
* python/py-progspace.c (pspy_objfiles): Rewrite.
(pspy_solib_name, pspy_block_for_pc)
(pspy_find_pc_line, pspy_is_valid): New functions.
(progspace_object_methods): Add entries for solib_name,
block_for_pc, find_pc_line, is_valid.
* python/python-internal.h (gdbpy_block_for_pc)
(build_objfiles_list): Don't declare.
* python/python.c: Don't include solib.h.
(gdbpy_solib_name, gdbpy_find_pc_line)
(gdbpy_get_current_progspace, build_objfiles_list)
(gdbpy_objfiles): Remove.
(GdbMethods) <current_progspace, objfiles, block_for_pc,
solib_name, find_pc_line>: Remove entries.
gdb/doc/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python.texi (Basic Python): Update docs for find_pc_line,
solib_name.
(Progspaces In Python): Update docs for current_progspace.
Document block_for_pc, find_pc_line, is_valid, nsolib_name.
Move method documentation before example.
2013-12-26 19:50:05 -07:00
|
|
|
as a string, or @code{None}. This is identical to
|
|
|
|
|
@code{gdb.current_progspace().solib_name(address)} and is included for
|
|
|
|
|
historical compatibility.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
2018-09-08 13:40:50 -06:00
|
|
|
@defun gdb.decode_line (@r{[}expression@r{]})
|
2014-02-17 10:35:03 -08:00
|
|
|
Return locations of the line specified by @var{expression}, or of the
|
|
|
|
|
current line if no argument was given. This function returns a Python
|
|
|
|
|
tuple containing two elements. The first element contains a string
|
|
|
|
|
holding any unparsed section of @var{expression} (or @code{None} if
|
|
|
|
|
the expression has been fully parsed). The second element contains
|
|
|
|
|
either @code{None} or another tuple that contains all the locations
|
|
|
|
|
that match the expression represented as @code{gdb.Symtab_and_line}
|
|
|
|
|
objects (@pxref{Symbol Tables In Python}). If @var{expression} is
|
|
|
|
|
provided, it is decoded the way that @value{GDBN}'s inbuilt
|
gdb/manual: Introduce location specs
The current "Specify Location" section of the GDB manual starts with:
"Several @value{GDBN} commands accept arguments that specify a location
of your program's code."
And then, such commands are documented as taking a "location"
argument. For example, here's a representative subset:
@item break @var{location}
@item clear @var{location}
@item until @var{location}
@item list @var{location}
@item edit @var{location}
@itemx info line @var{location}
@item info macros @var{location}
@item trace @var{location}
@item info scope @var{location}
@item maint agent @r{[}-at @var{location}@r{,}@r{]} @var{expression}
The issue here is that "location" isn't really correct for most of
these commands. Instead, the "location" argument is really a
placeholder that represent an umbrella term for all of the
"linespecs", "explicit location", and "address location" input
formats. GDB parses these and then finds the actual code locations
(plural) in the program that match. For example, a "location"
specified like "-function func" will actually match all the code
locations in the program that correspond to the address/file/lineno of
all the functions named "func" in all the loaded programs and shared
libraries of all the inferiors. A location specified like "-function
func -label lab" matches all the addresses of C labels named "lab" in
all functions named "func". Etc.
This means that several of the commands that claim they accept a
"location", actually end up working with multiple locations, and the
manual doesn't explain that all that well. In some cases, the command
will work with all the resolved locations. In other cases, the
command aborts with an error if the location specification resolves to
multiple locations in the program. In other cases, GDB just
arbitrarily and silently picks whatever is the first resolved code
location (which sounds like should be improved).
To clarify this, I propose we use the term "Location Specification",
with shorthand "locaction spec", when we're talking about the user
input, the argument or arguments that is/are passed to commands to
instruct GDB how to find locations of interest. This is distinct from
the actual code locations in the program, which are what GDB finds
based on the user-specified location spec. Then use "location
specification or the shorter "location spec" thoughout instead of
"location" when we're talking about the user input.
Thus, this commit does the following:
- renames the "Specify Location" section of the manual to "Location
Specifications".
- It then introduces the term "Location Specification", with
corresponding shorthand "location spec", as something distinct from
an actual code location in the program. It explains what a concrete
code location is. It explains that a location specification may be
incomplete, and that may match multiple code locations in the
program, or no code location at all. It gives examples. Some
pre-existing examples were moved from the "Set Breaks" section, and
a few new ones that didn't exist yet were added. I think it is
better to have these centralized in this "Location Specification"
section, since all the other commands that accept a location spec
have an xref that points there.
- Goes through the manual, and where "@var{location}" was used for a
command argument, updated it to say "@var{locspec}" instead. At the
same time, tweaks the description of the affected commands to
describe what happens when the location spec resolves to more than
one location. Most commands just did not say anything about that.
One command -- "maint agent -at @var{location}" -- currently says it
accepts a "location", suggesting it can accept address and explicit
locations too, but that's incorrect. In reality, it only accepts
linespecs, so fix it accordingly.
One MI command -- "-trace-find line" -- currently says it accepts a
"line specification", but it can accept address and explicit
locations too, so fix it accordingly.
Special thanks goes to Eli Zaretskii for reviews and rewording
suggestions.
Change-Id: Ic42ad8565e79ca67bfebb22cbb4794ea816fd08b
2022-05-17 13:12:04 +01:00
|
|
|
@code{break} or @code{edit} commands do (@pxref{Location
|
|
|
|
|
Specifications}).
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.prompt_hook (current_prompt)
|
|
|
|
|
@anchor{prompt_hook}
|
|
|
|
|
|
|
|
|
|
If @var{prompt_hook} is callable, @value{GDBN} will call the method
|
|
|
|
|
assigned to this operation before a prompt is displayed by
|
|
|
|
|
@value{GDBN}.
|
|
|
|
|
|
|
|
|
|
The parameter @code{current_prompt} contains the current @value{GDBN}
|
|
|
|
|
prompt. This method must return a Python string, or @code{None}. If
|
|
|
|
|
a string is returned, the @value{GDBN} prompt will be set to that
|
|
|
|
|
string. If @code{None} is returned, @value{GDBN} will continue to use
|
|
|
|
|
the current prompt.
|
|
|
|
|
|
|
|
|
|
Some prompts cannot be substituted in @value{GDBN}. Secondary prompts
|
|
|
|
|
such as those used by readline for command input, and annotation
|
|
|
|
|
related prompts are prohibited from being changed.
|
|
|
|
|
@end defun
|
|
|
|
|
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
@anchor{gdb_architecture_names}
|
2021-09-15 13:34:14 +01:00
|
|
|
@defun gdb.architecture_names ()
|
|
|
|
|
Return a list containing all of the architecture names that the
|
|
|
|
|
current build of @value{GDBN} supports. Each architecture name is a
|
|
|
|
|
string. The names returned in this list are the same names as are
|
|
|
|
|
returned from @code{gdb.Architecture.name}
|
|
|
|
|
(@pxref{gdbpy_architecture_name,,Architecture.name}).
|
|
|
|
|
@end defun
|
|
|
|
|
|
gdb/python: introduce gdb.TargetConnection object type
This commit adds a new object type gdb.TargetConnection. This new
type represents a connection within GDB (a connection as displayed by
'info connections').
There's three ways to find a gdb.TargetConnection, there's a new
'gdb.connections()' function, which returns a list of all currently
active connections.
Or you can read the new 'connection' property on the gdb.Inferior
object type, this contains the connection for that inferior (or None
if the inferior has no connection, for example, it is exited).
Finally, there's a new gdb.events.connection_removed event registry,
this emits a new gdb.ConnectionEvent whenever a connection is removed
from GDB (this can happen when all inferiors using a connection exit,
though this is not always the case, depending on the connection type).
The gdb.ConnectionEvent has a 'connection' property, which is the
gdb.TargetConnection being removed from GDB.
The gdb.TargetConnection has an 'is_valid()' method. A connection
object becomes invalid when the underlying connection is removed from
GDB (as discussed above, this might be when all inferiors using a
connection exit, or it might be when the user explicitly replaces a
connection in GDB by issuing another 'target' command).
The gdb.TargetConnection has the following read-only properties:
'num': The number for this connection,
'type': e.g. 'native', 'remote', 'sim', etc
'description': The longer description as seen in the 'info
connections' command output.
'details': A string or None. Extra details for the connection, for
example, a remote connection's details might be
'hostname:port'.
2021-09-01 15:33:19 +01:00
|
|
|
@anchor{gdbpy_connections}
|
|
|
|
|
@defun gdb.connections
|
|
|
|
|
Return a list of @code{gdb.TargetConnection} objects, one for each
|
|
|
|
|
currently active connection (@pxref{Connections In Python}). The
|
|
|
|
|
connection objects are in no particular order in the returned list.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun gdb.format_address (address @r{[}, progspace, architecture@r{]})
|
gdb/python: add gdb.format_address function
Add a new function, gdb.format_address, which is a wrapper around
GDB's print_address function.
This method takes an address, and returns a string with the format:
ADDRESS <SYMBOL+OFFSET>
Where, ADDRESS is the original address, formatted as hexadecimal,
SYMBOL is a symbol with an address lower than ADDRESS, and OFFSET is
the offset from SYMBOL to ADDRESS in decimal.
If there's no SYMBOL suitably close to ADDRESS then the
<SYMBOL+OFFSET> part is not included.
This is useful if a user wants to write a Python script that
pretty-prints addresses, the user no longer needs to do manual symbol
lookup, or worry about correctly formatting addresses.
Additionally, there are some settings that effect how GDB picks
SYMBOL, and whether the file name and line number should be included
with the SYMBOL name, the gdb.format_address function ensures that the
users Python script also benefits from these settings.
The gdb.format_address by default selects SYMBOL from the current
inferiors program space, and address is formatted using the
architecture for the current inferior. However, a user can also
explicitly pass a program space and architecture like this:
gdb.format_address(ADDRESS, PROGRAM_SPACE, ARCHITECTURE)
In order to format an address for a different inferior.
Notes on the implementation:
In py-arch.c I extended arch_object_to_gdbarch to add an assertion for
the type of the PyObject being worked on. Prior to this commit all
uses of arch_object_to_gdbarch were guaranteed to pass this function a
gdb.Architecture object, but, with this commit, this might not be the
case.
So, with this commit I've made it a requirement that the PyObject be a
gdb.Architecture, and this is checked with the assert. And in order
that callers from other files can check if they have a
gdb.Architecture object, I've added the new function
gdbpy_is_architecture.
In py-progspace.c I've added two new function, the first
progspace_object_to_program_space, converts a PyObject of type
gdb.Progspace to the associated program_space pointer, and
gdbpy_is_progspace checks if a PyObject is a gdb.Progspace or not.
2021-10-23 09:59:25 +01:00
|
|
|
Return a string in the format @samp{@var{addr}
|
|
|
|
|
<@var{symbol}+@var{offset}>}, where @var{addr} is @var{address}
|
|
|
|
|
formatted in hexadecimal, @var{symbol} is the symbol whose address is
|
|
|
|
|
the nearest to @var{address} and below it in memory, and @var{offset}
|
|
|
|
|
is the offset from @var{symbol} to @var{address} in decimal.
|
|
|
|
|
|
|
|
|
|
If no suitable @var{symbol} was found, then the
|
|
|
|
|
<@var{symbol}+@var{offset}> part is not included in the returned
|
|
|
|
|
string, instead the returned string will just contain the
|
|
|
|
|
@var{address} formatted as hexadecimal. How far @value{GDBN} looks
|
|
|
|
|
back for a suitable symbol can be controlled with @kbd{set print
|
|
|
|
|
max-symbolic-offset} (@pxref{Print Settings}).
|
|
|
|
|
|
|
|
|
|
Additionally, the returned string can include file name and line
|
|
|
|
|
number information when @kbd{set print symbol-filename on}
|
|
|
|
|
(@pxref{Print Settings}), in this case the format of the returned
|
|
|
|
|
string is @samp{@var{addr} <@var{symbol}+@var{offset}> at
|
|
|
|
|
@var{filename}:@var{line-number}}.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The @var{progspace} is the gdb.Progspace in which @var{symbol} is
|
|
|
|
|
looked up, and @var{architecture} is used when formatting @var{addr},
|
|
|
|
|
e.g.@: in order to determine the size of an address in bytes.
|
|
|
|
|
|
|
|
|
|
If neither @var{progspace} or @var{architecture} are passed, then by
|
|
|
|
|
default @value{GDBN} will use the program space and architecture of
|
|
|
|
|
the currently selected inferior, thus, the following two calls are
|
|
|
|
|
equivalent:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
gdb.format_address(address)
|
|
|
|
|
gdb.format_address(address,
|
|
|
|
|
gdb.selected_inferior().progspace,
|
|
|
|
|
gdb.selected_inferior().architecture())
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
It is not valid to only pass one of @var{progspace} or
|
|
|
|
|
@var{architecture}, either they must both be provided, or neither must
|
|
|
|
|
be provided (and the defaults will be used).
|
|
|
|
|
|
|
|
|
|
This method uses the same mechanism for formatting address, symbol,
|
|
|
|
|
and offset information as core @value{GDBN} does in commands such as
|
|
|
|
|
@kbd{disassemble}.
|
|
|
|
|
|
|
|
|
|
Here are some examples of the possible string formats:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
0x00001042
|
|
|
|
|
0x00001042 <symbol+16>
|
|
|
|
|
0x00001042 <symbol+16 at file.c:123>
|
|
|
|
|
@end smallexample
|
|
|
|
|
@end defun
|
|
|
|
|
|
2022-05-24 10:15:17 -06:00
|
|
|
@defun gdb.current_language ()
|
|
|
|
|
Return the name of the current language as a string. Unlike
|
|
|
|
|
@code{gdb.parameter('language')}, this function will never return
|
|
|
|
|
@samp{auto}. If a @code{gdb.Frame} object is available (@pxref{Frames
|
|
|
|
|
In Python}), the @code{language} method might be preferable in some
|
|
|
|
|
cases, as that is not affected by the user's language setting.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-07-04 09:15:54 -06:00
|
|
|
@node Threading in GDB
|
|
|
|
|
@subsubsection Threading in GDB
|
|
|
|
|
|
|
|
|
|
@value{GDBN} is not thread-safe. If your Python program uses multiple
|
|
|
|
|
threads, you must be careful to only call @value{GDBN}-specific
|
|
|
|
|
functions in the @value{GDBN} thread. @value{GDBN} provides some
|
|
|
|
|
functions to help with this.
|
|
|
|
|
|
2025-04-24 07:36:19 -06:00
|
|
|
@defun gdb.blocked_signals ()
|
2023-07-04 09:15:54 -06:00
|
|
|
As mentioned earlier (@pxref{Basic Python}), certain signals must be
|
2025-04-24 07:36:19 -06:00
|
|
|
delivered to the @value{GDBN} main thread. The @code{blocked_signals}
|
2023-07-04 09:15:54 -06:00
|
|
|
function returns a context manager that will block these signals on
|
|
|
|
|
entry. This can be used when starting a new thread to ensure that the
|
|
|
|
|
signals are blocked there, like:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
2025-04-24 07:36:19 -06:00
|
|
|
with gdb.blocked_signals():
|
2023-07-04 09:15:54 -06:00
|
|
|
start_new_thread()
|
|
|
|
|
@end smallexample
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@deftp {class} gdb.Thread
|
|
|
|
|
This is a subclass of Python's @code{threading.Thread} class. It
|
2025-04-24 07:36:19 -06:00
|
|
|
overrides the @code{start} method to call @code{blocked_signals}, making
|
2023-07-04 09:15:54 -06:00
|
|
|
this an easy-to-use drop-in replacement for creating threads that will
|
|
|
|
|
work well in @value{GDBN}.
|
|
|
|
|
@end deftp
|
|
|
|
|
|
2023-11-16 10:44:42 -07:00
|
|
|
@defun gdb.interrupt ()
|
|
|
|
|
This causes @value{GDBN} to react as if the user had typed a control-C
|
|
|
|
|
character at the terminal. That is, if the inferior is running, it is
|
|
|
|
|
interrupted; if a @value{GDBN} command is executing, it is stopped;
|
|
|
|
|
and if a Python command is running, @code{KeyboardInterrupt} will be
|
|
|
|
|
raised.
|
|
|
|
|
|
|
|
|
|
Unlike most Python APIs in @value{GDBN}, @code{interrupt} is
|
|
|
|
|
thread-safe.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-07-04 09:15:54 -06:00
|
|
|
@defun gdb.post_event (event)
|
|
|
|
|
Put @var{event}, a callable object taking no arguments, into
|
|
|
|
|
@value{GDBN}'s internal event queue. This callable will be invoked at
|
|
|
|
|
some later point, during @value{GDBN}'s event processing. Events
|
|
|
|
|
posted using @code{post_event} will be run in the order in which they
|
|
|
|
|
were posted; however, there is no way to know when they will be
|
|
|
|
|
processed relative to other events inside @value{GDBN}.
|
|
|
|
|
|
|
|
|
|
Unlike most Python APIs in @value{GDBN}, @code{post_event} is
|
|
|
|
|
thread-safe. For example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(@value{GDBP}) python
|
|
|
|
|
>import threading
|
|
|
|
|
>
|
|
|
|
|
>class Writer():
|
|
|
|
|
> def __init__(self, message):
|
|
|
|
|
> self.message = message;
|
|
|
|
|
> def __call__(self):
|
|
|
|
|
> gdb.write(self.message)
|
|
|
|
|
>
|
|
|
|
|
>class MyThread1 (threading.Thread):
|
|
|
|
|
> def run (self):
|
|
|
|
|
> gdb.post_event(Writer("Hello "))
|
|
|
|
|
>
|
|
|
|
|
>class MyThread2 (threading.Thread):
|
|
|
|
|
> def run (self):
|
|
|
|
|
> gdb.post_event(Writer("World\n"))
|
|
|
|
|
>
|
|
|
|
|
>MyThread1().start()
|
|
|
|
|
>MyThread2().start()
|
|
|
|
|
>end
|
|
|
|
|
(@value{GDBP}) Hello World
|
|
|
|
|
@end smallexample
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Exception Handling
|
|
|
|
|
@subsubsection Exception Handling
|
|
|
|
|
@cindex python exceptions
|
|
|
|
|
@cindex exceptions, python
|
|
|
|
|
|
|
|
|
|
When executing the @code{python} command, Python exceptions
|
|
|
|
|
uncaught within the Python code are translated to calls to
|
|
|
|
|
@value{GDBN} error-reporting mechanism. If the command that called
|
|
|
|
|
@code{python} does not handle the error, @value{GDBN} will
|
2024-02-15 13:14:43 -07:00
|
|
|
terminate it and print an error message. Exactly what will be printed
|
|
|
|
|
depends on @code{set python print-stack} (@pxref{Python Commands}).
|
|
|
|
|
Example:
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(@value{GDBP}) python print foo
|
|
|
|
|
Traceback (most recent call last):
|
|
|
|
|
File "<string>", line 1, in <module>
|
|
|
|
|
NameError: name 'foo' is not defined
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@value{GDBN} errors that happen in @value{GDBN} commands invoked by
|
|
|
|
|
Python code are converted to Python exceptions. The type of the
|
|
|
|
|
Python exception depends on the error.
|
|
|
|
|
|
|
|
|
|
@ftable @code
|
|
|
|
|
@item gdb.error
|
|
|
|
|
This is the base class for most exceptions generated by @value{GDBN}.
|
|
|
|
|
It is derived from @code{RuntimeError}, for compatibility with earlier
|
|
|
|
|
versions of @value{GDBN}.
|
|
|
|
|
|
|
|
|
|
If an error occurring in @value{GDBN} does not fit into some more
|
|
|
|
|
specific category, then the generated exception will have this type.
|
|
|
|
|
|
|
|
|
|
@item gdb.MemoryError
|
|
|
|
|
This is a subclass of @code{gdb.error} which is thrown when an
|
|
|
|
|
operation tried to access invalid memory in the inferior.
|
|
|
|
|
|
|
|
|
|
@item KeyboardInterrupt
|
|
|
|
|
User interrupt (via @kbd{C-c} or by typing @kbd{q} at a pagination
|
|
|
|
|
prompt) is translated to a Python @code{KeyboardInterrupt} exception.
|
|
|
|
|
@end ftable
|
|
|
|
|
|
|
|
|
|
In all cases, your exception handler will see the @value{GDBN} error
|
|
|
|
|
message as its value and the Python call stack backtrace at the Python
|
2023-06-03 22:43:57 +02:00
|
|
|
statement closest to where the @value{GDBN} error occurred as the
|
2014-02-17 10:35:03 -08:00
|
|
|
traceback.
|
|
|
|
|
|
2018-09-08 09:39:41 -06:00
|
|
|
|
|
|
|
|
When implementing @value{GDBN} commands in Python via
|
|
|
|
|
@code{gdb.Command}, or functions via @code{gdb.Function}, it is useful
|
|
|
|
|
to be able to throw an exception that doesn't cause a traceback to be
|
|
|
|
|
printed. For example, the user may have invoked the command
|
|
|
|
|
incorrectly. @value{GDBN} provides a special exception class that can
|
|
|
|
|
be used for this purpose.
|
|
|
|
|
|
|
|
|
|
@ftable @code
|
|
|
|
|
@item gdb.GdbError
|
|
|
|
|
When thrown from a command or function, this exception will cause the
|
|
|
|
|
command or function to fail, but the Python stack will not be
|
|
|
|
|
displayed. @value{GDBN} does not throw this exception itself, but
|
|
|
|
|
rather recognizes it when thrown from user Python code. Example:
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(gdb) python
|
|
|
|
|
>class HelloWorld (gdb.Command):
|
|
|
|
|
> """Greet the whole world."""
|
|
|
|
|
> def __init__ (self):
|
|
|
|
|
> super (HelloWorld, self).__init__ ("hello-world", gdb.COMMAND_USER)
|
|
|
|
|
> def invoke (self, args, from_tty):
|
|
|
|
|
> argv = gdb.string_to_argv (args)
|
|
|
|
|
> if len (argv) != 0:
|
|
|
|
|
> raise gdb.GdbError ("hello-world takes no arguments")
|
2021-01-25 10:28:53 -05:00
|
|
|
> print ("Hello, World!")
|
2014-02-17 10:35:03 -08:00
|
|
|
>HelloWorld ()
|
|
|
|
|
>end
|
|
|
|
|
(gdb) hello-world 42
|
|
|
|
|
hello-world takes no arguments
|
|
|
|
|
@end smallexample
|
2018-09-08 09:39:41 -06:00
|
|
|
@end ftable
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@node Values From Inferior
|
|
|
|
|
@subsubsection Values From Inferior
|
|
|
|
|
@cindex values from inferior, with Python
|
|
|
|
|
@cindex python, working with values from inferior
|
|
|
|
|
|
|
|
|
|
@cindex @code{gdb.Value}
|
|
|
|
|
@value{GDBN} provides values it obtains from the inferior program in
|
|
|
|
|
an object of type @code{gdb.Value}. @value{GDBN} uses this object
|
|
|
|
|
for its internal bookkeeping of the inferior's values, and for
|
|
|
|
|
fetching values when necessary.
|
|
|
|
|
|
|
|
|
|
Inferior values that are simple scalars can be used directly in
|
|
|
|
|
Python expressions that are valid for the value's data type. Here's
|
|
|
|
|
an example for an integer or floating-point value @code{some_val}:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
bar = some_val + 2
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
As result of this, @code{bar} will also be a @code{gdb.Value} object
|
2013-12-02 06:45:09 -08:00
|
|
|
whose values are of the same type as those of @code{some_val}. Valid
|
|
|
|
|
Python operations can also be performed on @code{gdb.Value} objects
|
|
|
|
|
representing a @code{struct} or @code{class} object. For such cases,
|
|
|
|
|
the overloaded operator (if present), is used to perform the operation.
|
|
|
|
|
For example, if @code{val1} and @code{val2} are @code{gdb.Value} objects
|
|
|
|
|
representing instances of a @code{class} which overloads the @code{+}
|
|
|
|
|
operator, then one can use the @code{+} operator in their Python script
|
|
|
|
|
as follows:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
val3 = val1 + val2
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
The result of the operation @code{val3} is also a @code{gdb.Value}
|
|
|
|
|
object corresponding to the value returned by the overloaded @code{+}
|
|
|
|
|
operator. In general, overloaded operators are invoked for the
|
|
|
|
|
following operations: @code{+} (binary addition), @code{-} (binary
|
|
|
|
|
subtraction), @code{*} (multiplication), @code{/}, @code{%}, @code{<<},
|
|
|
|
|
@code{>>}, @code{|}, @code{&}, @code{^}.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
Inferior values that are structures or instances of some class can
|
|
|
|
|
be accessed using the Python @dfn{dictionary syntax}. For example, if
|
|
|
|
|
@code{some_val} is a @code{gdb.Value} instance holding a structure, you
|
|
|
|
|
can access its @code{foo} element with:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
bar = some_val['foo']
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@cindex getting structure elements using gdb.Field objects as subscripts
|
|
|
|
|
Again, @code{bar} will also be a @code{gdb.Value} object. Structure
|
|
|
|
|
elements can also be accessed by using @code{gdb.Field} objects as
|
|
|
|
|
subscripts (@pxref{Types In Python}, for more information on
|
|
|
|
|
@code{gdb.Field} objects). For example, if @code{foo_field} is a
|
|
|
|
|
@code{gdb.Field} object corresponding to element @code{foo} of the above
|
|
|
|
|
structure, then @code{bar} can also be accessed as follows:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
bar = some_val[foo_field]
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
2023-07-18 08:38:56 -06:00
|
|
|
If a @code{gdb.Value} has array or pointer type, an integer index can
|
|
|
|
|
be used to access elements.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
result = some_array[23]
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
A @code{gdb.Value} that represents a function can be executed via
|
|
|
|
|
inferior function call. Any arguments provided to the call must match
|
|
|
|
|
the function's prototype, and must be provided in the order specified
|
|
|
|
|
by that prototype.
|
|
|
|
|
|
|
|
|
|
For example, @code{some_val} is a @code{gdb.Value} instance
|
|
|
|
|
representing a function that takes two integers as arguments. To
|
|
|
|
|
execute this function, call it like so:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
result = some_val (10,20)
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Any values returned from a function call will be stored as a
|
|
|
|
|
@code{gdb.Value}.
|
|
|
|
|
|
|
|
|
|
The following attributes are provided:
|
|
|
|
|
|
|
|
|
|
@defvar Value.address
|
|
|
|
|
If this object is addressable, this read-only attribute holds a
|
|
|
|
|
@code{gdb.Value} object representing the address. Otherwise,
|
|
|
|
|
this attribute holds @code{None}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@cindex optimized out value in Python
|
|
|
|
|
@defvar Value.is_optimized_out
|
|
|
|
|
This read-only boolean attribute is true if the compiler optimized out
|
|
|
|
|
this value, thus it is not available for fetching from the inferior.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Value.type
|
|
|
|
|
The type of this @code{gdb.Value}. The value of this attribute is a
|
|
|
|
|
@code{gdb.Type} object (@pxref{Types In Python}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Value.dynamic_type
|
2018-09-08 13:44:24 -06:00
|
|
|
The dynamic type of this @code{gdb.Value}. This uses the object's
|
|
|
|
|
virtual table and the C@t{++} run-time type information
|
|
|
|
|
(@acronym{RTTI}) to determine the dynamic type of the value. If this
|
|
|
|
|
value is of class type, it will return the class in which the value is
|
|
|
|
|
embedded, if any. If this value is of pointer or reference to a class
|
|
|
|
|
type, it will compute the dynamic type of the referenced object, and
|
|
|
|
|
return a pointer or reference to that type, respectively. In all
|
|
|
|
|
other cases, it will return the value's static type.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
Note that this feature will only work when debugging a C@t{++} program
|
|
|
|
|
that includes @acronym{RTTI} for the object in question. Otherwise,
|
|
|
|
|
it will just return the static type of the value as in @kbd{ptype foo}
|
|
|
|
|
(@pxref{Symbols, ptype}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Value.is_lazy
|
|
|
|
|
The value of this read-only boolean attribute is @code{True} if this
|
|
|
|
|
@code{gdb.Value} has not yet been fetched from the inferior.
|
|
|
|
|
@value{GDBN} does not fetch values until necessary, for efficiency.
|
|
|
|
|
For example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
myval = gdb.parse_and_eval ('somevar')
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The value of @code{somevar} is not fetched at this time. It will be
|
|
|
|
|
fetched when the value is needed, or when the @code{fetch_lazy}
|
|
|
|
|
method is invoked.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2023-10-18 15:46:23 +01:00
|
|
|
@defvar Value.bytes
|
|
|
|
|
The value of this attribute is a @code{bytes} object containing the
|
|
|
|
|
bytes that make up this @code{Value}'s complete value in little endian
|
|
|
|
|
order. If the complete contents of this value are not available then
|
|
|
|
|
accessing this attribute will raise an exception.
|
|
|
|
|
|
|
|
|
|
This attribute can also be assigned to. The new value should be a
|
|
|
|
|
buffer object (e.g.@: a @code{bytes} object), the length of the new
|
|
|
|
|
buffer must exactly match the length of this @code{Value}'s type. The
|
|
|
|
|
bytes values in the new buffer should be in little endian order.
|
|
|
|
|
|
|
|
|
|
As with @code{Value.assign} (@pxref{Value.assign}), if this value
|
|
|
|
|
cannot be assigned to, then an exception will be thrown.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
The following methods are provided:
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Value.__init__ (val)
|
2014-02-17 10:35:03 -08:00
|
|
|
Many Python values can be converted directly to a @code{gdb.Value} via
|
|
|
|
|
this object initializer. Specifically:
|
|
|
|
|
|
|
|
|
|
@table @asis
|
|
|
|
|
@item Python boolean
|
|
|
|
|
A Python boolean is converted to the boolean type from the current
|
|
|
|
|
language.
|
|
|
|
|
|
|
|
|
|
@item Python integer
|
|
|
|
|
A Python integer is converted to the C @code{long} type for the
|
|
|
|
|
current architecture.
|
|
|
|
|
|
|
|
|
|
@item Python long
|
|
|
|
|
A Python long is converted to the C @code{long long} type for the
|
|
|
|
|
current architecture.
|
|
|
|
|
|
|
|
|
|
@item Python float
|
|
|
|
|
A Python float is converted to the C @code{double} type for the
|
|
|
|
|
current architecture.
|
|
|
|
|
|
|
|
|
|
@item Python string
|
2014-05-17 09:13:00 -07:00
|
|
|
A Python string is converted to a target string in the current target
|
|
|
|
|
language using the current target encoding.
|
|
|
|
|
If a character cannot be represented in the current target encoding,
|
|
|
|
|
then an exception is thrown.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@item @code{gdb.Value}
|
|
|
|
|
If @code{val} is a @code{gdb.Value}, then a copy of the value is made.
|
|
|
|
|
|
|
|
|
|
@item @code{gdb.LazyString}
|
|
|
|
|
If @code{val} is a @code{gdb.LazyString} (@pxref{Lazy Strings In
|
|
|
|
|
Python}), then the lazy string's @code{value} method is called, and
|
|
|
|
|
its result is used.
|
|
|
|
|
@end table
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Value.__init__ (val, type)
|
2019-02-16 18:31:51 -07:00
|
|
|
This second form of the @code{gdb.Value} constructor returns a
|
|
|
|
|
@code{gdb.Value} of type @var{type} where the value contents are taken
|
|
|
|
|
from the Python buffer object specified by @var{val}. The number of
|
|
|
|
|
bytes in the Python buffer object must be greater than or equal to the
|
|
|
|
|
size of @var{type}.
|
gdb/python: Use tp_init instead of tp_new to setup gdb.Value
The documentation suggests that we implement gdb.Value.__init__,
however, this is not currently true, we really implement
gdb.Value.__new__. This will cause confusion if a user tries to
sub-class gdb.Value. They might write:
class MyVal (gdb.Value):
def __init__ (self, val):
gdb.Value.__init__(self, val)
obj = MyVal(123)
print ("Got: %s" % obj)
But, when they source this code they'll see:
(gdb) source ~/tmp/value-test.py
Traceback (most recent call last):
File "/home/andrew/tmp/value-test.py", line 7, in <module>
obj = MyVal(123)
File "/home/andrew/tmp/value-test.py", line 5, in __init__
gdb.Value.__init__(self, val)
TypeError: object.__init__() takes exactly one argument (the instance to initialize)
(gdb)
The reason for this is that, as we don't implement __init__ for
gdb.Value, Python ends up calling object.__init__ instead, which
doesn't expect any arguments.
The Python docs suggest that the reason why we might take this
approach is because we want gdb.Value to be immutable:
https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_new
But I don't see any reason why we should require gdb.Value to be
immutable when other types defined in GDB are not. This current
immutability can be seen in this code:
obj = gdb.Value(1234)
print("Got: %s" % obj)
obj.__init__ (5678)
print("Got: %s" % obj)
Which currently runs without error, but prints:
Got: 1234
Got: 1234
In this commit I propose that we switch to using __init__ to
initialize gdb.Value objects.
This does introduce some additional complexity, during the __init__
call a gdb.Value might already be associated with a gdb value object,
in which case we need to cleanly break that association before
installing the new gdb value object. However, the cost of doing this
is not great, and the benefit - being able to easily sub-class
gdb.Value seems worth it.
After this commit the first example above works without error, while
the second example now prints:
Got: 1234
Got: 5678
In order to make it easier to override the gdb.Value.__init__ method,
I have tweaked the definition of gdb.Value.__init__. The second,
optional argument to __init__ is a gdb.Type, if this argument is not
present then GDB figures out a suitable type.
However, if we want to override the __init__ method in a sub-class,
and still support the default argument, it is easier to write:
class MyVal (gdb.Value):
def __init__ (self, val, type=None):
gdb.Value.__init__(self, val, type)
Currently, passing None for the Type will result in an error:
TypeError: type argument must be a gdb.Type.
After this commit I now allow the type argument to be None, in which
case GDB figures out a suitable type just as if the type had not been
passed at all.
Unless a user is trying to reinitialize a value, or create sub-classes
of gdb.Value, there should be no user visible changes after this
commit.
2021-11-17 11:55:37 +00:00
|
|
|
|
|
|
|
|
If @var{type} is @code{None} then this version of @code{__init__}
|
|
|
|
|
behaves as though @var{type} was not passed at all.
|
2019-02-16 18:31:51 -07:00
|
|
|
@end defun
|
|
|
|
|
|
2023-10-18 15:46:23 +01:00
|
|
|
@anchor{Value.assign}
|
2023-05-12 14:10:56 -06:00
|
|
|
@defun Value.assign (rhs)
|
|
|
|
|
Assign @var{rhs} to this value, and return @code{None}. If this value
|
|
|
|
|
cannot be assigned to, or if the assignment is invalid for some reason
|
|
|
|
|
(for example a type-checking failure), an exception will be thrown.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun Value.cast (type)
|
|
|
|
|
Return a new instance of @code{gdb.Value} that is the result of
|
|
|
|
|
casting this instance to the type described by @var{type}, which must
|
|
|
|
|
be a @code{gdb.Type} object. If the cast cannot be performed for some
|
|
|
|
|
reason, this method throws an exception.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Value.dereference ()
|
|
|
|
|
For pointer data types, this method returns a new @code{gdb.Value} object
|
|
|
|
|
whose contents is the object pointed to by the pointer. For example, if
|
|
|
|
|
@code{foo} is a C pointer to an @code{int}, declared in your C program as
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
int *foo;
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
then you can use the corresponding @code{gdb.Value} to access what
|
|
|
|
|
@code{foo} points to like this:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
bar = foo.dereference ()
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The result @code{bar} will be a @code{gdb.Value} object holding the
|
|
|
|
|
value pointed to by @code{foo}.
|
|
|
|
|
|
|
|
|
|
A similar function @code{Value.referenced_value} exists which also
|
2019-10-07 09:51:18 +02:00
|
|
|
returns @code{gdb.Value} objects corresponding to the values pointed to
|
2014-02-17 10:35:03 -08:00
|
|
|
by pointer values (and additionally, values referenced by reference
|
|
|
|
|
values). However, the behavior of @code{Value.dereference}
|
|
|
|
|
differs from @code{Value.referenced_value} by the fact that the
|
|
|
|
|
behavior of @code{Value.dereference} is identical to applying the C
|
|
|
|
|
unary operator @code{*} on a given value. For example, consider a
|
|
|
|
|
reference to a pointer @code{ptrref}, declared in your C@t{++} program
|
|
|
|
|
as
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
typedef int *intptr;
|
|
|
|
|
...
|
|
|
|
|
int val = 10;
|
|
|
|
|
intptr ptr = &val;
|
|
|
|
|
intptr &ptrref = ptr;
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Though @code{ptrref} is a reference value, one can apply the method
|
|
|
|
|
@code{Value.dereference} to the @code{gdb.Value} object corresponding
|
|
|
|
|
to it and obtain a @code{gdb.Value} which is identical to that
|
|
|
|
|
corresponding to @code{val}. However, if you apply the method
|
|
|
|
|
@code{Value.referenced_value}, the result would be a @code{gdb.Value}
|
|
|
|
|
object identical to that corresponding to @code{ptr}.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
py_ptrref = gdb.parse_and_eval ("ptrref")
|
|
|
|
|
py_val = py_ptrref.dereference ()
|
|
|
|
|
py_ptr = py_ptrref.referenced_value ()
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The @code{gdb.Value} object @code{py_val} is identical to that
|
|
|
|
|
corresponding to @code{val}, and @code{py_ptr} is identical to that
|
|
|
|
|
corresponding to @code{ptr}. In general, @code{Value.dereference} can
|
|
|
|
|
be applied whenever the C unary operator @code{*} can be applied
|
|
|
|
|
to the corresponding C value. For those cases where applying both
|
|
|
|
|
@code{Value.dereference} and @code{Value.referenced_value} is allowed,
|
|
|
|
|
the results obtained need not be identical (as we have seen in the above
|
|
|
|
|
example). The results are however identical when applied on
|
|
|
|
|
@code{gdb.Value} objects corresponding to pointers (@code{gdb.Value}
|
|
|
|
|
objects with type code @code{TYPE_CODE_PTR}) in a C/C@t{++} program.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Value.referenced_value ()
|
|
|
|
|
For pointer or reference data types, this method returns a new
|
|
|
|
|
@code{gdb.Value} object corresponding to the value referenced by the
|
|
|
|
|
pointer/reference value. For pointer data types,
|
|
|
|
|
@code{Value.dereference} and @code{Value.referenced_value} produce
|
|
|
|
|
identical results. The difference between these methods is that
|
|
|
|
|
@code{Value.dereference} cannot get the values referenced by reference
|
|
|
|
|
values. For example, consider a reference to an @code{int}, declared
|
|
|
|
|
in your C@t{++} program as
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
int val = 10;
|
|
|
|
|
int &ref = val;
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
then applying @code{Value.dereference} to the @code{gdb.Value} object
|
|
|
|
|
corresponding to @code{ref} will result in an error, while applying
|
|
|
|
|
@code{Value.referenced_value} will result in a @code{gdb.Value} object
|
|
|
|
|
identical to that corresponding to @code{val}.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
py_ref = gdb.parse_and_eval ("ref")
|
|
|
|
|
er_ref = py_ref.dereference () # Results in error
|
|
|
|
|
py_val = py_ref.referenced_value () # Returns the referenced value
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The @code{gdb.Value} object @code{py_val} is identical to that
|
|
|
|
|
corresponding to @code{val}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2015-04-25 07:04:40 -07:00
|
|
|
@defun Value.reference_value ()
|
|
|
|
|
Return a @code{gdb.Value} object which is a reference to the value
|
|
|
|
|
encapsulated by this instance.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Value.const_value ()
|
|
|
|
|
Return a @code{gdb.Value} object which is a @code{const} version of the
|
|
|
|
|
value encapsulated by this instance.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun Value.dynamic_cast (type)
|
|
|
|
|
Like @code{Value.cast}, but works as if the C@t{++} @code{dynamic_cast}
|
|
|
|
|
operator were used. Consult a C@t{++} reference for details.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Value.reinterpret_cast (type)
|
|
|
|
|
Like @code{Value.cast}, but works as if the C@t{++} @code{reinterpret_cast}
|
|
|
|
|
operator were used. Consult a C@t{++} reference for details.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2019-04-01 09:59:53 +02:00
|
|
|
@defun Value.format_string (...)
|
|
|
|
|
Convert a @code{gdb.Value} to a string, similarly to what the @code{print}
|
|
|
|
|
command does. Invoked with no arguments, this is equivalent to calling
|
|
|
|
|
the @code{str} function on the @code{gdb.Value}. The representation of
|
|
|
|
|
the same value may change across different versions of @value{GDBN}, so
|
|
|
|
|
you shouldn't, for instance, parse the strings returned by this method.
|
|
|
|
|
|
|
|
|
|
All the arguments are keyword only. If an argument is not specified, the
|
|
|
|
|
current global default setting is used.
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@item raw
|
|
|
|
|
@code{True} if pretty-printers (@pxref{Pretty Printing}) should not be
|
|
|
|
|
used to format the value. @code{False} if enabled pretty-printers
|
|
|
|
|
matching the type represented by the @code{gdb.Value} should be used to
|
|
|
|
|
format it.
|
|
|
|
|
|
|
|
|
|
@item pretty_arrays
|
|
|
|
|
@code{True} if arrays should be pretty printed to be more convenient to
|
|
|
|
|
read, @code{False} if they shouldn't (see @code{set print array} in
|
|
|
|
|
@ref{Print Settings}).
|
|
|
|
|
|
|
|
|
|
@item pretty_structs
|
|
|
|
|
@code{True} if structs should be pretty printed to be more convenient to
|
|
|
|
|
read, @code{False} if they shouldn't (see @code{set print pretty} in
|
|
|
|
|
@ref{Print Settings}).
|
|
|
|
|
|
|
|
|
|
@item array_indexes
|
|
|
|
|
@code{True} if array indexes should be included in the string
|
|
|
|
|
representation of arrays, @code{False} if they shouldn't (see @code{set
|
|
|
|
|
print array-indexes} in @ref{Print Settings}).
|
|
|
|
|
|
|
|
|
|
@item symbols
|
|
|
|
|
@code{True} if the string representation of a pointer should include the
|
|
|
|
|
corresponding symbol name (if one exists), @code{False} if it shouldn't
|
|
|
|
|
(see @code{set print symbol} in @ref{Print Settings}).
|
|
|
|
|
|
|
|
|
|
@item unions
|
|
|
|
|
@code{True} if unions which are contained in other structures or unions
|
|
|
|
|
should be expanded, @code{False} if they shouldn't (see @code{set print
|
|
|
|
|
union} in @ref{Print Settings}).
|
|
|
|
|
|
2020-12-18 17:23:06 +01:00
|
|
|
@item address
|
|
|
|
|
@code{True} if the string representation of a pointer should include the
|
|
|
|
|
address, @code{False} if it shouldn't (see @code{set print address} in
|
|
|
|
|
@ref{Print Settings}).
|
|
|
|
|
|
2022-06-12 13:25:31 +08:00
|
|
|
@item nibbles
|
|
|
|
|
@code{True} if binary values should be displayed in groups of four bits,
|
|
|
|
|
known as nibbles. @code{False} if it shouldn't (@pxref{Print Settings,
|
|
|
|
|
set print nibbles}).
|
|
|
|
|
|
2019-04-01 09:59:53 +02:00
|
|
|
@item deref_refs
|
|
|
|
|
@code{True} if C@t{++} references should be resolved to the value they
|
|
|
|
|
refer to, @code{False} (the default) if they shouldn't. Note that, unlike
|
|
|
|
|
for the @code{print} command, references are not automatically expanded
|
|
|
|
|
when using the @code{format_string} method or the @code{str}
|
|
|
|
|
function. There is no global @code{print} setting to change the default
|
2024-11-23 12:20:34 +01:00
|
|
|
behavior.
|
2019-04-01 09:59:53 +02:00
|
|
|
|
|
|
|
|
@item actual_objects
|
|
|
|
|
@code{True} if the representation of a pointer to an object should
|
|
|
|
|
identify the @emph{actual} (derived) type of the object rather than the
|
|
|
|
|
@emph{declared} type, using the virtual function table. @code{False} if
|
|
|
|
|
the @emph{declared} type should be used. (See @code{set print object} in
|
|
|
|
|
@ref{Print Settings}).
|
|
|
|
|
|
2020-11-24 19:43:19 +01:00
|
|
|
@item static_members
|
2019-04-01 09:59:53 +02:00
|
|
|
@code{True} if static members should be included in the string
|
|
|
|
|
representation of a C@t{++} object, @code{False} if they shouldn't (see
|
|
|
|
|
@code{set print static-members} in @ref{Print Settings}).
|
|
|
|
|
|
GDB: Add a character string limiting option
This commit splits the `set/show print elements' option into two. We
retain `set/show print elements' for controlling how many elements of an
array we print, but a new `set/show print characters' setting is added
which is used for controlling how many characters of a string are
printed.
The motivation behind this change is to allow users a finer level of
control over how data is printed, reflecting that, although strings can
be thought of as arrays of characters, users often want to treat these
two things differently.
For compatibility reasons by default the `set/show print characters'
option is set to `elements', which makes the limit for character strings
follow the setting of the `set/show print elements' option, as it used
to. Using `set print characters' with any other value makes the limit
independent from the `set/show print elements' setting, however it can
be restored to the default with the `set print characters elements'
command at any time.
A corresponding `-characters' option for the `print' command is added,
with the same semantics, i.e. one can use `elements' to make a given
`print' invocation follow the limit of elements, be it set with the
`-elements' option also given with the same invocation or taken from the
`set/show print elements' setting, for characters as well regardless of
the current setting of the `set/show print characters' option.
The GDB changes are all pretty straightforward, just changing references
to the old 'print_max' to use a new `get_print_max_chars' helper which
figures out which of the two of `print_max' and `print_max_chars' values
to use.
Likewise, the documentation is just updated to reference the new setting
where appropriate.
To make people's life easier the message shown by `show print elements'
now indicates if the setting also applies to character strings:
(gdb) set print characters elements
(gdb) show print elements
Limit on string chars or array elements to print is 200.
(gdb) set print characters unlimited
(gdb) show print elements
Limit on array elements to print is 200.
(gdb)
and the help text shows the dependency as well:
(gdb) help set print elements
Set limit on array elements to print.
"unlimited" causes there to be no limit.
This setting also applies to string chars when "print characters"
is set to "elements".
(gdb)
In the testsuite there are two minor updates, one to add `-characters'
to the list of completions now shown for the `print' command, and a bare
minimum pair of checks for the right handling of `set print characters'
and `show print characters', copied from the corresponding checks for
`set print elements' and `show print elements' respectively.
Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
|
|
|
@item max_characters
|
|
|
|
|
Number of string characters to print, @code{0} to follow
|
|
|
|
|
@code{max_elements}, or @code{UINT_MAX} to print an unlimited number
|
|
|
|
|
of characters (see @code{set print characters} in @ref{Print Settings}).
|
|
|
|
|
|
2019-04-01 09:59:53 +02:00
|
|
|
@item max_elements
|
|
|
|
|
Number of array elements to print, or @code{0} to print an unlimited
|
|
|
|
|
number of elements (see @code{set print elements} in @ref{Print
|
|
|
|
|
Settings}).
|
|
|
|
|
|
gdb: Introduce 'print max-depth' feature
Introduce a new print setting max-depth which can be set with 'set
print max-depth DEPTH'. The default value of DEPTH is 20, but this
can also be set to unlimited.
When GDB is printing a value containing nested structures GDB will
stop descending at depth DEPTH. Here is a small example:
typedef struct s1 { int a; } s1;
typedef struct s2 { s1 b; } s2;
typedef struct s3 { s2 c; } s3;
typedef struct s4 { s3 d; } s4;
s4 var = { { { { 3 } } } };
The following table shows how various depth settings affect printing
of 'var':
| Depth Setting | Result of 'p var' |
|---------------+--------------------------------|
| Unlimited | $1 = {d = {c = {b = {a = 3}}}} |
| 4 | $1 = {d = {c = {b = {a = 3}}}} |
| 3 | $1 = {d = {c = {b = {...}}}} |
| 2 | $1 = {d = {c = {...}}} |
| 1 | $1 = {d = {...}} |
| 0 | $1 = {...} |
Only structures, unions, and arrays are replaced in this way, scalars
and strings are not replaced.
The replacement is counted from the level at which you print, not from
the top level of the structure. So, consider the above example and
this GDB session:
(gdb) set print max-depth 2
(gdb) p var
$1 = {d = {c = {...}}}
(gdb) p var.d
$2 = {c = {b = {...}}}
(gdb) p var.d.c
$3 = {b = {a = 3}}
Setting the max-depth to 2 doesn't prevent the user from exploring
deeper into 'var' by asking for specific sub-fields to be printed.
The motivation behind this feature is to try and give the user more
control over how much is printed when examining large, complex data
structures.
The default max-depth of 20 means that there is a change in GDB's
default behaviour. Someone printing a data structure with 20 levels
of nesting will now see '{...}' instead of their data, they would need
to adjust the max depth, or call print again naming a specific field
in order to dig deeper into their data structure. If this is
considered a problem then we could increase the default, or even make
the default unlimited.
This commit relies on the previous commit, which added a new field to
the language structure, this new field was a string that contained the
pattern that should be used when a structure/union/array is replaced
in the output, this allows languages to use a syntax that is more
appropriate, mostly this will be selecting the correct types of
bracket '(...)' or '{...}', both of which are currently in use.
This commit should have no impact on MI output, expressions are
printed through the MI using -var-create and then -var-list-children.
As each use of -var-list-children only ever displays a single level of
an expression then the max-depth setting will have no impact.
This commit also adds the max-depth mechanism to the scripting
language pretty printers following basically the same rules as for the
built in value printing.
One quirk is that when printing a value using the display hint 'map',
if the keys of the map are structs then GDB will hide the keys one
depth level after it hides the values, this ensures that GDB produces
output like this:
$1 = map_object = {[{key1}] = {...}, [{key2}] = {...}}
Instead of this less helpful output:
$1 = map_object = {[{...}] = {...}, [{...}] = {...}}
This is covered by the new tests in gdb.python/py-nested-maps.exp.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value_fields): Allow an additional level
of depth when printing anonymous structs or unions.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer):
Don't print either the top-level value, or the children if the
max-depth is exceeded.
(ppscm_print_children): When printing the key of a map, allow one
extra level of depth.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't
print either the top-level value, or the children if the max-depth
is exceeded.
(print_children): When printing the key of a map, allow one extra
level of depth.
* python/py-value.c (valpy_format_string): Add max_depth keyword.
* valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define.
(user_print_options): Initialise max_depth field.
(val_print_scalar_or_string_type_p): New function.
(val_print): Check to see if the max depth has been reached.
(val_print_check_max_depth): Define new function.
(show_print_max_depth): New function.
(_initialize_valprint): Add 'print max-depth' option.
* valprint.h (struct value_print_options) <max_depth>: New field.
(val_print_check_max_depth): Declare new function.
* NEWS: Document new feature.
gdb/doc/ChangeLog:
* gdb.texinfo (Print Settings): Document 'print max-depth'.
* guile.texi (Guile Pretty Printing API): Document that 'print
max-depth' can effect the display of a values children.
* python.texi (Pretty Printing API): Likewise.
(Values From Inferior): Document max_depth keyword.
gdb/testsuite/ChangeLog:
* gdb.base/max-depth.c: New file.
* gdb.base/max-depth.exp: New file.
* gdb.python/py-nested-maps.c: New file.
* gdb.python/py-nested-maps.exp: New file.
* gdb.python/py-nested-maps.py: New file.
* gdb.python/py-format-string.exp (test_max_depth): New proc.
(test_all_common): Call test_max_depth.
* gdb.fortran/max-depth.exp: New file.
* gdb.fortran/max-depth.f90: New file.
* gdb.go/max-depth.exp: New file.
* gdb.go/max-depth.go: New file.
* gdb.modula2/max-depth.exp: New file.
* gdb.modula2/max-depth.c: New file.
* lib/gdb.exp (get_print_expr_at_depths): New proc.
2019-03-21 15:13:23 +00:00
|
|
|
@item max_depth
|
|
|
|
|
The maximum depth to print for nested structs and unions, or @code{-1}
|
|
|
|
|
to print an unlimited number of elements (see @code{set print
|
|
|
|
|
max-depth} in @ref{Print Settings}).
|
|
|
|
|
|
2019-04-01 09:59:53 +02:00
|
|
|
@item repeat_threshold
|
|
|
|
|
Set the threshold for suppressing display of repeated array elements, or
|
|
|
|
|
@code{0} to represent all elements, even if repeated. (See @code{set
|
|
|
|
|
print repeats} in @ref{Print Settings}).
|
|
|
|
|
|
|
|
|
|
@item format
|
|
|
|
|
A string containing a single character representing the format to use for
|
|
|
|
|
the returned string. For instance, @code{'x'} is equivalent to using the
|
|
|
|
|
@value{GDBN} command @code{print} with the @code{/x} option and formats
|
|
|
|
|
the value as a hexadecimal number.
|
2022-01-24 15:29:49 +00:00
|
|
|
|
|
|
|
|
@item styling
|
|
|
|
|
@code{True} if @value{GDBN} should apply styling to the returned
|
|
|
|
|
string. When styling is applied, the returned string might contain
|
|
|
|
|
ANSI terminal escape sequences. Escape sequences will only be
|
|
|
|
|
included if styling is turned on, see @ref{Output Styling}.
|
|
|
|
|
Additionally, @value{GDBN} only styles some value contents, so not
|
|
|
|
|
every output string will contain escape sequences.
|
|
|
|
|
|
|
|
|
|
When @code{False}, which is the default, no output styling is applied.
|
2022-06-07 07:05:02 -06:00
|
|
|
|
|
|
|
|
@item summary
|
|
|
|
|
@code{True} when just a summary should be printed. In this mode,
|
|
|
|
|
scalar values are printed in their entirety, but aggregates such as
|
|
|
|
|
structures or unions are omitted. This mode is used by @code{set
|
|
|
|
|
print frame-arguments scalars} (@pxref{Print Settings}).
|
2019-04-01 09:59:53 +02:00
|
|
|
@end table
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-07-24 07:29:46 -06:00
|
|
|
@defun Value.to_array ()
|
|
|
|
|
If this value is array-like (@pxref{Type.is_array_like}), then this
|
|
|
|
|
method converts it to an array, which is returned. If this value is
|
|
|
|
|
already an array, it is simply returned. Otherwise, an exception is
|
|
|
|
|
throw.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun Value.string (@r{[}encoding@r{[}, errors@r{[}, length@r{]]]})
|
|
|
|
|
If this @code{gdb.Value} represents a string, then this method
|
|
|
|
|
converts the contents to a Python string. Otherwise, this method will
|
|
|
|
|
throw an exception.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
Values are interpreted as strings according to the rules of the
|
|
|
|
|
current language. If the optional length argument is given, the
|
|
|
|
|
string will be converted to that length, and will include any embedded
|
|
|
|
|
zeroes that the string may contain. Otherwise, for languages
|
|
|
|
|
where the string is zero-terminated, the entire string will be
|
|
|
|
|
converted.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
For example, in C-like languages, a value is a string if it is a pointer
|
|
|
|
|
to or an array of characters or ints of type @code{wchar_t}, @code{char16_t},
|
|
|
|
|
or @code{char32_t}.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
If the optional @var{encoding} argument is given, it must be a string
|
|
|
|
|
naming the encoding of the string in the @code{gdb.Value}, such as
|
|
|
|
|
@code{"ascii"}, @code{"iso-8859-6"} or @code{"utf-8"}. It accepts
|
|
|
|
|
the same encodings as the corresponding argument to Python's
|
|
|
|
|
@code{string.decode} method, and the Python codec machinery will be used
|
|
|
|
|
to convert the string. If @var{encoding} is not given, or if
|
|
|
|
|
@var{encoding} is the empty string, then either the @code{target-charset}
|
|
|
|
|
(@pxref{Character Sets}) will be used, or a language-specific encoding
|
|
|
|
|
will be used, if the current language is able to supply one.
|
|
|
|
|
|
|
|
|
|
The optional @var{errors} argument is the same as the corresponding
|
|
|
|
|
argument to Python's @code{string.decode} method.
|
|
|
|
|
|
|
|
|
|
If the optional @var{length} argument is given, the string will be
|
|
|
|
|
fetched and converted to the given length.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Value.lazy_string (@r{[}encoding @r{[}, length@r{]]})
|
2024-11-15 08:02:25 -07:00
|
|
|
This method attempts to convert this @code{gdb.Value} to a
|
|
|
|
|
@code{gdb.LazyString} (@pxref{Lazy Strings In Python}). Values of
|
|
|
|
|
array or pointer type can be converted; for other types, this method
|
|
|
|
|
will throw an exception.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
If the optional @var{encoding} argument is given, it must be a string
|
|
|
|
|
naming the encoding of the @code{gdb.LazyString}. Some examples are:
|
|
|
|
|
@samp{ascii}, @samp{iso-8859-6} or @samp{utf-8}. If the
|
|
|
|
|
@var{encoding} argument is an encoding that @value{GDBN} does
|
|
|
|
|
recognize, @value{GDBN} will raise an error.
|
|
|
|
|
|
|
|
|
|
When a lazy string is printed, the @value{GDBN} encoding machinery is
|
|
|
|
|
used to convert the string during printing. If the optional
|
|
|
|
|
@var{encoding} argument is not provided, or is an empty string,
|
|
|
|
|
@value{GDBN} will automatically select the encoding most suitable for
|
|
|
|
|
the string type. For further information on encoding in @value{GDBN}
|
|
|
|
|
please see @ref{Character Sets}.
|
|
|
|
|
|
|
|
|
|
If the optional @var{length} argument is given, the string will be
|
|
|
|
|
fetched and encoded to the length of characters specified. If
|
|
|
|
|
the @var{length} argument is not provided, the string will be fetched
|
|
|
|
|
and encoded until a null of appropriate width is found.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Value.fetch_lazy ()
|
|
|
|
|
If the @code{gdb.Value} object is currently a lazy value
|
|
|
|
|
(@code{gdb.Value.is_lazy} is @code{True}), then the value is
|
|
|
|
|
fetched from the inferior. Any errors that occur in the process
|
|
|
|
|
will produce a Python exception.
|
|
|
|
|
|
|
|
|
|
If the @code{gdb.Value} object is not a lazy value, this method
|
|
|
|
|
has no effect.
|
|
|
|
|
|
|
|
|
|
This method does not return a value.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@node Types In Python
|
|
|
|
|
@subsubsection Types In Python
|
|
|
|
|
@cindex types in Python
|
|
|
|
|
@cindex Python, working with types
|
|
|
|
|
|
|
|
|
|
@tindex gdb.Type
|
|
|
|
|
@value{GDBN} represents types from the inferior using the class
|
|
|
|
|
@code{gdb.Type}.
|
|
|
|
|
|
|
|
|
|
The following type-related functions are available in the @code{gdb}
|
|
|
|
|
module:
|
|
|
|
|
|
|
|
|
|
@defun gdb.lookup_type (name @r{[}, block@r{]})
|
Don't use @var at the beginning of a sentence in GDB documentation.
gdb/doc/guile.texi (Types In Guile, Basic Guile, Frames In Guile)
(Breakpoints In Guile, Guile Printing Module)
(Guile Exception Handling, Values From Inferior In Guile)
(Objfiles In Guile, Breakpoints In Guile, Memory Ports in Guile):
Don't use @var at the beginning of a sentence.
gdb/doc/gdb.texinfo (Frame Filter Management, Trace Files)
(C Operators, Ada Tasks, Calling, Bootstrapping, ARM)
(PowerPC Embedded, Define, Annotations for Running)
(IPA Protocol Commands, Packets, General Query Packets)
(Tracepoint Packets, Notification Packets, Environment)
(Inferiors and Programs, Set Breaks, Set Catchpoints)
(Continuing and Stepping, Signals, Thread-Specific Breakpoints)
(Frames, Backtrace, Selection, Expressions, Registers)
(Trace State Variables, Built-In Func/Proc, Signaling, Files)
(Numbers, GDB/MI Async Records, GDB/MI Data Manipulation)
(Source Annotations, Using JIT Debug Info Readers, Packets)
(Stop Reply Packets, Host I/O Packets)
(Target Description Format): Don't use @var at the beginning of a
sentence.
gdb/doc/python.texi (Basic Python, Types In Python)
(Commands In Python, Frames In Python, Line Tables In Python)
(Breakpoints In Python, gdb.printing, gdb.types)
(Type Printing API): Don't use @var at the beginning of a
sentence.
2014-05-24 13:02:42 +03:00
|
|
|
This function looks up a type by its @var{name}, which must be a string.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
If @var{block} is given, then @var{name} is looked up in that scope.
|
|
|
|
|
Otherwise, it is searched for globally.
|
|
|
|
|
|
|
|
|
|
Ordinarily, this function will return an instance of @code{gdb.Type}.
|
|
|
|
|
If the named type cannot be found, it will throw an exception.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2021-10-22 10:49:19 -06:00
|
|
|
Integer types can be found without looking them up by name.
|
|
|
|
|
@xref{Architectures In Python}, for the @code{integer_type} method.
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
If the type is a structure or class type, or an enum type, the fields
|
|
|
|
|
of that type can be accessed using the Python @dfn{dictionary syntax}.
|
|
|
|
|
For example, if @code{some_type} is a @code{gdb.Type} instance holding
|
|
|
|
|
a structure type, you can access its @code{foo} field with:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
bar = some_type['foo']
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@code{bar} will be a @code{gdb.Field} object; see below under the
|
|
|
|
|
description of the @code{Type.fields} method for a description of the
|
|
|
|
|
@code{gdb.Field} class.
|
|
|
|
|
|
|
|
|
|
An instance of @code{Type} has the following attributes:
|
|
|
|
|
|
2018-04-20 15:43:56 -06:00
|
|
|
@defvar Type.alignof
|
|
|
|
|
The alignment of this type, in bytes. Type alignment comes from the
|
|
|
|
|
debugging information; if it was not specified, then @value{GDBN} will
|
|
|
|
|
use the relevant ABI to try to determine the alignment. In some
|
|
|
|
|
cases, even this is not possible, and zero will be returned.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar Type.code
|
|
|
|
|
The type code for this type. The type code will be one of the
|
|
|
|
|
@code{TYPE_CODE_} constants defined below.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2020-04-24 13:40:31 -06:00
|
|
|
@defvar Type.dynamic
|
|
|
|
|
A boolean indicating whether this type is dynamic. In some
|
|
|
|
|
situations, such as Rust @code{enum} types or Ada variant records, the
|
2020-04-27 08:23:53 -06:00
|
|
|
concrete type of a value may vary depending on its contents. That is,
|
|
|
|
|
the declared type of a variable, or the type returned by
|
|
|
|
|
@code{gdb.lookup_type} may be dynamic; while the type of the
|
|
|
|
|
variable's value will be a concrete instance of that dynamic type.
|
|
|
|
|
|
|
|
|
|
For example, consider this code:
|
|
|
|
|
@smallexample
|
|
|
|
|
int n;
|
|
|
|
|
int array[n];
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Here, at least conceptually (whether your compiler actually does this
|
|
|
|
|
is a separate issue), examining @w{@code{gdb.lookup_symbol("array", ...).type}}
|
|
|
|
|
could yield a @code{gdb.Type} which reports a size of @code{None}.
|
|
|
|
|
This is the dynamic type.
|
|
|
|
|
|
|
|
|
|
However, examining @code{gdb.parse_and_eval("array").type} would yield
|
|
|
|
|
a concrete type, whose length would be known.
|
2020-04-24 13:40:31 -06:00
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar Type.name
|
|
|
|
|
The name of this type. If this type has no name, then @code{None}
|
|
|
|
|
is returned.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Type.sizeof
|
|
|
|
|
The size of this type, in target @code{char} units. Usually, a
|
|
|
|
|
target's @code{char} type will be an 8-bit byte. However, on some
|
2020-04-24 13:40:31 -06:00
|
|
|
unusual platforms, this type may have a different size. A dynamic
|
|
|
|
|
type may not have a fixed size; in this case, this attribute's value
|
|
|
|
|
will be @code{None}.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Type.tag
|
|
|
|
|
The tag name for this type. The tag name is the name after
|
|
|
|
|
@code{struct}, @code{union}, or @code{enum} in C and C@t{++}; not all
|
|
|
|
|
languages have this concept. If this type has no tag name, then
|
|
|
|
|
@code{None} is returned.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2019-05-23 16:37:29 -05:00
|
|
|
@defvar Type.objfile
|
|
|
|
|
The @code{gdb.Objfile} that this type was defined in, or @code{None} if
|
|
|
|
|
there is no associated objfile.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2022-02-25 10:54:04 +00:00
|
|
|
@defvar Type.is_scalar
|
|
|
|
|
This property is @code{True} if the type is a scalar type, otherwise,
|
|
|
|
|
this property is @code{False}. Examples of non-scalar types include
|
|
|
|
|
structures, unions, and classes.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2021-11-30 14:35:44 +00:00
|
|
|
@defvar Type.is_signed
|
|
|
|
|
For scalar types (those for which @code{Type.is_scalar} is
|
|
|
|
|
@code{True}), this property is @code{True} if the type is signed,
|
|
|
|
|
otherwise this property is @code{False}.
|
|
|
|
|
|
|
|
|
|
Attempting to read this property for a non-scalar type (a type for
|
|
|
|
|
which @code{Type.is_scalar} is @code{False}), will raise a
|
|
|
|
|
@code{ValueError}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2023-07-24 07:29:46 -06:00
|
|
|
@defvar Type.is_array_like
|
|
|
|
|
@anchor{Type.is_array_like}
|
|
|
|
|
A boolean indicating whether this type is array-like.
|
|
|
|
|
|
|
|
|
|
Some languages have array-like objects that are represented internally
|
|
|
|
|
as structures. For example, this is true for a Rust slice type, or
|
|
|
|
|
for an Ada unconstrained array. @value{GDBN} may know about these
|
|
|
|
|
types. This determination is done based on the language from which
|
|
|
|
|
the type originated.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Type.is_string_like
|
|
|
|
|
A boolean indicating whether this type is string-like. Like
|
|
|
|
|
@code{Type.is_array_like}, this is determined based on the originating
|
|
|
|
|
language of the type.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
The following methods are provided:
|
|
|
|
|
|
|
|
|
|
@defun Type.fields ()
|
2021-05-04 22:19:05 -04:00
|
|
|
|
|
|
|
|
Return the fields of this type. The behavior depends on the type code:
|
|
|
|
|
|
|
|
|
|
@itemize @bullet
|
|
|
|
|
|
|
|
|
|
@item
|
|
|
|
|
For structure and union types, this method returns the fields.
|
|
|
|
|
|
|
|
|
|
@item
|
|
|
|
|
Enum types have one field per enum constant.
|
|
|
|
|
|
|
|
|
|
@item
|
|
|
|
|
Function and method types have one field per parameter. The base types of
|
|
|
|
|
C@t{++} classes are also represented as fields.
|
|
|
|
|
|
|
|
|
|
@item
|
|
|
|
|
Array types have one field representing the array's range.
|
|
|
|
|
|
|
|
|
|
@item
|
|
|
|
|
If the type does not fit into one of these categories, a @code{TypeError}
|
|
|
|
|
is raised.
|
|
|
|
|
|
|
|
|
|
@end itemize
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
Each field is a @code{gdb.Field} object, with some pre-defined attributes:
|
|
|
|
|
@table @code
|
|
|
|
|
@item bitpos
|
|
|
|
|
This attribute is not available for @code{enum} or @code{static}
|
Remove Java support
This patch removes the Java support from gdb. gcj has not seen much
development or use for years now, and was recently removed from GCC.
This patch changes gdb to follow; in the unlikely event that there are
still users using gcj, they can continue to use an older gdb to debug.
Or, they can debug in C++ mode.
Built and regtested on x86-64 Fedora 24.
2016-10-06 Tom Tromey <tom@tromey.com>
* MAINTAINERS: Remove Java test maintainer.
* varobj.h (java_varobj_ops): Don't declare.
* valprint.h (struct value_print_options)
<pascal_static_field_print>: Update comment.
* utils.c (producer_is_gcc): Remove java reference.
* symtab.h (struct general_symbol_info): Remove java references.
(SYMBOL_SEARCH_NAME): Likewise.
* objfiles.c (allocate_objfile): Update comment.
* linespec.c (find_linespec_symbols): Remove java references.
* gnu-v3-abi.c (gnuv3_rtti_type, gnuv3_baseclass_offset): Remove
java references.
* gdbtypes.h (struct cplus_struct_type) <is_java>: Remove.
(TYPE_CPLUS_REALLY_JAVA): Remove.
* c-varobj.c (enum vsections): Update comment.
* symtab.c (symbol_set_language, symbol_set_names)
(symbol_natural_name, symbol_demangled_name)
(demangle_for_lookup, symbol_matches_domain)
(default_make_symbol_completion_list_break_on_1): Remove java
references.
(JAVA_PREFIX, JAVA_PREFIX_LEN): Remove.
* psymtab.c (match_partial_symbol, psymtab_search_name)
(lookup_partial_symbol): Remove java references.
* dwarf2read.c (find_slot_in_mapped_hash): Remove java references.
(add_partial_symbol, dwarf2_compute_name, dwarf2_physname)
(dwarf2_add_member_fn, is_vtable_name, read_structure_type)
(process_structure_scope, read_subroutine_type)
(read_subrange_type, load_partial_dies)
(new_symbol_full, determine_prefix, typename_concat)
(dwarf2_name): Remove java references.
(set_cu_language): Treat Java as C++.
* c-typeprint.c (c_type_print_args): Remove java reference.
* defs.h (enum language) <language_java>: Remove.
* Makefile.in (SFILES, HFILES_NO_SRCDIR, COMMON_OBS, YYFILES)
(YYOBJ, local-maintainer-clean): Don't mention java files.
* jv-exp.y, jv-lang.c, jv-lang.h, jv-typeprint.c, jv-valprint.c,
jv-varobj.c: Remove.
2016-10-06 Tom Tromey <tom@tromey.com>
* guile.texi (Types In Guile): Remove Java mentions.
* python.texi (Types In Python): Remove Java mentions.
* gdb.texinfo (Address Locations, Supported Languages)
(Index Section Format): Remove Java mentions.
2016-10-06 Tom Tromey <tom@tromey.com>
* gdb.compile/compile.exp: Change java tests to rust.
* gdb.base/setshow.exp: Change java tests to rust.
* gdb.base/default.exp: Remove java from language list.
* README (Examples): Update language example.
* gdb.python/py-lookup-type.exp (test_lookup_type): Remove java
test.
* lib/gdb.exp (skip_java_tests): Remove.
* lib/java.exp: Remove.
* gdb.java: Remove.
2016-10-05 08:44:34 -06:00
|
|
|
(as in C@t{++}) fields. The value is the position, counting
|
2020-04-24 13:40:31 -06:00
|
|
|
in bits, from the start of the containing type. Note that, in a
|
|
|
|
|
dynamic type, the position of a field may not be constant. In this
|
2020-04-27 08:23:53 -06:00
|
|
|
case, the value will be @code{None}. Also, a dynamic type may have
|
|
|
|
|
fields that do not appear in a corresponding concrete type.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@item enumval
|
|
|
|
|
This attribute is only available for @code{enum} fields, and its value
|
|
|
|
|
is the enumeration member's integer representation.
|
|
|
|
|
|
|
|
|
|
@item name
|
|
|
|
|
The name of the field, or @code{None} for anonymous fields.
|
|
|
|
|
|
|
|
|
|
@item artificial
|
|
|
|
|
This is @code{True} if the field is artificial, usually meaning that
|
|
|
|
|
it was provided by the compiler and not the user. This attribute is
|
|
|
|
|
always provided, and is @code{False} if the field is not artificial.
|
|
|
|
|
|
|
|
|
|
@item is_base_class
|
|
|
|
|
This is @code{True} if the field represents a base class of a C@t{++}
|
|
|
|
|
structure. This attribute is always provided, and is @code{False}
|
|
|
|
|
if the field is not a base class of the type that is the argument of
|
|
|
|
|
@code{fields}, or if that type was not a C@t{++} class.
|
|
|
|
|
|
|
|
|
|
@item bitsize
|
|
|
|
|
If the field is packed, or is a bitfield, then this will have a
|
|
|
|
|
non-zero value, which is the size of the field in bits. Otherwise,
|
|
|
|
|
this will be zero; in this case the field's size is given by its type.
|
|
|
|
|
|
|
|
|
|
@item type
|
|
|
|
|
The type of the field. This is usually an instance of @code{Type},
|
|
|
|
|
but it can be @code{None} in some situations.
|
|
|
|
|
|
|
|
|
|
@item parent_type
|
|
|
|
|
The type which contains this field. This is an instance of
|
|
|
|
|
@code{gdb.Type}.
|
|
|
|
|
@end table
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Type.array (n1 @r{[}, n2@r{]})
|
2014-02-17 10:35:03 -08:00
|
|
|
Return a new @code{gdb.Type} object which represents an array of this
|
|
|
|
|
type. If one argument is given, it is the inclusive upper bound of
|
|
|
|
|
the array; in this case the lower bound is zero. If two arguments are
|
|
|
|
|
given, the first argument is the lower bound of the array, and the
|
|
|
|
|
second argument is the upper bound of the array. An array's length
|
|
|
|
|
must not be negative, but the bounds can be.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Type.vector (n1 @r{[}, n2@r{]})
|
2014-02-17 10:35:03 -08:00
|
|
|
Return a new @code{gdb.Type} object which represents a vector of this
|
|
|
|
|
type. If one argument is given, it is the inclusive upper bound of
|
|
|
|
|
the vector; in this case the lower bound is zero. If two arguments are
|
|
|
|
|
given, the first argument is the lower bound of the vector, and the
|
|
|
|
|
second argument is the upper bound of the vector. A vector's length
|
|
|
|
|
must not be negative, but the bounds can be.
|
|
|
|
|
|
|
|
|
|
The difference between an @code{array} and a @code{vector} is that
|
|
|
|
|
arrays behave like in C: when used in expressions they decay to a pointer
|
|
|
|
|
to the first element whereas vectors are treated as first class values.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Type.const ()
|
|
|
|
|
Return a new @code{gdb.Type} object which represents a
|
|
|
|
|
@code{const}-qualified variant of this type.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Type.volatile ()
|
|
|
|
|
Return a new @code{gdb.Type} object which represents a
|
|
|
|
|
@code{volatile}-qualified variant of this type.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Type.unqualified ()
|
|
|
|
|
Return a new @code{gdb.Type} object which represents an unqualified
|
|
|
|
|
variant of this type. That is, the result is neither @code{const} nor
|
|
|
|
|
@code{volatile}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Type.range ()
|
|
|
|
|
Return a Python @code{Tuple} object that contains two elements: the
|
|
|
|
|
low bound of the argument type and the high bound of that type. If
|
|
|
|
|
the type does not have a range, @value{GDBN} will raise a
|
|
|
|
|
@code{gdb.error} exception (@pxref{Exception Handling}).
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Type.reference ()
|
|
|
|
|
Return a new @code{gdb.Type} object which represents a reference to this
|
|
|
|
|
type.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Type.pointer ()
|
|
|
|
|
Return a new @code{gdb.Type} object which represents a pointer to this
|
|
|
|
|
type.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Type.strip_typedefs ()
|
|
|
|
|
Return a new @code{gdb.Type} that represents the real type,
|
|
|
|
|
after removing all layers of typedefs.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Type.target ()
|
|
|
|
|
Return a new @code{gdb.Type} object which represents the target type
|
|
|
|
|
of this type.
|
|
|
|
|
|
|
|
|
|
For a pointer type, the target type is the type of the pointed-to
|
|
|
|
|
object. For an array type (meaning C-like arrays), the target type is
|
|
|
|
|
the type of the elements of the array. For a function or method type,
|
|
|
|
|
the target type is the type of the return value. For a complex type,
|
|
|
|
|
the target type is the type of the elements. For a typedef, the
|
|
|
|
|
target type is the aliased type.
|
|
|
|
|
|
|
|
|
|
If the type does not have a target, this method will throw an
|
|
|
|
|
exception.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Type.template_argument (n @r{[}, block@r{]})
|
|
|
|
|
If this @code{gdb.Type} is an instantiation of a template, this will
|
2014-09-03 16:40:22 -07:00
|
|
|
return a new @code{gdb.Value} or @code{gdb.Type} which represents the
|
|
|
|
|
value of the @var{n}th template argument (indexed starting at 0).
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2014-09-03 16:40:22 -07:00
|
|
|
If this @code{gdb.Type} is not a template type, or if the type has fewer
|
|
|
|
|
than @var{n} template arguments, this will throw an exception.
|
|
|
|
|
Ordinarily, only C@t{++} code will have template types.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
If @var{block} is given, then @var{name} is looked up in that scope.
|
|
|
|
|
Otherwise, it is searched for globally.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2015-04-28 17:41:09 -07:00
|
|
|
@defun Type.optimized_out ()
|
|
|
|
|
Return @code{gdb.Value} instance of this type whose value is optimized
|
|
|
|
|
out. This allows a frame decorator to indicate that the value of an
|
|
|
|
|
argument or a local variable is not known.
|
|
|
|
|
@end defun
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
Each type has a code, which indicates what category this type falls
|
|
|
|
|
into. The available type categories are represented by constants
|
|
|
|
|
defined in the @code{gdb} module:
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vtable @code
|
|
|
|
|
@vindex TYPE_CODE_PTR
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_PTR
|
|
|
|
|
The type is a pointer.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_ARRAY
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_ARRAY
|
|
|
|
|
The type is an array.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_STRUCT
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_STRUCT
|
|
|
|
|
The type is a structure.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_UNION
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_UNION
|
|
|
|
|
The type is a union.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_ENUM
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_ENUM
|
|
|
|
|
The type is an enum.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_FLAGS
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_FLAGS
|
|
|
|
|
A bit flags type, used for things such as status registers.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_FUNC
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_FUNC
|
|
|
|
|
The type is a function.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_INT
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_INT
|
|
|
|
|
The type is an integer type.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_FLT
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_FLT
|
|
|
|
|
A floating point type.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_VOID
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_VOID
|
|
|
|
|
The special type @code{void}.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_SET
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_SET
|
|
|
|
|
A Pascal set type.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_RANGE
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_RANGE
|
|
|
|
|
A range type, that is, an integer type with bounds.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_STRING
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_STRING
|
|
|
|
|
A string type. Note that this is only used for certain languages with
|
|
|
|
|
language-defined string types; C strings are not represented this way.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_BITSTRING
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_BITSTRING
|
|
|
|
|
A string of bits. It is deprecated.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_ERROR
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_ERROR
|
|
|
|
|
An unknown or erroneous type.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_METHOD
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_METHOD
|
Remove Java support
This patch removes the Java support from gdb. gcj has not seen much
development or use for years now, and was recently removed from GCC.
This patch changes gdb to follow; in the unlikely event that there are
still users using gcj, they can continue to use an older gdb to debug.
Or, they can debug in C++ mode.
Built and regtested on x86-64 Fedora 24.
2016-10-06 Tom Tromey <tom@tromey.com>
* MAINTAINERS: Remove Java test maintainer.
* varobj.h (java_varobj_ops): Don't declare.
* valprint.h (struct value_print_options)
<pascal_static_field_print>: Update comment.
* utils.c (producer_is_gcc): Remove java reference.
* symtab.h (struct general_symbol_info): Remove java references.
(SYMBOL_SEARCH_NAME): Likewise.
* objfiles.c (allocate_objfile): Update comment.
* linespec.c (find_linespec_symbols): Remove java references.
* gnu-v3-abi.c (gnuv3_rtti_type, gnuv3_baseclass_offset): Remove
java references.
* gdbtypes.h (struct cplus_struct_type) <is_java>: Remove.
(TYPE_CPLUS_REALLY_JAVA): Remove.
* c-varobj.c (enum vsections): Update comment.
* symtab.c (symbol_set_language, symbol_set_names)
(symbol_natural_name, symbol_demangled_name)
(demangle_for_lookup, symbol_matches_domain)
(default_make_symbol_completion_list_break_on_1): Remove java
references.
(JAVA_PREFIX, JAVA_PREFIX_LEN): Remove.
* psymtab.c (match_partial_symbol, psymtab_search_name)
(lookup_partial_symbol): Remove java references.
* dwarf2read.c (find_slot_in_mapped_hash): Remove java references.
(add_partial_symbol, dwarf2_compute_name, dwarf2_physname)
(dwarf2_add_member_fn, is_vtable_name, read_structure_type)
(process_structure_scope, read_subroutine_type)
(read_subrange_type, load_partial_dies)
(new_symbol_full, determine_prefix, typename_concat)
(dwarf2_name): Remove java references.
(set_cu_language): Treat Java as C++.
* c-typeprint.c (c_type_print_args): Remove java reference.
* defs.h (enum language) <language_java>: Remove.
* Makefile.in (SFILES, HFILES_NO_SRCDIR, COMMON_OBS, YYFILES)
(YYOBJ, local-maintainer-clean): Don't mention java files.
* jv-exp.y, jv-lang.c, jv-lang.h, jv-typeprint.c, jv-valprint.c,
jv-varobj.c: Remove.
2016-10-06 Tom Tromey <tom@tromey.com>
* guile.texi (Types In Guile): Remove Java mentions.
* python.texi (Types In Python): Remove Java mentions.
* gdb.texinfo (Address Locations, Supported Languages)
(Index Section Format): Remove Java mentions.
2016-10-06 Tom Tromey <tom@tromey.com>
* gdb.compile/compile.exp: Change java tests to rust.
* gdb.base/setshow.exp: Change java tests to rust.
* gdb.base/default.exp: Remove java from language list.
* README (Examples): Update language example.
* gdb.python/py-lookup-type.exp (test_lookup_type): Remove java
test.
* lib/gdb.exp (skip_java_tests): Remove.
* lib/java.exp: Remove.
* gdb.java: Remove.
2016-10-05 08:44:34 -06:00
|
|
|
A method type, as found in C@t{++}.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_METHODPTR
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_METHODPTR
|
|
|
|
|
A pointer-to-member-function.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_MEMBERPTR
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_MEMBERPTR
|
|
|
|
|
A pointer-to-member.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_REF
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_REF
|
|
|
|
|
A reference type.
|
|
|
|
|
|
2017-03-20 13:47:52 -07:00
|
|
|
@vindex TYPE_CODE_RVALUE_REF
|
|
|
|
|
@item gdb.TYPE_CODE_RVALUE_REF
|
|
|
|
|
A C@t{++}11 rvalue reference type.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_CHAR
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_CHAR
|
|
|
|
|
A character type.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_BOOL
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_BOOL
|
|
|
|
|
A boolean type.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_COMPLEX
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_COMPLEX
|
|
|
|
|
A complex float type.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_TYPEDEF
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_TYPEDEF
|
|
|
|
|
A typedef to some other type.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_NAMESPACE
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_NAMESPACE
|
|
|
|
|
A C@t{++} namespace.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_DECFLOAT
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_DECFLOAT
|
|
|
|
|
A decimal floating point type.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex TYPE_CODE_INTERNAL_FUNCTION
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.TYPE_CODE_INTERNAL_FUNCTION
|
|
|
|
|
A function internal to @value{GDBN}. This is the type used to represent
|
|
|
|
|
convenience functions.
|
2022-10-12 08:40:34 -06:00
|
|
|
|
|
|
|
|
@vindex TYPE_CODE_XMETHOD
|
|
|
|
|
@item gdb.TYPE_CODE_XMETHOD
|
|
|
|
|
A method internal to @value{GDBN}. This is the type used to represent
|
|
|
|
|
xmethods (@pxref{Writing an Xmethod}).
|
|
|
|
|
|
|
|
|
|
@vindex TYPE_CODE_FIXED_POINT
|
|
|
|
|
@item gdb.TYPE_CODE_FIXED_POINT
|
|
|
|
|
A fixed-point number.
|
|
|
|
|
|
|
|
|
|
@vindex TYPE_CODE_NAMESPACE
|
|
|
|
|
@item gdb.TYPE_CODE_NAMESPACE
|
|
|
|
|
A Fortran namelist.
|
2014-05-17 09:13:00 -07:00
|
|
|
@end vtable
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
Further support for types is provided in the @code{gdb.types}
|
|
|
|
|
Python module (@pxref{gdb.types}).
|
|
|
|
|
|
|
|
|
|
@node Pretty Printing API
|
|
|
|
|
@subsubsection Pretty Printing API
|
2014-05-17 09:13:00 -07:00
|
|
|
@cindex python pretty printing api
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
A pretty-printer is just an object that holds a value and implements a
|
2018-09-08 13:50:09 -06:00
|
|
|
specific interface, defined here. An example output is provided
|
|
|
|
|
(@pxref{Pretty Printing}).
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2023-09-07 13:40:29 -06:00
|
|
|
Because @value{GDBN} did not document extensibility for
|
|
|
|
|
pretty-printers, by default @value{GDBN} will assume that only the
|
|
|
|
|
basic pretty-printer methods may be available. The basic methods are
|
|
|
|
|
marked as such, below.
|
|
|
|
|
|
|
|
|
|
To allow extensibility, @value{GDBN} provides the
|
|
|
|
|
@code{gdb.ValuePrinter} base class. This class does not provide any
|
|
|
|
|
attributes or behavior, but instead serves as a tag that can be
|
|
|
|
|
recognized by @value{GDBN}. For such printers, @value{GDBN} reserves
|
|
|
|
|
all attributes starting with a lower-case letter. That is, in the
|
|
|
|
|
future, @value{GDBN} may add a new method or attribute to the
|
|
|
|
|
pretty-printer protocol, and @code{gdb.ValuePrinter}-based printers
|
|
|
|
|
are expected to handle this gracefully. A simple way to do this would
|
|
|
|
|
be to use a leading underscore (or two, following the Python
|
|
|
|
|
name-mangling scheme) to any attributes local to the implementation.
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun pretty_printer.children (self)
|
|
|
|
|
@value{GDBN} will call this method on a pretty-printer to compute the
|
|
|
|
|
children of the pretty-printer's value.
|
|
|
|
|
|
|
|
|
|
This method must return an object conforming to the Python iterator
|
|
|
|
|
protocol. Each item returned by the iterator must be a tuple holding
|
|
|
|
|
two elements. The first element is the ``name'' of the child; the
|
|
|
|
|
second element is the child's value. The value can be any Python
|
|
|
|
|
object which is convertible to a @value{GDBN} value.
|
|
|
|
|
|
2023-09-07 13:40:29 -06:00
|
|
|
This is a basic method, and is optional. If it does not exist,
|
|
|
|
|
@value{GDBN} will act as though the value has no children.
|
gdb: Introduce 'print max-depth' feature
Introduce a new print setting max-depth which can be set with 'set
print max-depth DEPTH'. The default value of DEPTH is 20, but this
can also be set to unlimited.
When GDB is printing a value containing nested structures GDB will
stop descending at depth DEPTH. Here is a small example:
typedef struct s1 { int a; } s1;
typedef struct s2 { s1 b; } s2;
typedef struct s3 { s2 c; } s3;
typedef struct s4 { s3 d; } s4;
s4 var = { { { { 3 } } } };
The following table shows how various depth settings affect printing
of 'var':
| Depth Setting | Result of 'p var' |
|---------------+--------------------------------|
| Unlimited | $1 = {d = {c = {b = {a = 3}}}} |
| 4 | $1 = {d = {c = {b = {a = 3}}}} |
| 3 | $1 = {d = {c = {b = {...}}}} |
| 2 | $1 = {d = {c = {...}}} |
| 1 | $1 = {d = {...}} |
| 0 | $1 = {...} |
Only structures, unions, and arrays are replaced in this way, scalars
and strings are not replaced.
The replacement is counted from the level at which you print, not from
the top level of the structure. So, consider the above example and
this GDB session:
(gdb) set print max-depth 2
(gdb) p var
$1 = {d = {c = {...}}}
(gdb) p var.d
$2 = {c = {b = {...}}}
(gdb) p var.d.c
$3 = {b = {a = 3}}
Setting the max-depth to 2 doesn't prevent the user from exploring
deeper into 'var' by asking for specific sub-fields to be printed.
The motivation behind this feature is to try and give the user more
control over how much is printed when examining large, complex data
structures.
The default max-depth of 20 means that there is a change in GDB's
default behaviour. Someone printing a data structure with 20 levels
of nesting will now see '{...}' instead of their data, they would need
to adjust the max depth, or call print again naming a specific field
in order to dig deeper into their data structure. If this is
considered a problem then we could increase the default, or even make
the default unlimited.
This commit relies on the previous commit, which added a new field to
the language structure, this new field was a string that contained the
pattern that should be used when a structure/union/array is replaced
in the output, this allows languages to use a syntax that is more
appropriate, mostly this will be selecting the correct types of
bracket '(...)' or '{...}', both of which are currently in use.
This commit should have no impact on MI output, expressions are
printed through the MI using -var-create and then -var-list-children.
As each use of -var-list-children only ever displays a single level of
an expression then the max-depth setting will have no impact.
This commit also adds the max-depth mechanism to the scripting
language pretty printers following basically the same rules as for the
built in value printing.
One quirk is that when printing a value using the display hint 'map',
if the keys of the map are structs then GDB will hide the keys one
depth level after it hides the values, this ensures that GDB produces
output like this:
$1 = map_object = {[{key1}] = {...}, [{key2}] = {...}}
Instead of this less helpful output:
$1 = map_object = {[{...}] = {...}, [{...}] = {...}}
This is covered by the new tests in gdb.python/py-nested-maps.exp.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value_fields): Allow an additional level
of depth when printing anonymous structs or unions.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer):
Don't print either the top-level value, or the children if the
max-depth is exceeded.
(ppscm_print_children): When printing the key of a map, allow one
extra level of depth.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't
print either the top-level value, or the children if the max-depth
is exceeded.
(print_children): When printing the key of a map, allow one extra
level of depth.
* python/py-value.c (valpy_format_string): Add max_depth keyword.
* valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define.
(user_print_options): Initialise max_depth field.
(val_print_scalar_or_string_type_p): New function.
(val_print): Check to see if the max depth has been reached.
(val_print_check_max_depth): Define new function.
(show_print_max_depth): New function.
(_initialize_valprint): Add 'print max-depth' option.
* valprint.h (struct value_print_options) <max_depth>: New field.
(val_print_check_max_depth): Declare new function.
* NEWS: Document new feature.
gdb/doc/ChangeLog:
* gdb.texinfo (Print Settings): Document 'print max-depth'.
* guile.texi (Guile Pretty Printing API): Document that 'print
max-depth' can effect the display of a values children.
* python.texi (Pretty Printing API): Likewise.
(Values From Inferior): Document max_depth keyword.
gdb/testsuite/ChangeLog:
* gdb.base/max-depth.c: New file.
* gdb.base/max-depth.exp: New file.
* gdb.python/py-nested-maps.c: New file.
* gdb.python/py-nested-maps.exp: New file.
* gdb.python/py-nested-maps.py: New file.
* gdb.python/py-format-string.exp (test_max_depth): New proc.
(test_all_common): Call test_max_depth.
* gdb.fortran/max-depth.exp: New file.
* gdb.fortran/max-depth.f90: New file.
* gdb.go/max-depth.exp: New file.
* gdb.go/max-depth.go: New file.
* gdb.modula2/max-depth.exp: New file.
* gdb.modula2/max-depth.c: New file.
* lib/gdb.exp (get_print_expr_at_depths): New proc.
2019-03-21 15:13:23 +00:00
|
|
|
|
2019-05-10 08:19:04 -06:00
|
|
|
For efficiency, the @code{children} method should lazily compute its
|
|
|
|
|
results. This will let @value{GDBN} read as few elements as
|
|
|
|
|
necessary, for example when various print settings (@pxref{Print
|
|
|
|
|
Settings}) or @code{-var-list-children} (@pxref{GDB/MI Variable
|
|
|
|
|
Objects}) limit the number of elements to be displayed.
|
|
|
|
|
|
gdb: Introduce 'print max-depth' feature
Introduce a new print setting max-depth which can be set with 'set
print max-depth DEPTH'. The default value of DEPTH is 20, but this
can also be set to unlimited.
When GDB is printing a value containing nested structures GDB will
stop descending at depth DEPTH. Here is a small example:
typedef struct s1 { int a; } s1;
typedef struct s2 { s1 b; } s2;
typedef struct s3 { s2 c; } s3;
typedef struct s4 { s3 d; } s4;
s4 var = { { { { 3 } } } };
The following table shows how various depth settings affect printing
of 'var':
| Depth Setting | Result of 'p var' |
|---------------+--------------------------------|
| Unlimited | $1 = {d = {c = {b = {a = 3}}}} |
| 4 | $1 = {d = {c = {b = {a = 3}}}} |
| 3 | $1 = {d = {c = {b = {...}}}} |
| 2 | $1 = {d = {c = {...}}} |
| 1 | $1 = {d = {...}} |
| 0 | $1 = {...} |
Only structures, unions, and arrays are replaced in this way, scalars
and strings are not replaced.
The replacement is counted from the level at which you print, not from
the top level of the structure. So, consider the above example and
this GDB session:
(gdb) set print max-depth 2
(gdb) p var
$1 = {d = {c = {...}}}
(gdb) p var.d
$2 = {c = {b = {...}}}
(gdb) p var.d.c
$3 = {b = {a = 3}}
Setting the max-depth to 2 doesn't prevent the user from exploring
deeper into 'var' by asking for specific sub-fields to be printed.
The motivation behind this feature is to try and give the user more
control over how much is printed when examining large, complex data
structures.
The default max-depth of 20 means that there is a change in GDB's
default behaviour. Someone printing a data structure with 20 levels
of nesting will now see '{...}' instead of their data, they would need
to adjust the max depth, or call print again naming a specific field
in order to dig deeper into their data structure. If this is
considered a problem then we could increase the default, or even make
the default unlimited.
This commit relies on the previous commit, which added a new field to
the language structure, this new field was a string that contained the
pattern that should be used when a structure/union/array is replaced
in the output, this allows languages to use a syntax that is more
appropriate, mostly this will be selecting the correct types of
bracket '(...)' or '{...}', both of which are currently in use.
This commit should have no impact on MI output, expressions are
printed through the MI using -var-create and then -var-list-children.
As each use of -var-list-children only ever displays a single level of
an expression then the max-depth setting will have no impact.
This commit also adds the max-depth mechanism to the scripting
language pretty printers following basically the same rules as for the
built in value printing.
One quirk is that when printing a value using the display hint 'map',
if the keys of the map are structs then GDB will hide the keys one
depth level after it hides the values, this ensures that GDB produces
output like this:
$1 = map_object = {[{key1}] = {...}, [{key2}] = {...}}
Instead of this less helpful output:
$1 = map_object = {[{...}] = {...}, [{...}] = {...}}
This is covered by the new tests in gdb.python/py-nested-maps.exp.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value_fields): Allow an additional level
of depth when printing anonymous structs or unions.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer):
Don't print either the top-level value, or the children if the
max-depth is exceeded.
(ppscm_print_children): When printing the key of a map, allow one
extra level of depth.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't
print either the top-level value, or the children if the max-depth
is exceeded.
(print_children): When printing the key of a map, allow one extra
level of depth.
* python/py-value.c (valpy_format_string): Add max_depth keyword.
* valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define.
(user_print_options): Initialise max_depth field.
(val_print_scalar_or_string_type_p): New function.
(val_print): Check to see if the max depth has been reached.
(val_print_check_max_depth): Define new function.
(show_print_max_depth): New function.
(_initialize_valprint): Add 'print max-depth' option.
* valprint.h (struct value_print_options) <max_depth>: New field.
(val_print_check_max_depth): Declare new function.
* NEWS: Document new feature.
gdb/doc/ChangeLog:
* gdb.texinfo (Print Settings): Document 'print max-depth'.
* guile.texi (Guile Pretty Printing API): Document that 'print
max-depth' can effect the display of a values children.
* python.texi (Pretty Printing API): Likewise.
(Values From Inferior): Document max_depth keyword.
gdb/testsuite/ChangeLog:
* gdb.base/max-depth.c: New file.
* gdb.base/max-depth.exp: New file.
* gdb.python/py-nested-maps.c: New file.
* gdb.python/py-nested-maps.exp: New file.
* gdb.python/py-nested-maps.py: New file.
* gdb.python/py-format-string.exp (test_max_depth): New proc.
(test_all_common): Call test_max_depth.
* gdb.fortran/max-depth.exp: New file.
* gdb.fortran/max-depth.f90: New file.
* gdb.go/max-depth.exp: New file.
* gdb.go/max-depth.go: New file.
* gdb.modula2/max-depth.exp: New file.
* gdb.modula2/max-depth.c: New file.
* lib/gdb.exp (get_print_expr_at_depths): New proc.
2019-03-21 15:13:23 +00:00
|
|
|
Children may be hidden from display based on the value of @samp{set
|
|
|
|
|
print max-depth} (@pxref{Print Settings}).
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun pretty_printer.display_hint (self)
|
|
|
|
|
The CLI may call this method and use its result to change the
|
|
|
|
|
formatting of a value. The result will also be supplied to an MI
|
|
|
|
|
consumer as a @samp{displayhint} attribute of the variable being
|
|
|
|
|
printed.
|
|
|
|
|
|
2023-09-07 13:40:29 -06:00
|
|
|
This is a basic method, and is optional. If it does exist, this
|
|
|
|
|
method must return a string or the special value @code{None}.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
Some display hints are predefined by @value{GDBN}:
|
|
|
|
|
|
|
|
|
|
@table @samp
|
|
|
|
|
@item array
|
|
|
|
|
Indicate that the object being printed is ``array-like''. The CLI
|
|
|
|
|
uses this to respect parameters such as @code{set print elements} and
|
|
|
|
|
@code{set print array}.
|
|
|
|
|
|
|
|
|
|
@item map
|
|
|
|
|
Indicate that the object being printed is ``map-like'', and that the
|
|
|
|
|
children of this value can be assumed to alternate between keys and
|
|
|
|
|
values.
|
|
|
|
|
|
|
|
|
|
@item string
|
|
|
|
|
Indicate that the object being printed is ``string-like''. If the
|
|
|
|
|
printer's @code{to_string} method returns a Python string of some
|
|
|
|
|
kind, then @value{GDBN} will call its internal language-specific
|
|
|
|
|
string-printing function to format the string. For the CLI this means
|
|
|
|
|
adding quotation marks, possibly escaping some characters, respecting
|
|
|
|
|
@code{set print elements}, and the like.
|
|
|
|
|
@end table
|
2019-03-21 16:29:14 +00:00
|
|
|
|
|
|
|
|
The special value @code{None} causes @value{GDBN} to apply the default
|
|
|
|
|
display rules.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun pretty_printer.to_string (self)
|
|
|
|
|
@value{GDBN} will call this method to display the string
|
|
|
|
|
representation of the value passed to the object's constructor.
|
|
|
|
|
|
2023-09-07 13:40:29 -06:00
|
|
|
This is a basic method, and is optional.
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
When printing from the CLI, if the @code{to_string} method exists,
|
|
|
|
|
then @value{GDBN} will prepend its result to the values returned by
|
|
|
|
|
@code{children}. Exactly how this formatting is done is dependent on
|
|
|
|
|
the display hint, and may change as more hints are added. Also,
|
|
|
|
|
depending on the print settings (@pxref{Print Settings}), the CLI may
|
|
|
|
|
print just the result of @code{to_string} in a stack trace, omitting
|
|
|
|
|
the result of @code{children}.
|
|
|
|
|
|
|
|
|
|
If this method returns a string, it is printed verbatim.
|
|
|
|
|
|
|
|
|
|
Otherwise, if this method returns an instance of @code{gdb.Value},
|
|
|
|
|
then @value{GDBN} prints this value. This may result in a call to
|
|
|
|
|
another pretty-printer.
|
|
|
|
|
|
|
|
|
|
If instead the method returns a Python value which is convertible to a
|
|
|
|
|
@code{gdb.Value}, then @value{GDBN} performs the conversion and prints
|
|
|
|
|
the resulting value. Again, this may result in a call to another
|
|
|
|
|
pretty-printer. Python scalars (integers, floats, and booleans) and
|
|
|
|
|
strings are convertible to @code{gdb.Value}; other types are not.
|
|
|
|
|
|
|
|
|
|
Finally, if this method returns @code{None} then no further operations
|
2024-02-08 20:31:51 +01:00
|
|
|
are performed in this method and nothing is printed.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
If the result is not one of these types, an exception is raised.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-09-08 13:18:17 -06:00
|
|
|
@defun pretty_printer.num_children ()
|
|
|
|
|
This is not a basic method, so @value{GDBN} will only ever call it for
|
|
|
|
|
objects derived from @code{gdb.ValuePrinter}.
|
|
|
|
|
|
|
|
|
|
If available, this method should return the number of children.
|
|
|
|
|
@code{None} may be returned if the number can't readily be computed.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun pretty_printer.child (n)
|
|
|
|
|
This is not a basic method, so @value{GDBN} will only ever call it for
|
|
|
|
|
objects derived from @code{gdb.ValuePrinter}.
|
|
|
|
|
|
2024-05-21 05:13:18 -06:00
|
|
|
If available, this method should return the child item (that is, a
|
|
|
|
|
tuple holding the name and value of this child) indicated by @var{n}.
|
|
|
|
|
Indices start at zero.
|
2023-09-08 13:18:17 -06:00
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@value{GDBN} provides a function which can be used to look up the
|
|
|
|
|
default pretty-printer for a @code{gdb.Value}:
|
|
|
|
|
|
|
|
|
|
@defun gdb.default_visualizer (value)
|
|
|
|
|
This function takes a @code{gdb.Value} object as an argument. If a
|
|
|
|
|
pretty-printer for this value exists, then it is returned. If no such
|
|
|
|
|
printer exists, then this returns @code{None}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2022-06-06 09:54:45 -06:00
|
|
|
Normally, a pretty-printer can respect the user's print settings
|
|
|
|
|
(including temporarily applied settings, such as @samp{/x}) simply by
|
|
|
|
|
calling @code{Value.format_string} (@pxref{Values From Inferior}).
|
|
|
|
|
However, these settings can also be queried directly:
|
|
|
|
|
|
|
|
|
|
@defun gdb.print_options ()
|
|
|
|
|
Return a dictionary whose keys are the valid keywords that can be
|
|
|
|
|
given to @code{Value.format_string}, and whose values are the user's
|
|
|
|
|
settings. During a @code{print} or other operation, the values will
|
|
|
|
|
reflect any flags that are temporarily in effect.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(gdb) python print (gdb.print_options ()['max_elements'])
|
|
|
|
|
200
|
|
|
|
|
@end smallexample
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Selecting Pretty-Printers
|
|
|
|
|
@subsubsection Selecting Pretty-Printers
|
2014-05-17 09:13:00 -07:00
|
|
|
@cindex selecting python pretty-printers
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2019-03-20 08:12:38 -06:00
|
|
|
@value{GDBN} provides several ways to register a pretty-printer:
|
|
|
|
|
globally, per program space, and per objfile. When choosing how to
|
|
|
|
|
register your pretty-printer, a good rule is to register it with the
|
|
|
|
|
smallest scope possible: that is prefer a specific objfile first, then
|
|
|
|
|
a program space, and only register a printer globally as a last
|
|
|
|
|
resort.
|
|
|
|
|
|
|
|
|
|
@defvar gdb.pretty_printers
|
2014-02-17 10:35:03 -08:00
|
|
|
The Python list @code{gdb.pretty_printers} contains an array of
|
|
|
|
|
functions or callable objects that have been registered via addition
|
|
|
|
|
as a pretty-printer. Printers in this list are called @code{global}
|
|
|
|
|
printers, they're available when debugging all inferiors.
|
2019-03-20 08:12:38 -06:00
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
Each @code{gdb.Progspace} contains a @code{pretty_printers} attribute.
|
|
|
|
|
Each @code{gdb.Objfile} also contains a @code{pretty_printers}
|
|
|
|
|
attribute.
|
|
|
|
|
|
|
|
|
|
Each function on these lists is passed a single @code{gdb.Value}
|
|
|
|
|
argument and should return a pretty-printer object conforming to the
|
|
|
|
|
interface definition above (@pxref{Pretty Printing API}). If a function
|
|
|
|
|
cannot create a pretty-printer for the value, it should return
|
|
|
|
|
@code{None}.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} first checks the @code{pretty_printers} attribute of each
|
|
|
|
|
@code{gdb.Objfile} in the current program space and iteratively calls
|
|
|
|
|
each enabled lookup routine in the list for that @code{gdb.Objfile}
|
|
|
|
|
until it receives a pretty-printer object.
|
|
|
|
|
If no pretty-printer is found in the objfile lists, @value{GDBN} then
|
|
|
|
|
searches the pretty-printer list of the current program space,
|
|
|
|
|
calling each enabled function until an object is returned.
|
|
|
|
|
After these lists have been exhausted, it tries the global
|
|
|
|
|
@code{gdb.pretty_printers} list, again calling each enabled function until an
|
|
|
|
|
object is returned.
|
|
|
|
|
|
|
|
|
|
The order in which the objfiles are searched is not specified. For a
|
|
|
|
|
given list, functions are always invoked from the head of the list,
|
|
|
|
|
and iterated over sequentially until the end of the list, or a printer
|
|
|
|
|
object is returned.
|
|
|
|
|
|
|
|
|
|
For various reasons a pretty-printer may not work.
|
|
|
|
|
For example, the underlying data structure may have changed and
|
|
|
|
|
the pretty-printer is out of date.
|
|
|
|
|
|
|
|
|
|
The consequences of a broken pretty-printer are severe enough that
|
|
|
|
|
@value{GDBN} provides support for enabling and disabling individual
|
|
|
|
|
printers. For example, if @code{print frame-arguments} is on,
|
|
|
|
|
a backtrace can become highly illegible if any argument is printed
|
|
|
|
|
with a broken printer.
|
|
|
|
|
|
|
|
|
|
Pretty-printers are enabled and disabled by attaching an @code{enabled}
|
|
|
|
|
attribute to the registered function or callable object. If this attribute
|
|
|
|
|
is present and its value is @code{False}, the printer is disabled, otherwise
|
|
|
|
|
the printer is enabled.
|
|
|
|
|
|
|
|
|
|
@node Writing a Pretty-Printer
|
|
|
|
|
@subsubsection Writing a Pretty-Printer
|
|
|
|
|
@cindex writing a pretty-printer
|
|
|
|
|
|
|
|
|
|
A pretty-printer consists of two parts: a lookup function to detect
|
|
|
|
|
if the type is supported, and the printer itself.
|
|
|
|
|
|
|
|
|
|
Here is an example showing how a @code{std::string} printer might be
|
|
|
|
|
written. @xref{Pretty Printing API}, for details on the API this class
|
2023-09-07 13:40:29 -06:00
|
|
|
must provide. Note that this example uses the @code{gdb.ValuePrinter}
|
|
|
|
|
base class, and is careful to use a leading underscore for its local
|
|
|
|
|
state.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@smallexample
|
2023-09-07 13:40:29 -06:00
|
|
|
class StdStringPrinter(gdb.ValuePrinter):
|
2014-02-17 10:35:03 -08:00
|
|
|
"Print a std::string"
|
|
|
|
|
|
|
|
|
|
def __init__(self, val):
|
2023-09-07 13:40:29 -06:00
|
|
|
self.__val = val
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
def to_string(self):
|
2023-09-07 13:40:29 -06:00
|
|
|
return self.__val['_M_dataplus']['_M_p']
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
def display_hint(self):
|
|
|
|
|
return 'string'
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
And here is an example showing how a lookup function for the printer
|
|
|
|
|
example above might be written.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
def str_lookup_function(val):
|
|
|
|
|
lookup_tag = val.type.tag
|
2021-06-07 23:14:55 +01:00
|
|
|
if lookup_tag is None:
|
2014-02-17 10:35:03 -08:00
|
|
|
return None
|
|
|
|
|
regex = re.compile("^std::basic_string<char,.*>$")
|
|
|
|
|
if regex.match(lookup_tag):
|
|
|
|
|
return StdStringPrinter(val)
|
|
|
|
|
return None
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The example lookup function extracts the value's type, and attempts to
|
|
|
|
|
match it to a type that it can pretty-print. If it is a type the
|
|
|
|
|
printer can pretty-print, it will return a printer object. If not, it
|
|
|
|
|
returns @code{None}.
|
|
|
|
|
|
|
|
|
|
We recommend that you put your core pretty-printers into a Python
|
|
|
|
|
package. If your pretty-printers are for use with a library, we
|
|
|
|
|
further recommend embedding a version number into the package name.
|
|
|
|
|
This practice will enable @value{GDBN} to load multiple versions of
|
|
|
|
|
your pretty-printers at the same time, because they will have
|
|
|
|
|
different names.
|
|
|
|
|
|
|
|
|
|
You should write auto-loaded code (@pxref{Python Auto-loading}) such that it
|
|
|
|
|
can be evaluated multiple times without changing its meaning. An
|
|
|
|
|
ideal auto-load file will consist solely of @code{import}s of your
|
|
|
|
|
printer modules, followed by a call to a register pretty-printers with
|
|
|
|
|
the current objfile.
|
|
|
|
|
|
|
|
|
|
Taken as a whole, this approach will scale nicely to multiple
|
|
|
|
|
inferiors, each potentially using a different library version.
|
|
|
|
|
Embedding a version number in the Python package name will ensure that
|
|
|
|
|
@value{GDBN} is able to load both sets of printers simultaneously.
|
|
|
|
|
Then, because the search for pretty-printers is done by objfile, and
|
|
|
|
|
because your auto-loaded code took care to register your library's
|
|
|
|
|
printers with a specific objfile, @value{GDBN} will find the correct
|
|
|
|
|
printers for the specific version of the library used by each
|
|
|
|
|
inferior.
|
|
|
|
|
|
|
|
|
|
To continue the @code{std::string} example (@pxref{Pretty Printing API}),
|
|
|
|
|
this code might appear in @code{gdb.libstdcxx.v6}:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
def register_printers(objfile):
|
|
|
|
|
objfile.pretty_printers.append(str_lookup_function)
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
And then the corresponding contents of the auto-load file would be:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
import gdb.libstdcxx.v6
|
|
|
|
|
gdb.libstdcxx.v6.register_printers(gdb.current_objfile())
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The previous example illustrates a basic pretty-printer.
|
|
|
|
|
There are a few things that can be improved on.
|
|
|
|
|
The printer doesn't have a name, making it hard to identify in a
|
|
|
|
|
list of installed printers. The lookup function has a name, but
|
|
|
|
|
lookup functions can have arbitrary, even identical, names.
|
|
|
|
|
|
|
|
|
|
Second, the printer only handles one type, whereas a library typically has
|
|
|
|
|
several types. One could install a lookup function for each desired type
|
|
|
|
|
in the library, but one could also have a single lookup function recognize
|
|
|
|
|
several types. The latter is the conventional way this is handled.
|
|
|
|
|
If a pretty-printer can handle multiple data types, then its
|
|
|
|
|
@dfn{subprinters} are the printers for the individual data types.
|
|
|
|
|
|
|
|
|
|
The @code{gdb.printing} module provides a formal way of solving these
|
|
|
|
|
problems (@pxref{gdb.printing}).
|
|
|
|
|
Here is another example that handles multiple types.
|
|
|
|
|
|
|
|
|
|
These are the types we are going to pretty-print:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
struct foo @{ int a, b; @};
|
|
|
|
|
struct bar @{ struct foo x, y; @};
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Here are the printers:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
2023-09-07 13:40:29 -06:00
|
|
|
class fooPrinter(gdb.ValuePrinter):
|
2014-02-17 10:35:03 -08:00
|
|
|
"""Print a foo object."""
|
|
|
|
|
|
|
|
|
|
def __init__(self, val):
|
2023-09-07 13:40:29 -06:00
|
|
|
self.__val = val
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
def to_string(self):
|
2023-09-07 13:40:29 -06:00
|
|
|
return ("a=<" + str(self.__val["a"]) +
|
|
|
|
|
"> b=<" + str(self.__val["b"]) + ">")
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2023-09-07 13:40:29 -06:00
|
|
|
class barPrinter(gdb.ValuePrinter):
|
2014-02-17 10:35:03 -08:00
|
|
|
"""Print a bar object."""
|
|
|
|
|
|
|
|
|
|
def __init__(self, val):
|
2023-09-07 13:40:29 -06:00
|
|
|
self.__val = val
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
def to_string(self):
|
2023-09-07 13:40:29 -06:00
|
|
|
return ("x=<" + str(self.__val["x"]) +
|
|
|
|
|
"> y=<" + str(self.__val["y"]) + ">")
|
2014-02-17 10:35:03 -08:00
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
This example doesn't need a lookup function, that is handled by the
|
|
|
|
|
@code{gdb.printing} module. Instead a function is provided to build up
|
|
|
|
|
the object that handles the lookup.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
import gdb.printing
|
|
|
|
|
|
|
|
|
|
def build_pretty_printer():
|
|
|
|
|
pp = gdb.printing.RegexpCollectionPrettyPrinter(
|
|
|
|
|
"my_library")
|
|
|
|
|
pp.add_printer('foo', '^foo$', fooPrinter)
|
|
|
|
|
pp.add_printer('bar', '^bar$', barPrinter)
|
|
|
|
|
return pp
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
And here is the autoload support:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
import gdb.printing
|
|
|
|
|
import my_library
|
|
|
|
|
gdb.printing.register_pretty_printer(
|
|
|
|
|
gdb.current_objfile(),
|
|
|
|
|
my_library.build_pretty_printer())
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Finally, when this printer is loaded into @value{GDBN}, here is the
|
|
|
|
|
corresponding output of @samp{info pretty-printer}:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(gdb) info pretty-printer
|
|
|
|
|
my_library.so:
|
|
|
|
|
my_library
|
|
|
|
|
foo
|
|
|
|
|
bar
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@node Type Printing API
|
|
|
|
|
@subsubsection Type Printing API
|
|
|
|
|
@cindex type printing API for Python
|
|
|
|
|
|
|
|
|
|
@value{GDBN} provides a way for Python code to customize type display.
|
|
|
|
|
This is mainly useful for substituting canonical typedef names for
|
|
|
|
|
types.
|
|
|
|
|
|
|
|
|
|
@cindex type printer
|
|
|
|
|
A @dfn{type printer} is just a Python object conforming to a certain
|
|
|
|
|
protocol. A simple base class implementing the protocol is provided;
|
|
|
|
|
see @ref{gdb.types}. A type printer must supply at least:
|
|
|
|
|
|
|
|
|
|
@defivar type_printer enabled
|
|
|
|
|
A boolean which is True if the printer is enabled, and False
|
|
|
|
|
otherwise. This is manipulated by the @code{enable type-printer}
|
|
|
|
|
and @code{disable type-printer} commands.
|
|
|
|
|
@end defivar
|
|
|
|
|
|
|
|
|
|
@defivar type_printer name
|
|
|
|
|
The name of the type printer. This must be a string. This is used by
|
|
|
|
|
the @code{enable type-printer} and @code{disable type-printer}
|
|
|
|
|
commands.
|
|
|
|
|
@end defivar
|
|
|
|
|
|
|
|
|
|
@defmethod type_printer instantiate (self)
|
|
|
|
|
This is called by @value{GDBN} at the start of type-printing. It is
|
|
|
|
|
only called if the type printer is enabled. This method must return a
|
|
|
|
|
new object that supplies a @code{recognize} method, as described below.
|
|
|
|
|
@end defmethod
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When displaying a type, say via the @code{ptype} command, @value{GDBN}
|
|
|
|
|
will compute a list of type recognizers. This is done by iterating
|
|
|
|
|
first over the per-objfile type printers (@pxref{Objfiles In Python}),
|
|
|
|
|
followed by the per-progspace type printers (@pxref{Progspaces In
|
|
|
|
|
Python}), and finally the global type printers.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} will call the @code{instantiate} method of each enabled
|
|
|
|
|
type printer. If this method returns @code{None}, then the result is
|
|
|
|
|
ignored; otherwise, it is appended to the list of recognizers.
|
|
|
|
|
|
|
|
|
|
Then, when @value{GDBN} is going to display a type name, it iterates
|
|
|
|
|
over the list of recognizers. For each one, it calls the recognition
|
|
|
|
|
function, stopping if the function returns a non-@code{None} value.
|
|
|
|
|
The recognition function is defined as:
|
|
|
|
|
|
|
|
|
|
@defmethod type_recognizer recognize (self, type)
|
|
|
|
|
If @var{type} is not recognized, return @code{None}. Otherwise,
|
|
|
|
|
return a string which is to be printed as the name of @var{type}.
|
Don't use @var at the beginning of a sentence in GDB documentation.
gdb/doc/guile.texi (Types In Guile, Basic Guile, Frames In Guile)
(Breakpoints In Guile, Guile Printing Module)
(Guile Exception Handling, Values From Inferior In Guile)
(Objfiles In Guile, Breakpoints In Guile, Memory Ports in Guile):
Don't use @var at the beginning of a sentence.
gdb/doc/gdb.texinfo (Frame Filter Management, Trace Files)
(C Operators, Ada Tasks, Calling, Bootstrapping, ARM)
(PowerPC Embedded, Define, Annotations for Running)
(IPA Protocol Commands, Packets, General Query Packets)
(Tracepoint Packets, Notification Packets, Environment)
(Inferiors and Programs, Set Breaks, Set Catchpoints)
(Continuing and Stepping, Signals, Thread-Specific Breakpoints)
(Frames, Backtrace, Selection, Expressions, Registers)
(Trace State Variables, Built-In Func/Proc, Signaling, Files)
(Numbers, GDB/MI Async Records, GDB/MI Data Manipulation)
(Source Annotations, Using JIT Debug Info Readers, Packets)
(Stop Reply Packets, Host I/O Packets)
(Target Description Format): Don't use @var at the beginning of a
sentence.
gdb/doc/python.texi (Basic Python, Types In Python)
(Commands In Python, Frames In Python, Line Tables In Python)
(Breakpoints In Python, gdb.printing, gdb.types)
(Type Printing API): Don't use @var at the beginning of a
sentence.
2014-05-24 13:02:42 +03:00
|
|
|
The @var{type} argument will be an instance of @code{gdb.Type}
|
|
|
|
|
(@pxref{Types In Python}).
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defmethod
|
|
|
|
|
|
|
|
|
|
@value{GDBN} uses this two-pass approach so that type printers can
|
|
|
|
|
efficiently cache information without holding on to it too long. For
|
|
|
|
|
example, it can be convenient to look up type information in a type
|
|
|
|
|
printer and hold it for a recognizer's lifetime; if a single pass were
|
|
|
|
|
done then type printers would have to make use of the event system in
|
|
|
|
|
order to avoid holding information that could become stale as the
|
|
|
|
|
inferior changed.
|
|
|
|
|
|
|
|
|
|
@node Frame Filter API
|
2018-09-08 10:16:46 -06:00
|
|
|
@subsubsection Filtering Frames
|
2014-02-17 10:35:03 -08:00
|
|
|
@cindex frame filters api
|
|
|
|
|
|
|
|
|
|
Frame filters are Python objects that manipulate the visibility of a
|
|
|
|
|
frame or frames when a backtrace (@pxref{Backtrace}) is printed by
|
|
|
|
|
@value{GDBN}.
|
|
|
|
|
|
|
|
|
|
Only commands that print a backtrace, or, in the case of @sc{gdb/mi}
|
|
|
|
|
commands (@pxref{GDB/MI}), those that return a collection of frames
|
|
|
|
|
are affected. The commands that work with frame filters are:
|
|
|
|
|
|
|
|
|
|
@code{backtrace} (@pxref{backtrace-command,, The backtrace command}),
|
|
|
|
|
@code{-stack-list-frames}
|
|
|
|
|
(@pxref{-stack-list-frames,, The -stack-list-frames command}),
|
|
|
|
|
@code{-stack-list-variables} (@pxref{-stack-list-variables,, The
|
|
|
|
|
-stack-list-variables command}), @code{-stack-list-arguments}
|
|
|
|
|
@pxref{-stack-list-arguments,, The -stack-list-arguments command}) and
|
|
|
|
|
@code{-stack-list-locals} (@pxref{-stack-list-locals,, The
|
|
|
|
|
-stack-list-locals command}).
|
|
|
|
|
|
|
|
|
|
A frame filter works by taking an iterator as an argument, applying
|
|
|
|
|
actions to the contents of that iterator, and returning another
|
|
|
|
|
iterator (or, possibly, the same iterator it was provided in the case
|
|
|
|
|
where the filter does not perform any operations). Typically, frame
|
|
|
|
|
filters utilize tools such as the Python's @code{itertools} module to
|
|
|
|
|
work with and create new iterators from the source iterator.
|
|
|
|
|
Regardless of how a filter chooses to apply actions, it must not alter
|
|
|
|
|
the underlying @value{GDBN} frame or frames, or attempt to alter the
|
|
|
|
|
call-stack within @value{GDBN}. This preserves data integrity within
|
|
|
|
|
@value{GDBN}. Frame filters are executed on a priority basis and care
|
|
|
|
|
should be taken that some frame filters may have been executed before,
|
|
|
|
|
and that some frame filters will be executed after.
|
|
|
|
|
|
|
|
|
|
An important consideration when designing frame filters, and well
|
|
|
|
|
worth reflecting upon, is that frame filters should avoid unwinding
|
|
|
|
|
the call stack if possible. Some stacks can run very deep, into the
|
|
|
|
|
tens of thousands in some cases. To search every frame when a frame
|
|
|
|
|
filter executes may be too expensive at that step. The frame filter
|
|
|
|
|
cannot know how many frames it has to iterate over, and it may have to
|
|
|
|
|
iterate through them all. This ends up duplicating effort as
|
|
|
|
|
@value{GDBN} performs this iteration when it prints the frames. If
|
|
|
|
|
the filter can defer unwinding frames until frame decorators are
|
|
|
|
|
executed, after the last filter has executed, it should. @xref{Frame
|
|
|
|
|
Decorator API}, for more information on decorators. Also, there are
|
|
|
|
|
examples for both frame decorators and filters in later chapters.
|
|
|
|
|
@xref{Writing a Frame Filter}, for more information.
|
|
|
|
|
|
|
|
|
|
The Python dictionary @code{gdb.frame_filters} contains key/object
|
|
|
|
|
pairings that comprise a frame filter. Frame filters in this
|
|
|
|
|
dictionary are called @code{global} frame filters, and they are
|
|
|
|
|
available when debugging all inferiors. These frame filters must
|
|
|
|
|
register with the dictionary directly. In addition to the
|
|
|
|
|
@code{global} dictionary, there are other dictionaries that are loaded
|
|
|
|
|
with different inferiors via auto-loading (@pxref{Python
|
|
|
|
|
Auto-loading}). The two other areas where frame filter dictionaries
|
|
|
|
|
can be found are: @code{gdb.Progspace} which contains a
|
|
|
|
|
@code{frame_filters} dictionary attribute, and each @code{gdb.Objfile}
|
|
|
|
|
object which also contains a @code{frame_filters} dictionary
|
|
|
|
|
attribute.
|
|
|
|
|
|
|
|
|
|
When a command is executed from @value{GDBN} that is compatible with
|
|
|
|
|
frame filters, @value{GDBN} combines the @code{global},
|
|
|
|
|
@code{gdb.Progspace} and all @code{gdb.Objfile} dictionaries currently
|
|
|
|
|
loaded. All of the @code{gdb.Objfile} dictionaries are combined, as
|
|
|
|
|
several frames, and thus several object files, might be in use.
|
|
|
|
|
@value{GDBN} then prunes any frame filter whose @code{enabled}
|
|
|
|
|
attribute is @code{False}. This pruned list is then sorted according
|
|
|
|
|
to the @code{priority} attribute in each filter.
|
|
|
|
|
|
|
|
|
|
Once the dictionaries are combined, pruned and sorted, @value{GDBN}
|
|
|
|
|
creates an iterator which wraps each frame in the call stack in a
|
|
|
|
|
@code{FrameDecorator} object, and calls each filter in order. The
|
|
|
|
|
output from the previous filter will always be the input to the next
|
|
|
|
|
filter, and so on.
|
|
|
|
|
|
|
|
|
|
Frame filters have a mandatory interface which each frame filter must
|
|
|
|
|
implement, defined here:
|
|
|
|
|
|
|
|
|
|
@defun FrameFilter.filter (iterator)
|
|
|
|
|
@value{GDBN} will call this method on a frame filter when it has
|
|
|
|
|
reached the order in the priority list for that filter.
|
|
|
|
|
|
|
|
|
|
For example, if there are four frame filters:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
Name Priority
|
|
|
|
|
|
|
|
|
|
Filter1 5
|
|
|
|
|
Filter2 10
|
|
|
|
|
Filter3 100
|
|
|
|
|
Filter4 1
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The order that the frame filters will be called is:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
Filter3 -> Filter2 -> Filter1 -> Filter4
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Note that the output from @code{Filter3} is passed to the input of
|
|
|
|
|
@code{Filter2}, and so on.
|
|
|
|
|
|
|
|
|
|
This @code{filter} method is passed a Python iterator. This iterator
|
|
|
|
|
contains a sequence of frame decorators that wrap each
|
|
|
|
|
@code{gdb.Frame}, or a frame decorator that wraps another frame
|
|
|
|
|
decorator. The first filter that is executed in the sequence of frame
|
|
|
|
|
filters will receive an iterator entirely comprised of default
|
|
|
|
|
@code{FrameDecorator} objects. However, after each frame filter is
|
|
|
|
|
executed, the previous frame filter may have wrapped some or all of
|
|
|
|
|
the frame decorators with their own frame decorator. As frame
|
|
|
|
|
decorators must also conform to a mandatory interface, these
|
|
|
|
|
decorators can be assumed to act in a uniform manner (@pxref{Frame
|
|
|
|
|
Decorator API}).
|
|
|
|
|
|
|
|
|
|
This method must return an object conforming to the Python iterator
|
|
|
|
|
protocol. Each item in the iterator must be an object conforming to
|
|
|
|
|
the frame decorator interface. If a frame filter does not wish to
|
|
|
|
|
perform any operations on this iterator, it should return that
|
|
|
|
|
iterator untouched.
|
|
|
|
|
|
|
|
|
|
This method is not optional. If it does not exist, @value{GDBN} will
|
|
|
|
|
raise and print an error.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defvar FrameFilter.name
|
|
|
|
|
The @code{name} attribute must be Python string which contains the
|
|
|
|
|
name of the filter displayed by @value{GDBN} (@pxref{Frame Filter
|
|
|
|
|
Management}). This attribute may contain any combination of letters
|
|
|
|
|
or numbers. Care should be taken to ensure that it is unique. This
|
|
|
|
|
attribute is mandatory.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar FrameFilter.enabled
|
|
|
|
|
The @code{enabled} attribute must be Python boolean. This attribute
|
|
|
|
|
indicates to @value{GDBN} whether the frame filter is enabled, and
|
|
|
|
|
should be considered when frame filters are executed. If
|
|
|
|
|
@code{enabled} is @code{True}, then the frame filter will be executed
|
|
|
|
|
when any of the backtrace commands detailed earlier in this chapter
|
|
|
|
|
are executed. If @code{enabled} is @code{False}, then the frame
|
|
|
|
|
filter will not be executed. This attribute is mandatory.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar FrameFilter.priority
|
|
|
|
|
The @code{priority} attribute must be Python integer. This attribute
|
|
|
|
|
controls the order of execution in relation to other frame filters.
|
|
|
|
|
There are no imposed limits on the range of @code{priority} other than
|
|
|
|
|
it must be a valid integer. The higher the @code{priority} attribute,
|
|
|
|
|
the sooner the frame filter will be executed in relation to other
|
|
|
|
|
frame filters. Although @code{priority} can be negative, it is
|
|
|
|
|
recommended practice to assume zero is the lowest priority that a
|
|
|
|
|
frame filter can be assigned. Frame filters that have the same
|
|
|
|
|
priority are executed in unsorted order in that priority slot. This
|
2018-09-08 10:16:46 -06:00
|
|
|
attribute is mandatory. 100 is a good default priority.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@node Frame Decorator API
|
2018-09-08 10:16:46 -06:00
|
|
|
@subsubsection Decorating Frames
|
2014-02-17 10:35:03 -08:00
|
|
|
@cindex frame decorator api
|
|
|
|
|
|
|
|
|
|
Frame decorators are sister objects to frame filters (@pxref{Frame
|
|
|
|
|
Filter API}). Frame decorators are applied by a frame filter and can
|
|
|
|
|
only be used in conjunction with frame filters.
|
|
|
|
|
|
|
|
|
|
The purpose of a frame decorator is to customize the printed content
|
|
|
|
|
of each @code{gdb.Frame} in commands where frame filters are executed.
|
|
|
|
|
This concept is called decorating a frame. Frame decorators decorate
|
|
|
|
|
a @code{gdb.Frame} with Python code contained within each API call.
|
|
|
|
|
This separates the actual data contained in a @code{gdb.Frame} from
|
|
|
|
|
the decorated data produced by a frame decorator. This abstraction is
|
|
|
|
|
necessary to maintain integrity of the data contained in each
|
|
|
|
|
@code{gdb.Frame}.
|
|
|
|
|
|
|
|
|
|
Frame decorators have a mandatory interface, defined below.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} already contains a frame decorator called
|
|
|
|
|
@code{FrameDecorator}. This contains substantial amounts of
|
|
|
|
|
boilerplate code to decorate the content of a @code{gdb.Frame}. It is
|
|
|
|
|
recommended that other frame decorators inherit and extend this
|
|
|
|
|
object, and only to override the methods needed.
|
|
|
|
|
|
2018-09-08 10:16:46 -06:00
|
|
|
@tindex gdb.FrameDecorator
|
|
|
|
|
@code{FrameDecorator} is defined in the Python module
|
|
|
|
|
@code{gdb.FrameDecorator}, so your code can import it like:
|
|
|
|
|
@smallexample
|
|
|
|
|
from gdb.FrameDecorator import FrameDecorator
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun FrameDecorator.elided (self)
|
|
|
|
|
|
|
|
|
|
The @code{elided} method groups frames together in a hierarchical
|
|
|
|
|
system. An example would be an interpreter, where multiple low-level
|
|
|
|
|
frames make up a single call in the interpreted language. In this
|
|
|
|
|
example, the frame filter would elide the low-level frames and present
|
|
|
|
|
a single high-level frame, representing the call in the interpreted
|
|
|
|
|
language, to the user.
|
|
|
|
|
|
|
|
|
|
The @code{elided} function must return an iterable and this iterable
|
|
|
|
|
must contain the frames that are being elided wrapped in a suitable
|
|
|
|
|
frame decorator. If no frames are being elided this function may
|
|
|
|
|
return an empty iterable, or @code{None}. Elided frames are indented
|
|
|
|
|
from normal frames in a @code{CLI} backtrace, or in the case of
|
2023-05-18 12:15:59 -06:00
|
|
|
@sc{gdb/mi}, are placed in the @code{children} field of the eliding
|
2014-02-17 10:35:03 -08:00
|
|
|
frame.
|
|
|
|
|
|
|
|
|
|
It is the frame filter's task to also filter out the elided frames from
|
|
|
|
|
the source iterator. This will avoid printing the frame twice.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun FrameDecorator.function (self)
|
|
|
|
|
|
|
|
|
|
This method returns the name of the function in the frame that is to
|
|
|
|
|
be printed.
|
|
|
|
|
|
|
|
|
|
This method must return a Python string describing the function, or
|
|
|
|
|
@code{None}.
|
|
|
|
|
|
|
|
|
|
If this function returns @code{None}, @value{GDBN} will not print any
|
|
|
|
|
data for this field.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun FrameDecorator.address (self)
|
|
|
|
|
|
|
|
|
|
This method returns the address of the frame that is to be printed.
|
|
|
|
|
|
|
|
|
|
This method must return a Python numeric integer type of sufficient
|
|
|
|
|
size to describe the address of the frame, or @code{None}.
|
|
|
|
|
|
|
|
|
|
If this function returns a @code{None}, @value{GDBN} will not print
|
|
|
|
|
any data for this field.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun FrameDecorator.filename (self)
|
|
|
|
|
|
|
|
|
|
This method returns the filename and path associated with this frame.
|
|
|
|
|
|
|
|
|
|
This method must return a Python string containing the filename and
|
|
|
|
|
the path to the object file backing the frame, or @code{None}.
|
|
|
|
|
|
|
|
|
|
If this function returns a @code{None}, @value{GDBN} will not print
|
|
|
|
|
any data for this field.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun FrameDecorator.line (self):
|
|
|
|
|
|
|
|
|
|
This method returns the line number associated with the current
|
|
|
|
|
position within the function addressed by this frame.
|
|
|
|
|
|
|
|
|
|
This method must return a Python integer type, or @code{None}.
|
|
|
|
|
|
|
|
|
|
If this function returns a @code{None}, @value{GDBN} will not print
|
|
|
|
|
any data for this field.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun FrameDecorator.frame_args (self)
|
|
|
|
|
@anchor{frame_args}
|
|
|
|
|
|
|
|
|
|
This method must return an iterable, or @code{None}. Returning an
|
|
|
|
|
empty iterable, or @code{None} means frame arguments will not be
|
|
|
|
|
printed for this frame. This iterable must contain objects that
|
|
|
|
|
implement two methods, described here.
|
|
|
|
|
|
2020-12-29 17:18:22 +01:00
|
|
|
This object must implement a @code{symbol} method which takes a
|
2014-02-17 10:35:03 -08:00
|
|
|
single @code{self} parameter and must return a @code{gdb.Symbol}
|
|
|
|
|
(@pxref{Symbols In Python}), or a Python string. The object must also
|
|
|
|
|
implement a @code{value} method which takes a single @code{self}
|
|
|
|
|
parameter and must return a @code{gdb.Value} (@pxref{Values From
|
|
|
|
|
Inferior}), a Python value, or @code{None}. If the @code{value}
|
|
|
|
|
method returns @code{None}, and the @code{argument} method returns a
|
|
|
|
|
@code{gdb.Symbol}, @value{GDBN} will look-up and print the value of
|
|
|
|
|
the @code{gdb.Symbol} automatically.
|
|
|
|
|
|
|
|
|
|
A brief example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class SymValueWrapper():
|
|
|
|
|
|
|
|
|
|
def __init__(self, symbol, value):
|
|
|
|
|
self.sym = symbol
|
|
|
|
|
self.val = value
|
|
|
|
|
|
|
|
|
|
def value(self):
|
|
|
|
|
return self.val
|
|
|
|
|
|
|
|
|
|
def symbol(self):
|
|
|
|
|
return self.sym
|
|
|
|
|
|
|
|
|
|
class SomeFrameDecorator()
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
def frame_args(self):
|
|
|
|
|
args = []
|
|
|
|
|
try:
|
|
|
|
|
block = self.inferior_frame.block()
|
|
|
|
|
except:
|
|
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
# Iterate over all symbols in a block. Only add
|
|
|
|
|
# symbols that are arguments.
|
|
|
|
|
for sym in block:
|
|
|
|
|
if not sym.is_argument:
|
|
|
|
|
continue
|
|
|
|
|
args.append(SymValueWrapper(sym,None))
|
|
|
|
|
|
|
|
|
|
# Add example synthetic argument.
|
|
|
|
|
args.append(SymValueWrapper(``foo'', 42))
|
|
|
|
|
|
|
|
|
|
return args
|
|
|
|
|
@end smallexample
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun FrameDecorator.frame_locals (self)
|
|
|
|
|
|
|
|
|
|
This method must return an iterable or @code{None}. Returning an
|
|
|
|
|
empty iterable, or @code{None} means frame local arguments will not be
|
|
|
|
|
printed for this frame.
|
|
|
|
|
|
|
|
|
|
The object interface, the description of the various strategies for
|
|
|
|
|
reading frame locals, and the example are largely similar to those
|
|
|
|
|
described in the @code{frame_args} function, (@pxref{frame_args,,The
|
|
|
|
|
frame filter frame_args function}). Below is a modified example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class SomeFrameDecorator()
|
|
|
|
|
...
|
|
|
|
|
...
|
|
|
|
|
def frame_locals(self):
|
|
|
|
|
vars = []
|
|
|
|
|
try:
|
|
|
|
|
block = self.inferior_frame.block()
|
|
|
|
|
except:
|
|
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
# Iterate over all symbols in a block. Add all
|
|
|
|
|
# symbols, except arguments.
|
|
|
|
|
for sym in block:
|
|
|
|
|
if sym.is_argument:
|
|
|
|
|
continue
|
|
|
|
|
vars.append(SymValueWrapper(sym,None))
|
|
|
|
|
|
|
|
|
|
# Add an example of a synthetic local variable.
|
|
|
|
|
vars.append(SymValueWrapper(``bar'', 99))
|
|
|
|
|
|
|
|
|
|
return vars
|
|
|
|
|
@end smallexample
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun FrameDecorator.inferior_frame (self):
|
|
|
|
|
|
|
|
|
|
This method must return the underlying @code{gdb.Frame} that this
|
|
|
|
|
frame decorator is decorating. @value{GDBN} requires the underlying
|
|
|
|
|
frame for internal frame information to determine how to print certain
|
|
|
|
|
values when printing a frame.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@node Writing a Frame Filter
|
|
|
|
|
@subsubsection Writing a Frame Filter
|
|
|
|
|
@cindex writing a frame filter
|
|
|
|
|
|
|
|
|
|
There are three basic elements that a frame filter must implement: it
|
|
|
|
|
must correctly implement the documented interface (@pxref{Frame Filter
|
|
|
|
|
API}), it must register itself with @value{GDBN}, and finally, it must
|
|
|
|
|
decide if it is to work on the data provided by @value{GDBN}. In all
|
|
|
|
|
cases, whether it works on the iterator or not, each frame filter must
|
|
|
|
|
return an iterator. A bare-bones frame filter follows the pattern in
|
|
|
|
|
the following example.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
import gdb
|
|
|
|
|
|
|
|
|
|
class FrameFilter():
|
|
|
|
|
|
|
|
|
|
def __init__(self):
|
|
|
|
|
# Frame filter attribute creation.
|
|
|
|
|
#
|
|
|
|
|
# 'name' is the name of the filter that GDB will display.
|
|
|
|
|
#
|
|
|
|
|
# 'priority' is the priority of the filter relative to other
|
|
|
|
|
# filters.
|
|
|
|
|
#
|
|
|
|
|
# 'enabled' is a boolean that indicates whether this filter is
|
|
|
|
|
# enabled and should be executed.
|
|
|
|
|
|
|
|
|
|
self.name = "Foo"
|
|
|
|
|
self.priority = 100
|
|
|
|
|
self.enabled = True
|
|
|
|
|
|
|
|
|
|
# Register this frame filter with the global frame_filters
|
|
|
|
|
# dictionary.
|
|
|
|
|
gdb.frame_filters[self.name] = self
|
|
|
|
|
|
|
|
|
|
def filter(self, frame_iter):
|
|
|
|
|
# Just return the iterator.
|
|
|
|
|
return frame_iter
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The frame filter in the example above implements the three
|
|
|
|
|
requirements for all frame filters. It implements the API, self
|
|
|
|
|
registers, and makes a decision on the iterator (in this case, it just
|
|
|
|
|
returns the iterator untouched).
|
|
|
|
|
|
|
|
|
|
The first step is attribute creation and assignment, and as shown in
|
|
|
|
|
the comments the filter assigns the following attributes: @code{name},
|
|
|
|
|
@code{priority} and whether the filter should be enabled with the
|
|
|
|
|
@code{enabled} attribute.
|
|
|
|
|
|
|
|
|
|
The second step is registering the frame filter with the dictionary or
|
|
|
|
|
dictionaries that the frame filter has interest in. As shown in the
|
|
|
|
|
comments, this filter just registers itself with the global dictionary
|
|
|
|
|
@code{gdb.frame_filters}. As noted earlier, @code{gdb.frame_filters}
|
|
|
|
|
is a dictionary that is initialized in the @code{gdb} module when
|
|
|
|
|
@value{GDBN} starts. What dictionary a filter registers with is an
|
|
|
|
|
important consideration. Generally, if a filter is specific to a set
|
|
|
|
|
of code, it should be registered either in the @code{objfile} or
|
|
|
|
|
@code{progspace} dictionaries as they are specific to the program
|
|
|
|
|
currently loaded in @value{GDBN}. The global dictionary is always
|
|
|
|
|
present in @value{GDBN} and is never unloaded. Any filters registered
|
|
|
|
|
with the global dictionary will exist until @value{GDBN} exits. To
|
|
|
|
|
avoid filters that may conflict, it is generally better to register
|
|
|
|
|
frame filters against the dictionaries that more closely align with
|
|
|
|
|
the usage of the filter currently in question. @xref{Python
|
|
|
|
|
Auto-loading}, for further information on auto-loading Python scripts.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} takes a hands-off approach to frame filter registration,
|
|
|
|
|
therefore it is the frame filter's responsibility to ensure
|
|
|
|
|
registration has occurred, and that any exceptions are handled
|
|
|
|
|
appropriately. In particular, you may wish to handle exceptions
|
|
|
|
|
relating to Python dictionary key uniqueness. It is mandatory that
|
|
|
|
|
the dictionary key is the same as frame filter's @code{name}
|
|
|
|
|
attribute. When a user manages frame filters (@pxref{Frame Filter
|
|
|
|
|
Management}), the names @value{GDBN} will display are those contained
|
|
|
|
|
in the @code{name} attribute.
|
|
|
|
|
|
|
|
|
|
The final step of this example is the implementation of the
|
|
|
|
|
@code{filter} method. As shown in the example comments, we define the
|
|
|
|
|
@code{filter} method and note that the method must take an iterator,
|
|
|
|
|
and also must return an iterator. In this bare-bones example, the
|
|
|
|
|
frame filter is not very useful as it just returns the iterator
|
|
|
|
|
untouched. However this is a valid operation for frame filters that
|
|
|
|
|
have the @code{enabled} attribute set, but decide not to operate on
|
|
|
|
|
any frames.
|
|
|
|
|
|
|
|
|
|
In the next example, the frame filter operates on all frames and
|
|
|
|
|
utilizes a frame decorator to perform some work on the frames.
|
|
|
|
|
@xref{Frame Decorator API}, for further information on the frame
|
|
|
|
|
decorator interface.
|
|
|
|
|
|
|
|
|
|
This example works on inlined frames. It highlights frames which are
|
|
|
|
|
inlined by tagging them with an ``[inlined]'' tag. By applying a
|
|
|
|
|
frame decorator to all frames with the Python @code{itertools imap}
|
|
|
|
|
method, the example defers actions to the frame decorator. Frame
|
|
|
|
|
decorators are only processed when @value{GDBN} prints the backtrace.
|
|
|
|
|
|
|
|
|
|
This introduces a new decision making topic: whether to perform
|
|
|
|
|
decision making operations at the filtering step, or at the printing
|
|
|
|
|
step. In this example's approach, it does not perform any filtering
|
|
|
|
|
decisions at the filtering step beyond mapping a frame decorator to
|
|
|
|
|
each frame. This allows the actual decision making to be performed
|
|
|
|
|
when each frame is printed. This is an important consideration, and
|
|
|
|
|
well worth reflecting upon when designing a frame filter. An issue
|
|
|
|
|
that frame filters should avoid is unwinding the stack if possible.
|
|
|
|
|
Some stacks can run very deep, into the tens of thousands in some
|
|
|
|
|
cases. To search every frame to determine if it is inlined ahead of
|
|
|
|
|
time may be too expensive at the filtering step. The frame filter
|
|
|
|
|
cannot know how many frames it has to iterate over, and it would have
|
|
|
|
|
to iterate through them all. This ends up duplicating effort as
|
|
|
|
|
@value{GDBN} performs this iteration when it prints the frames.
|
|
|
|
|
|
|
|
|
|
In this example decision making can be deferred to the printing step.
|
|
|
|
|
As each frame is printed, the frame decorator can examine each frame
|
|
|
|
|
in turn when @value{GDBN} iterates. From a performance viewpoint,
|
|
|
|
|
this is the most appropriate decision to make as it avoids duplicating
|
|
|
|
|
the effort that the printing step would undertake anyway. Also, if
|
|
|
|
|
there are many frame filters unwinding the stack during filtering, it
|
|
|
|
|
can substantially delay the printing of the backtrace which will
|
|
|
|
|
result in large memory usage, and a poor user experience.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class InlineFilter():
|
|
|
|
|
|
|
|
|
|
def __init__(self):
|
|
|
|
|
self.name = "InlinedFrameFilter"
|
|
|
|
|
self.priority = 100
|
|
|
|
|
self.enabled = True
|
|
|
|
|
gdb.frame_filters[self.name] = self
|
|
|
|
|
|
|
|
|
|
def filter(self, frame_iter):
|
|
|
|
|
frame_iter = itertools.imap(InlinedFrameDecorator,
|
|
|
|
|
frame_iter)
|
|
|
|
|
return frame_iter
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
This frame filter is somewhat similar to the earlier example, except
|
|
|
|
|
that the @code{filter} method applies a frame decorator object called
|
|
|
|
|
@code{InlinedFrameDecorator} to each element in the iterator. The
|
|
|
|
|
@code{imap} Python method is light-weight. It does not proactively
|
|
|
|
|
iterate over the iterator, but rather creates a new iterator which
|
|
|
|
|
wraps the existing one.
|
|
|
|
|
|
|
|
|
|
Below is the frame decorator for this example.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class InlinedFrameDecorator(FrameDecorator):
|
|
|
|
|
|
|
|
|
|
def __init__(self, fobj):
|
|
|
|
|
super(InlinedFrameDecorator, self).__init__(fobj)
|
|
|
|
|
|
|
|
|
|
def function(self):
|
2021-05-26 18:26:33 +02:00
|
|
|
frame = self.inferior_frame()
|
2014-02-17 10:35:03 -08:00
|
|
|
name = str(frame.name())
|
|
|
|
|
|
|
|
|
|
if frame.type() == gdb.INLINE_FRAME:
|
|
|
|
|
name = name + " [inlined]"
|
|
|
|
|
|
|
|
|
|
return name
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
This frame decorator only defines and overrides the @code{function}
|
|
|
|
|
method. It lets the supplied @code{FrameDecorator}, which is shipped
|
|
|
|
|
with @value{GDBN}, perform the other work associated with printing
|
|
|
|
|
this frame.
|
|
|
|
|
|
|
|
|
|
The combination of these two objects create this output from a
|
|
|
|
|
backtrace:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
#0 0x004004e0 in bar () at inline.c:11
|
|
|
|
|
#1 0x00400566 in max [inlined] (b=6, a=12) at inline.c:21
|
|
|
|
|
#2 0x00400566 in main () at inline.c:31
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
So in the case of this example, a frame decorator is applied to all
|
|
|
|
|
frames, regardless of whether they may be inlined or not. As
|
|
|
|
|
@value{GDBN} iterates over the iterator produced by the frame filters,
|
|
|
|
|
@value{GDBN} executes each frame decorator which then makes a decision
|
|
|
|
|
on what to print in the @code{function} callback. Using a strategy
|
|
|
|
|
like this is a way to defer decisions on the frame content to printing
|
|
|
|
|
time.
|
|
|
|
|
|
|
|
|
|
@subheading Eliding Frames
|
|
|
|
|
|
|
|
|
|
It might be that the above example is not desirable for representing
|
|
|
|
|
inlined frames, and a hierarchical approach may be preferred. If we
|
|
|
|
|
want to hierarchically represent frames, the @code{elided} frame
|
|
|
|
|
decorator interface might be preferable.
|
|
|
|
|
|
|
|
|
|
This example approaches the issue with the @code{elided} method. This
|
|
|
|
|
example is quite long, but very simplistic. It is out-of-scope for
|
|
|
|
|
this section to write a complete example that comprehensively covers
|
|
|
|
|
all approaches of finding and printing inlined frames. However, this
|
|
|
|
|
example illustrates the approach an author might use.
|
|
|
|
|
|
|
|
|
|
This example comprises of three sections.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class InlineFrameFilter():
|
|
|
|
|
|
|
|
|
|
def __init__(self):
|
|
|
|
|
self.name = "InlinedFrameFilter"
|
|
|
|
|
self.priority = 100
|
|
|
|
|
self.enabled = True
|
|
|
|
|
gdb.frame_filters[self.name] = self
|
|
|
|
|
|
|
|
|
|
def filter(self, frame_iter):
|
|
|
|
|
return ElidingInlineIterator(frame_iter)
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
This frame filter is very similar to the other examples. The only
|
|
|
|
|
difference is this frame filter is wrapping the iterator provided to
|
|
|
|
|
it (@code{frame_iter}) with a custom iterator called
|
|
|
|
|
@code{ElidingInlineIterator}. This again defers actions to when
|
|
|
|
|
@value{GDBN} prints the backtrace, as the iterator is not traversed
|
|
|
|
|
until printing.
|
|
|
|
|
|
|
|
|
|
The iterator for this example is as follows. It is in this section of
|
|
|
|
|
the example where decisions are made on the content of the backtrace.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class ElidingInlineIterator:
|
|
|
|
|
def __init__(self, ii):
|
|
|
|
|
self.input_iterator = ii
|
|
|
|
|
|
|
|
|
|
def __iter__(self):
|
|
|
|
|
return self
|
|
|
|
|
|
|
|
|
|
def next(self):
|
|
|
|
|
frame = next(self.input_iterator)
|
|
|
|
|
|
|
|
|
|
if frame.inferior_frame().type() != gdb.INLINE_FRAME:
|
|
|
|
|
return frame
|
|
|
|
|
|
|
|
|
|
try:
|
|
|
|
|
eliding_frame = next(self.input_iterator)
|
|
|
|
|
except StopIteration:
|
|
|
|
|
return frame
|
|
|
|
|
return ElidingFrameDecorator(eliding_frame, [frame])
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
This iterator implements the Python iterator protocol. When the
|
|
|
|
|
@code{next} function is called (when @value{GDBN} prints each frame),
|
|
|
|
|
the iterator checks if this frame decorator, @code{frame}, is wrapping
|
|
|
|
|
an inlined frame. If it is not, it returns the existing frame decorator
|
|
|
|
|
untouched. If it is wrapping an inlined frame, it assumes that the
|
|
|
|
|
inlined frame was contained within the next oldest frame,
|
|
|
|
|
@code{eliding_frame}, which it fetches. It then creates and returns a
|
|
|
|
|
frame decorator, @code{ElidingFrameDecorator}, which contains both the
|
|
|
|
|
elided frame, and the eliding frame.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class ElidingInlineDecorator(FrameDecorator):
|
|
|
|
|
|
|
|
|
|
def __init__(self, frame, elided_frames):
|
|
|
|
|
super(ElidingInlineDecorator, self).__init__(frame)
|
|
|
|
|
self.frame = frame
|
|
|
|
|
self.elided_frames = elided_frames
|
|
|
|
|
|
|
|
|
|
def elided(self):
|
|
|
|
|
return iter(self.elided_frames)
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
This frame decorator overrides one function and returns the inlined
|
|
|
|
|
frame in the @code{elided} method. As before it lets
|
|
|
|
|
@code{FrameDecorator} do the rest of the work involved in printing
|
|
|
|
|
this frame. This produces the following output.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
#0 0x004004e0 in bar () at inline.c:11
|
|
|
|
|
#2 0x00400529 in main () at inline.c:25
|
|
|
|
|
#1 0x00400529 in max (b=6, a=12) at inline.c:15
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
In that output, @code{max} which has been inlined into @code{main} is
|
|
|
|
|
printed hierarchically. Another approach would be to combine the
|
|
|
|
|
@code{function} method, and the @code{elided} method to both print a
|
|
|
|
|
marker in the inlined frame, and also show the hierarchical
|
|
|
|
|
relationship.
|
|
|
|
|
|
2015-04-01 11:49:12 -07:00
|
|
|
@node Unwinding Frames in Python
|
|
|
|
|
@subsubsection Unwinding Frames in Python
|
|
|
|
|
@cindex unwinding frames in Python
|
|
|
|
|
|
|
|
|
|
In @value{GDBN} terminology ``unwinding'' is the process of finding
|
|
|
|
|
the previous frame (that is, caller's) from the current one. An
|
|
|
|
|
unwinder has three methods. The first one checks if it can handle
|
|
|
|
|
given frame (``sniff'' it). For the frames it can sniff an unwinder
|
|
|
|
|
provides two additional methods: it can return frame's ID, and it can
|
|
|
|
|
fetch registers from the previous frame. A running @value{GDBN}
|
2024-02-08 20:31:51 +01:00
|
|
|
maintains a list of the unwinders and calls each unwinder's sniffer in
|
2015-04-01 11:49:12 -07:00
|
|
|
turn until it finds the one that recognizes the current frame. There
|
|
|
|
|
is an API to register an unwinder.
|
|
|
|
|
|
|
|
|
|
The unwinders that come with @value{GDBN} handle standard frames.
|
|
|
|
|
However, mixed language applications (for example, an application
|
|
|
|
|
running Java Virtual Machine) sometimes use frame layouts that cannot
|
|
|
|
|
be handled by the @value{GDBN} unwinders. You can write Python code
|
|
|
|
|
that can handle such custom frames.
|
|
|
|
|
|
|
|
|
|
You implement a frame unwinder in Python as a class with which has two
|
|
|
|
|
attributes, @code{name} and @code{enabled}, with obvious meanings, and
|
|
|
|
|
a single method @code{__call__}, which examines a given frame and
|
|
|
|
|
returns an object (an instance of @code{gdb.UnwindInfo class)}
|
|
|
|
|
describing it. If an unwinder does not recognize a frame, it should
|
|
|
|
|
return @code{None}. The code in @value{GDBN} that enables writing
|
|
|
|
|
unwinders in Python uses this object to return frame's ID and previous
|
|
|
|
|
frame registers when @value{GDBN} core asks for them.
|
|
|
|
|
|
2018-09-08 13:25:34 -06:00
|
|
|
An unwinder should do as little work as possible. Some otherwise
|
|
|
|
|
innocuous operations can cause problems (even crashes, as this code is
|
2023-12-10 15:26:46 -07:00
|
|
|
not well-hardened yet). For example, making an inferior call from
|
2018-09-08 13:25:34 -06:00
|
|
|
an unwinder is unadvisable, as an inferior call will reset
|
|
|
|
|
@value{GDBN}'s stack unwinding process, potentially causing re-entrant
|
|
|
|
|
unwinding.
|
|
|
|
|
|
2015-04-01 11:49:12 -07:00
|
|
|
@subheading Unwinder Input
|
|
|
|
|
|
|
|
|
|
An object passed to an unwinder (a @code{gdb.PendingFrame} instance)
|
|
|
|
|
provides a method to read frame's registers:
|
|
|
|
|
|
2023-03-14 11:43:14 +00:00
|
|
|
@defun PendingFrame.read_register (register)
|
|
|
|
|
This method returns the contents of @var{register} in the
|
gdb/python: make more use of RegisterDescriptors
This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.
Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number. I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind. However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.
Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.
This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.
The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly. However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.
As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.
After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.
gdb/ChangeLog:
* python/py-frame.c: Remove 'user-regs.h' include.
(frapy_read_register): Rewrite to make use of
gdbpy_parse_register_id.
* python/py-registers.c (gdbpy_parse_register_id): New function,
moved here from python/py-unwind.c. Updated the return type, and
also accepts register descriptor objects.
* python/py-unwind.c: Remove 'user-regs.h' include.
(pyuw_parse_register_id): Moved to python/py-registers.c.
(unwind_infopy_add_saved_register): Update to use
gdbpy_parse_register_id.
(pending_framepy_read_register): Likewise.
* python/python-internal.h (gdbpy_parse_register_id): Declare.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py: Update to make use of a register
descriptor.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Update descriptions
for PendingFrame.read_register and
gdb.UnwindInfo.add_saved_register.
(Frames In Python): Update description of Frame.read_register.
2020-07-22 12:13:11 +01:00
|
|
|
frame as a @code{gdb.Value} object. For a description of the
|
2023-03-14 11:43:14 +00:00
|
|
|
acceptable values of @var{register} see
|
|
|
|
|
@ref{gdbpy_frame_read_register,,Frame.read_register}. If @var{register}
|
gdb/python: make more use of RegisterDescriptors
This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.
Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number. I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind. However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.
Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.
This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.
The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly. However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.
As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.
After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.
gdb/ChangeLog:
* python/py-frame.c: Remove 'user-regs.h' include.
(frapy_read_register): Rewrite to make use of
gdbpy_parse_register_id.
* python/py-registers.c (gdbpy_parse_register_id): New function,
moved here from python/py-unwind.c. Updated the return type, and
also accepts register descriptor objects.
* python/py-unwind.c: Remove 'user-regs.h' include.
(pyuw_parse_register_id): Moved to python/py-registers.c.
(unwind_infopy_add_saved_register): Update to use
gdbpy_parse_register_id.
(pending_framepy_read_register): Likewise.
* python/python-internal.h (gdbpy_parse_register_id): Declare.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py: Update to make use of a register
descriptor.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Update descriptions
for PendingFrame.read_register and
gdb.UnwindInfo.add_saved_register.
(Frames In Python): Update description of Frame.read_register.
2020-07-22 12:13:11 +01:00
|
|
|
does not name a register for the current architecture, this method
|
|
|
|
|
will throw an exception.
|
2018-09-08 13:25:34 -06:00
|
|
|
|
|
|
|
|
Note that this method will always return a @code{gdb.Value} for a
|
|
|
|
|
valid register name. This does not mean that the value will be valid.
|
|
|
|
|
For example, you may request a register that an earlier unwinder could
|
|
|
|
|
not unwind---the value will be unavailable. Instead, the
|
|
|
|
|
@code{gdb.Value} returned from this method will be lazy; that is, its
|
|
|
|
|
underlying bits will not be fetched until it is first used. So,
|
|
|
|
|
attempting to use such a value will cause an exception at the point of
|
|
|
|
|
use.
|
|
|
|
|
|
|
|
|
|
The type of the returned @code{gdb.Value} depends on the register and
|
|
|
|
|
the architecture. It is common for registers to have a scalar type,
|
|
|
|
|
like @code{long long}; but many other types are possible, such as
|
|
|
|
|
pointer, pointer-to-function, floating point or vector types.
|
2015-04-01 11:49:12 -07:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
It also provides a factory method to create a @code{gdb.UnwindInfo}
|
|
|
|
|
instance to be returned to @value{GDBN}:
|
|
|
|
|
|
2023-03-10 12:29:58 +00:00
|
|
|
@anchor{gdb.PendingFrame.create_unwind_info}
|
2015-04-01 11:49:12 -07:00
|
|
|
@defun PendingFrame.create_unwind_info (frame_id)
|
|
|
|
|
Returns a new @code{gdb.UnwindInfo} instance identified by given
|
2023-03-08 15:26:32 +00:00
|
|
|
@var{frame_id}. The @var{frame_id} is used internally by @value{GDBN}
|
|
|
|
|
to identify the frames within the current thread's stack. The
|
|
|
|
|
attributes of @var{frame_id} determine what type of frame is
|
|
|
|
|
created within @value{GDBN}:
|
2015-04-01 11:49:12 -07:00
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@item sp, pc
|
2018-09-08 13:25:34 -06:00
|
|
|
The frame is identified by the given stack address and PC. The stack
|
|
|
|
|
address must be chosen so that it is constant throughout the lifetime
|
|
|
|
|
of the frame, so a typical choice is the value of the stack pointer at
|
|
|
|
|
the start of the function---in the DWARF standard, this would be the
|
|
|
|
|
``Call Frame Address''.
|
2015-04-01 11:49:12 -07:00
|
|
|
|
2018-09-08 13:25:34 -06:00
|
|
|
This is the most common case by far. The other cases are documented
|
|
|
|
|
for completeness but are only useful in specialized situations.
|
|
|
|
|
|
|
|
|
|
@item sp, pc, special
|
|
|
|
|
The frame is identified by the stack address, the PC, and a
|
|
|
|
|
``special'' address. The special address is used on architectures
|
|
|
|
|
that can have frames that do not change the stack, but which are still
|
|
|
|
|
distinct, for example the IA-64, which has a second stack for
|
|
|
|
|
registers. Both @var{sp} and @var{special} must be constant
|
|
|
|
|
throughout the lifetime of the frame.
|
2015-04-01 11:49:12 -07:00
|
|
|
|
|
|
|
|
@item sp
|
2018-09-08 13:25:34 -06:00
|
|
|
The frame is identified by the stack address only. Any other stack
|
|
|
|
|
frame with a matching @var{sp} will be considered to match this frame.
|
|
|
|
|
Inside gdb, this is called a ``wild frame''. You will never need
|
|
|
|
|
this.
|
2015-04-01 11:49:12 -07:00
|
|
|
@end table
|
2018-09-08 13:25:34 -06:00
|
|
|
|
gdb/python: Allow gdb.UnwindInfo to be created with non gdb.Value args
Currently when creating a gdb.UnwindInfo object a user must call
gdb.PendingFrame.create_unwind_info and pass a frame-id object.
The frame-id object should have at least a 'sp' attribute, and
probably a 'pc' attribute too (it can also, in some cases have a
'special' attribute).
Currently all of these frame-id attributes need to be gdb.Value
objects, but the only reason for that requirement is that we have some
code in py-unwind.c that only handles gdb.Value objects.
If instead we switch to using get_addr_from_python in py-utils.c then
we will support both gdb.Value objects and also raw numbers, which
might make things simpler in some cases.
So, I started rewriting pyuw_object_attribute_to_pointer (in
py-unwind.c) to use get_addr_from_python. However, while looking at
the code I noticed a problem.
The pyuw_object_attribute_to_pointer function returns a boolean flag,
if everything goes OK we return true, but we return false in two
cases, (1) when the attribute is not present, which might be
acceptable, or might be an error, and (2) when we get an error trying
to extract the attribute value, in which case a Python error will have
been set.
Now in pending_framepy_create_unwind_info we have this code:
if (!pyuw_object_attribute_to_pointer (pyo_frame_id, "sp", &sp))
{
PyErr_SetString (PyExc_ValueError,
_("frame_id should have 'sp' attribute."));
return NULL;
}
Notice how we always set an error. This will override any error that
is already set.
So, if you create a frame-id object that has an 'sp' attribute, but
the attribute is not a gdb.Value, then currently we fail to extract
the attribute value (it's not a gdb.Value) and set this error in
pyuw_object_attribute_to_pointer:
rc = pyuw_value_obj_to_pointer (pyo_value.get (), addr);
if (!rc)
PyErr_Format (
PyExc_ValueError,
_("The value of the '%s' attribute is not a pointer."),
attr_name);
Then we return to pending_framepy_create_unwind_info and immediately
override this error with the error about 'sp' being missing.
This all feels very confused.
Here's my proposed solution: pyuw_object_attribute_to_pointer will now
return a tri-state enum, with states OK, MISSING, or ERROR. The
meanings of these states are:
OK - Attribute exists and was extracted fine,
MISSING - Attribute doesn't exist, no Python error was set.
ERROR - Attribute does exist, but there was an error while
extracting it, a Python error was set.
We need to update pending_framepy_create_unwind_info, the only user of
pyuw_object_attribute_to_pointer, but now I think things are much
clearer. Errors from lower levels are not blindly overridden with the
generic meaningless error message, but we still get the "missing 'sp'
attribute" error when appropriate.
This change also includes the switch to get_addr_from_python which was
what started this whole journey.
For well behaving user code there should be no visible changes after
this commit.
For user code that hits an error, hopefully the new errors should be
more helpful in figuring out what's gone wrong.
Additionally, users can now use integers for the 'sp' and 'pc'
attributes in their frame-id objects if that is useful.
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-10 11:29:39 +00:00
|
|
|
Each attribute value should either be an instance of @code{gdb.Value}
|
|
|
|
|
or an integer.
|
2015-04-01 11:49:12 -07:00
|
|
|
|
2023-03-10 12:29:58 +00:00
|
|
|
A helper class is provided in the @code{gdb.unwinder} module that can
|
|
|
|
|
be used to represent a frame-id
|
|
|
|
|
(@pxref{gdb.unwinder.FrameId}).
|
|
|
|
|
|
2015-04-01 11:49:12 -07:00
|
|
|
@end defun
|
|
|
|
|
|
2020-06-07 23:07:52 +01:00
|
|
|
@defun PendingFrame.architecture ()
|
|
|
|
|
Return the @code{gdb.Architecture} (@pxref{Architectures In Python})
|
|
|
|
|
for this @code{gdb.PendingFrame}. This represents the architecture of
|
|
|
|
|
the particular frame being unwound.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2021-05-26 22:01:59 +01:00
|
|
|
@defun PendingFrame.level ()
|
|
|
|
|
Return an integer, the stack frame level for this frame.
|
|
|
|
|
@xref{Frames, ,Stack Frames}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
gdb/python: add some additional methods to gdb.PendingFrame
The gdb.Frame class has far more methods than gdb.PendingFrame. Given
that a PendingFrame hasn't yet been claimed by an unwinder, there is a
limit to which methods we can add to it, but many of the methods that
the Frame class has, the PendingFrame class could also support.
In this commit I've added those methods to PendingFrame that I believe
are safe.
In terms of implementation: if I was starting from scratch then I
would implement many of these (or most of these) as attributes rather
than methods. However, given both Frame and PendingFrame are just
different representation of a frame, I think there is value in keeping
the interface for the two classes the same. For this reason
everything here is a method -- that's what the Frame class does.
The new methods I've added are:
- gdb.PendingFrame.is_valid: Return True if the pending frame
object is valid.
- gdb.PendingFrame.name: Return the name for the frame's function,
or None.
- gdb.PendingFrame.pc: Return the $pc register value for this
frame.
- gdb.PendingFrame.language: Return a string containing the
language for this frame, or None.
- gdb.PendingFrame.find_sal: Return a gdb.Symtab_and_line object
for the current location within the pending frame, or None.
- gdb.PendingFrame.block: Return a gdb.Block for the current
pending frame, or None.
- gdb.PendingFrame.function: Return a gdb.Symbol for the current
pending frame, or None.
In every case I've just copied the implementation over from gdb.Frame
and cleaned the code slightly e.g. NULL to nullptr. Additionally each
function required a small update to reflect the PendingFrame type, but
that's pretty minor.
There are tests for all the new methods.
For more extensive testing, I added the following code to the file
gdb/python/lib/command/unwinders.py:
from gdb.unwinder import Unwinder
class TestUnwinder(Unwinder):
def __init__(self):
super().__init__("XXX_TestUnwinder_XXX")
def __call__(self,pending_frame):
lang = pending_frame.language()
try:
block = pending_frame.block()
assert isinstance(block, gdb.Block)
except RuntimeError as rte:
assert str(rte) == "Cannot locate block for frame."
function = pending_frame.function()
arch = pending_frame.architecture()
assert arch is None or isinstance(arch, gdb.Architecture)
name = pending_frame.name()
assert name is None or isinstance(name, str)
valid = pending_frame.is_valid()
pc = pending_frame.pc()
sal = pending_frame.find_sal()
assert sal is None or isinstance(sal, gdb.Symtab_and_line)
return None
gdb.unwinder.register_unwinder(None, TestUnwinder())
This registers a global unwinder that calls each of the new
PendingFrame methods and checks the result is of an acceptable type.
The unwinder never claims any frames though, so shouldn't change how
GDB actually behaves.
I then ran the testsuite. There was only a single regression, a test
that uses 'disable unwinder' and expects a single unwinder to be
disabled -- the extra unwinder is now disabled too, which changes the
test output. So I'm reasonably confident that the new methods are not
going to crash GDB.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-08 16:11:45 +00:00
|
|
|
@defun PendingFrame.name ()
|
|
|
|
|
Returns the function name of this pending frame, or @code{None} if it
|
|
|
|
|
can't be obtained.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun PendingFrame.is_valid ()
|
|
|
|
|
Returns true if the @code{gdb.PendingFrame} object is valid, false if
|
|
|
|
|
not. A pending frame object becomes invalid when the call to the
|
|
|
|
|
unwinder, for which the pending frame was created, returns.
|
|
|
|
|
|
|
|
|
|
All @code{gdb.PendingFrame} methods, except this one, will raise an
|
|
|
|
|
exception if the pending frame object is invalid at the time the
|
|
|
|
|
method is called.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun PendingFrame.pc ()
|
|
|
|
|
Returns the pending frame's resume address.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun PendingFrame.block ()
|
|
|
|
|
Return the pending frame's code block (@pxref{Blocks In Python}). If
|
|
|
|
|
the frame does not have a block -- for example, if there is no
|
|
|
|
|
debugging information for the code in question -- then this will raise
|
|
|
|
|
a @code{RuntimeError} exception.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun PendingFrame.function ()
|
|
|
|
|
Return the symbol for the function corresponding to this pending frame.
|
|
|
|
|
@xref{Symbols In Python}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun PendingFrame.find_sal ()
|
|
|
|
|
Return the pending frame's symtab and line object (@pxref{Symbol
|
|
|
|
|
Tables In Python}).
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun PendingFrame.language ()
|
|
|
|
|
Return the language of this frame, as a string, or None.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2015-04-01 11:49:12 -07:00
|
|
|
@subheading Unwinder Output: UnwindInfo
|
|
|
|
|
|
|
|
|
|
Use @code{PendingFrame.create_unwind_info} method described above to
|
|
|
|
|
create a @code{gdb.UnwindInfo} instance. Use the following method to
|
|
|
|
|
specify caller registers that have been saved in this frame:
|
|
|
|
|
|
2023-03-14 11:22:35 +00:00
|
|
|
@defun gdb.UnwindInfo.add_saved_register (register, value)
|
|
|
|
|
@var{register} identifies the register, for a description of the acceptable
|
gdb/python: make more use of RegisterDescriptors
This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.
Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number. I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind. However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.
Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.
This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.
The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly. However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.
As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.
After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.
gdb/ChangeLog:
* python/py-frame.c: Remove 'user-regs.h' include.
(frapy_read_register): Rewrite to make use of
gdbpy_parse_register_id.
* python/py-registers.c (gdbpy_parse_register_id): New function,
moved here from python/py-unwind.c. Updated the return type, and
also accepts register descriptor objects.
* python/py-unwind.c: Remove 'user-regs.h' include.
(pyuw_parse_register_id): Moved to python/py-registers.c.
(unwind_infopy_add_saved_register): Update to use
gdbpy_parse_register_id.
(pending_framepy_read_register): Likewise.
* python/python-internal.h (gdbpy_parse_register_id): Declare.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py: Update to make use of a register
descriptor.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Update descriptions
for PendingFrame.read_register and
gdb.UnwindInfo.add_saved_register.
(Frames In Python): Update description of Frame.read_register.
2020-07-22 12:13:11 +01:00
|
|
|
values see @ref{gdbpy_frame_read_register,,Frame.read_register}.
|
2015-04-01 11:49:12 -07:00
|
|
|
@var{value} is a register value (a @code{gdb.Value} object).
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-03-08 16:11:30 +00:00
|
|
|
@subheading The @code{gdb.unwinder} Module
|
|
|
|
|
|
|
|
|
|
@value{GDBN} comes with a @code{gdb.unwinder} module which contains
|
2023-03-10 12:29:58 +00:00
|
|
|
the following classes:
|
2023-03-08 16:11:30 +00:00
|
|
|
|
|
|
|
|
@deftp {class} gdb.unwinder.Unwinder
|
|
|
|
|
The @code{Unwinder} class is a base class from which user created
|
|
|
|
|
unwinders can derive, though it is not required that unwinders derive
|
|
|
|
|
from this class, so long as any user created unwinder has the required
|
|
|
|
|
@code{name} and @code{enabled} attributes.
|
|
|
|
|
|
2025-01-27 10:33:28 +01:00
|
|
|
@defun gdb.unwinder.Unwinder.__init__ (name)
|
2023-03-08 16:11:30 +00:00
|
|
|
The @var{name} is a string used to reference this unwinder within some
|
|
|
|
|
@value{GDBN} commands (@pxref{Managing Registered Unwinders}).
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defvar gdb.unwinder.name
|
|
|
|
|
A read-only attribute which is a string, the name of this unwinder.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar gdb.unwinder.enabled
|
|
|
|
|
A modifiable attribute containing a boolean; when @code{True}, the
|
|
|
|
|
unwinder is enabled, and will be used by @value{GDBN}. When
|
|
|
|
|
@code{False}, the unwinder has been disabled, and will not be used.
|
|
|
|
|
@end defvar
|
|
|
|
|
@end deftp
|
|
|
|
|
|
2023-03-10 12:29:58 +00:00
|
|
|
@anchor{gdb.unwinder.FrameId}
|
|
|
|
|
@deftp {class} gdb.unwinder.FrameId
|
|
|
|
|
This is a class suitable for being used as the frame-id when calling
|
|
|
|
|
@code{gdb.PendingFrame.create_unwind_info}. It is not required to use
|
|
|
|
|
this class, any class with the required attribute
|
|
|
|
|
(@pxref{gdb.PendingFrame.create_unwind_info}) will be accepted, but in
|
|
|
|
|
most cases this class will be sufficient.
|
|
|
|
|
|
|
|
|
|
@code{gdb.unwinder.FrameId} has the following method:
|
|
|
|
|
|
2025-01-27 10:33:28 +01:00
|
|
|
@defun gdb.unwinder.FrameId.__init__ (sp, pc, special = @code{None})
|
2023-03-10 12:29:58 +00:00
|
|
|
The @var{sp} and @var{pc} arguments are required and should be either
|
|
|
|
|
a @code{gdb.Value} object, or an integer.
|
|
|
|
|
|
|
|
|
|
The @var{special} argument is optional; if specified, it should be a
|
|
|
|
|
@code{gdb.Value} object, or an integer.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@code{gdb.unwinder.FrameId} has the following read-only attributes:
|
|
|
|
|
|
|
|
|
|
@defvar gdb.unwinder.sp
|
|
|
|
|
The @var{sp} value passed to the constructor.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar gdb.unwinder.pc
|
|
|
|
|
The @var{pc} value passed to the constructor.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar gdb.unwinder.special
|
|
|
|
|
The @var{special} value passed to the constructor, or @code{None} if
|
|
|
|
|
no such value was passed.
|
|
|
|
|
@end defvar
|
|
|
|
|
@end deftp
|
|
|
|
|
|
2023-03-08 15:26:32 +00:00
|
|
|
@subheading Registering an Unwinder
|
|
|
|
|
|
|
|
|
|
Object files and program spaces can have unwinders registered with
|
|
|
|
|
them. In addition, you can register unwinders globally.
|
|
|
|
|
|
|
|
|
|
The @code{gdb.unwinders} module provides the function to register an
|
|
|
|
|
unwinder:
|
|
|
|
|
|
|
|
|
|
@defun gdb.unwinder.register_unwinder (locus, unwinder, replace=False)
|
|
|
|
|
@var{locus} specifies to which unwinder list to prepend the
|
|
|
|
|
@var{unwinder}. It can be either an object file (@pxref{Objfiles In
|
|
|
|
|
Python}), a program space (@pxref{Progspaces In Python}), or
|
|
|
|
|
@code{None}, in which case the unwinder is registered globally. The
|
|
|
|
|
newly added @var{unwinder} will be called before any other unwinder
|
|
|
|
|
from the same locus. Two unwinders in the same locus cannot have the
|
|
|
|
|
same name. An attempt to add an unwinder with an already existing
|
|
|
|
|
name raises an exception unless @var{replace} is @code{True}, in which
|
|
|
|
|
case the old unwinder is deleted and the new unwinder is registered in
|
|
|
|
|
its place.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} first calls the unwinders from all the object files in no
|
|
|
|
|
particular order, then the unwinders from the current program space,
|
|
|
|
|
then the globally registered unwinders, and finally the unwinders
|
|
|
|
|
builtin to @value{GDBN}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2015-04-01 11:49:12 -07:00
|
|
|
@subheading Unwinder Skeleton Code
|
|
|
|
|
|
2023-03-08 16:11:30 +00:00
|
|
|
Here is an example of how to structure a user created unwinder:
|
2015-04-01 11:49:12 -07:00
|
|
|
|
|
|
|
|
@smallexample
|
2023-03-10 12:29:58 +00:00
|
|
|
from gdb.unwinder import Unwinder, FrameId
|
2015-04-01 11:49:12 -07:00
|
|
|
|
|
|
|
|
class MyUnwinder(Unwinder):
|
2023-03-08 15:26:32 +00:00
|
|
|
def __init__(self):
|
|
|
|
|
super().__init___("MyUnwinder_Name")
|
2015-04-01 11:49:12 -07:00
|
|
|
|
2023-03-08 15:26:32 +00:00
|
|
|
def __call__(self, pending_frame):
|
2015-04-01 11:49:12 -07:00
|
|
|
if not <we recognize frame>:
|
|
|
|
|
return None
|
2023-03-08 15:26:32 +00:00
|
|
|
|
|
|
|
|
# Create a FrameID. Usually the frame is identified by a
|
|
|
|
|
# stack pointer and the function address.
|
|
|
|
|
sp = ... compute a stack address ...
|
|
|
|
|
pc = ... compute function address ...
|
2015-04-01 11:49:12 -07:00
|
|
|
unwind_info = pending_frame.create_unwind_info(FrameId(sp, pc))
|
|
|
|
|
|
2023-03-08 15:26:32 +00:00
|
|
|
# Find the values of the registers in the caller's frame and
|
2015-04-01 11:49:12 -07:00
|
|
|
# save them in the result:
|
2023-03-08 15:26:32 +00:00
|
|
|
unwind_info.add_saved_register(<register-number>, <register-value>)
|
2015-04-01 11:49:12 -07:00
|
|
|
....
|
|
|
|
|
|
|
|
|
|
# Return the result:
|
|
|
|
|
return unwind_info
|
|
|
|
|
|
2023-03-08 15:26:32 +00:00
|
|
|
gdb.unwinder.register_unwinder(<locus>, MyUnwinder(), <replace>)
|
2015-04-01 11:49:12 -07:00
|
|
|
@end smallexample
|
|
|
|
|
|
2023-03-08 16:11:30 +00:00
|
|
|
@anchor{Managing Registered Unwinders}
|
|
|
|
|
@subheading Managing Registered Unwinders
|
|
|
|
|
@value{GDBN} defines 3 commands to manage registered unwinders. These
|
|
|
|
|
are:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@item info unwinder @r{[} @var{locus} @r{[} @var{name-regexp} @r{]} @r{]}
|
|
|
|
|
Lists all registered unwinders. Arguments @var{locus} and
|
|
|
|
|
@var{name-regexp} are both optional and can be used to filter which
|
|
|
|
|
unwinders are listed.
|
|
|
|
|
|
|
|
|
|
The @var{locus} argument should be either @kbd{global},
|
|
|
|
|
@kbd{progspace}, or the name of an object file. Only unwinders
|
|
|
|
|
registered for the specified locus will be listed.
|
|
|
|
|
|
|
|
|
|
The @var{name-regexp} is a regular expression used to match against
|
|
|
|
|
unwinder names. When trying to match against unwinder names that
|
|
|
|
|
include a string enclose @var{name-regexp} in quotes.
|
|
|
|
|
@item disable unwinder @r{[} @var{locus} @r{[} @var{name-regexp} @r{]} @r{]}
|
|
|
|
|
The @var{locus} and @var{name-regexp} are interpreted as in @kbd{info
|
|
|
|
|
unwinder} above, but instead of listing the matching unwinders, all of
|
|
|
|
|
the matching unwinders are disabled. The @code{enabled} field of each
|
|
|
|
|
matching unwinder is set to @code{False}.
|
|
|
|
|
@item enable unwinder @r{[} @var{locus} @r{[} @var{name-regexp} @r{]} @r{]}
|
|
|
|
|
The @var{locus} and @var{name-regexp} are interpreted as in @kbd{info
|
|
|
|
|
unwinder} above, but instead of listing the matching unwinders, all of
|
|
|
|
|
the matching unwinders are enabled. The @code{enabled} field of each
|
|
|
|
|
matching unwinder is set to @code{True}.
|
|
|
|
|
@end table
|
|
|
|
|
|
2014-03-30 16:24:50 -07:00
|
|
|
@node Xmethods In Python
|
|
|
|
|
@subsubsection Xmethods In Python
|
|
|
|
|
@cindex xmethods in Python
|
|
|
|
|
|
|
|
|
|
@dfn{Xmethods} are additional methods or replacements for existing
|
|
|
|
|
methods of a C@t{++} class. This feature is useful for those cases
|
|
|
|
|
where a method defined in C@t{++} source code could be inlined or
|
|
|
|
|
optimized out by the compiler, making it unavailable to @value{GDBN}.
|
|
|
|
|
For such cases, one can define an xmethod to serve as a replacement
|
|
|
|
|
for the method defined in the C@t{++} source code. @value{GDBN} will
|
|
|
|
|
then invoke the xmethod, instead of the C@t{++} method, to
|
|
|
|
|
evaluate expressions. One can also use xmethods when debugging
|
|
|
|
|
with core files. Moreover, when debugging live programs, invoking an
|
|
|
|
|
xmethod need not involve running the inferior (which can potentially
|
|
|
|
|
perturb its state). Hence, even if the C@t{++} method is available, it
|
|
|
|
|
is better to use its replacement xmethod if one is defined.
|
|
|
|
|
|
|
|
|
|
The xmethods feature in Python is available via the concepts of an
|
|
|
|
|
@dfn{xmethod matcher} and an @dfn{xmethod worker}. To
|
|
|
|
|
implement an xmethod, one has to implement a matcher and a
|
|
|
|
|
corresponding worker for it (more than one worker can be
|
|
|
|
|
implemented, each catering to a different overloaded instance of the
|
|
|
|
|
method). Internally, @value{GDBN} invokes the @code{match} method of a
|
|
|
|
|
matcher to match the class type and method name. On a match, the
|
|
|
|
|
@code{match} method returns a list of matching @emph{worker} objects.
|
|
|
|
|
Each worker object typically corresponds to an overloaded instance of
|
|
|
|
|
the xmethod. They implement a @code{get_arg_types} method which
|
|
|
|
|
returns a sequence of types corresponding to the arguments the xmethod
|
|
|
|
|
requires. @value{GDBN} uses this sequence of types to perform
|
|
|
|
|
overload resolution and picks a winning xmethod worker. A winner
|
|
|
|
|
is also selected from among the methods @value{GDBN} finds in the
|
|
|
|
|
C@t{++} source code. Next, the winning xmethod worker and the
|
|
|
|
|
winning C@t{++} method are compared to select an overall winner. In
|
|
|
|
|
case of a tie between a xmethod worker and a C@t{++} method, the
|
|
|
|
|
xmethod worker is selected as the winner. That is, if a winning
|
|
|
|
|
xmethod worker is found to be equivalent to the winning C@t{++}
|
|
|
|
|
method, then the xmethod worker is treated as a replacement for
|
|
|
|
|
the C@t{++} method. @value{GDBN} uses the overall winner to invoke the
|
|
|
|
|
method. If the winning xmethod worker is the overall winner, then
|
2015-04-24 11:16:12 -07:00
|
|
|
the corresponding xmethod is invoked via the @code{__call__} method
|
2014-03-30 16:24:50 -07:00
|
|
|
of the worker object.
|
|
|
|
|
|
|
|
|
|
If one wants to implement an xmethod as a replacement for an
|
|
|
|
|
existing C@t{++} method, then they have to implement an equivalent
|
|
|
|
|
xmethod which has exactly the same name and takes arguments of
|
|
|
|
|
exactly the same type as the C@t{++} method. If the user wants to
|
|
|
|
|
invoke the C@t{++} method even though a replacement xmethod is
|
|
|
|
|
available for that method, then they can disable the xmethod.
|
|
|
|
|
|
|
|
|
|
@xref{Xmethod API}, for API to implement xmethods in Python.
|
|
|
|
|
@xref{Writing an Xmethod}, for implementing xmethods in Python.
|
|
|
|
|
|
|
|
|
|
@node Xmethod API
|
|
|
|
|
@subsubsection Xmethod API
|
|
|
|
|
@cindex xmethod API
|
|
|
|
|
|
|
|
|
|
The @value{GDBN} Python API provides classes, interfaces and functions
|
|
|
|
|
to implement, register and manipulate xmethods.
|
|
|
|
|
@xref{Xmethods In Python}.
|
|
|
|
|
|
|
|
|
|
An xmethod matcher should be an instance of a class derived from
|
|
|
|
|
@code{XMethodMatcher} defined in the module @code{gdb.xmethod}, or an
|
|
|
|
|
object with similar interface and attributes. An instance of
|
|
|
|
|
@code{XMethodMatcher} has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar name
|
|
|
|
|
The name of the matcher.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar enabled
|
|
|
|
|
A boolean value indicating whether the matcher is enabled or disabled.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar methods
|
|
|
|
|
A list of named methods managed by the matcher. Each object in the list
|
|
|
|
|
is an instance of the class @code{XMethod} defined in the module
|
|
|
|
|
@code{gdb.xmethod}, or any object with the following attributes:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
|
|
|
|
|
@item name
|
|
|
|
|
Name of the xmethod which should be unique for each xmethod
|
|
|
|
|
managed by the matcher.
|
|
|
|
|
|
|
|
|
|
@item enabled
|
|
|
|
|
A boolean value indicating whether the xmethod is enabled or
|
|
|
|
|
disabled.
|
|
|
|
|
|
|
|
|
|
@end table
|
|
|
|
|
|
|
|
|
|
The class @code{XMethod} is a convenience class with same
|
|
|
|
|
attributes as above along with the following constructor:
|
|
|
|
|
|
2014-06-09 06:47:22 -07:00
|
|
|
@defun XMethod.__init__ (self, name)
|
2014-03-30 16:24:50 -07:00
|
|
|
Constructs an enabled xmethod with name @var{name}.
|
|
|
|
|
@end defun
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
The @code{XMethodMatcher} class has the following methods:
|
|
|
|
|
|
2014-06-09 06:47:22 -07:00
|
|
|
@defun XMethodMatcher.__init__ (self, name)
|
2014-03-30 16:24:50 -07:00
|
|
|
Constructs an enabled xmethod matcher with name @var{name}. The
|
|
|
|
|
@code{methods} attribute is initialized to @code{None}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-06-09 06:47:22 -07:00
|
|
|
@defun XMethodMatcher.match (self, class_type, method_name)
|
2014-03-30 16:24:50 -07:00
|
|
|
Derived classes should override this method. It should return a
|
|
|
|
|
xmethod worker object (or a sequence of xmethod worker
|
|
|
|
|
objects) matching the @var{class_type} and @var{method_name}.
|
|
|
|
|
@var{class_type} is a @code{gdb.Type} object, and @var{method_name}
|
|
|
|
|
is a string value. If the matcher manages named methods as listed in
|
|
|
|
|
its @code{methods} attribute, then only those worker objects whose
|
|
|
|
|
corresponding entries in the @code{methods} list are enabled should be
|
|
|
|
|
returned.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
An xmethod worker should be an instance of a class derived from
|
|
|
|
|
@code{XMethodWorker} defined in the module @code{gdb.xmethod},
|
|
|
|
|
or support the following interface:
|
|
|
|
|
|
2014-06-09 06:47:22 -07:00
|
|
|
@defun XMethodWorker.get_arg_types (self)
|
2014-03-30 16:24:50 -07:00
|
|
|
This method returns a sequence of @code{gdb.Type} objects corresponding
|
|
|
|
|
to the arguments that the xmethod takes. It can return an empty
|
|
|
|
|
sequence or @code{None} if the xmethod does not take any arguments.
|
|
|
|
|
If the xmethod takes a single argument, then a single
|
|
|
|
|
@code{gdb.Type} object corresponding to it can be returned.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2015-04-29 13:24:21 -07:00
|
|
|
@defun XMethodWorker.get_result_type (self, *args)
|
|
|
|
|
This method returns a @code{gdb.Type} object representing the type
|
|
|
|
|
of the result of invoking this xmethod.
|
|
|
|
|
The @var{args} argument is the same tuple of arguments that would be
|
|
|
|
|
passed to the @code{__call__} method of this worker.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-06-09 06:47:22 -07:00
|
|
|
@defun XMethodWorker.__call__ (self, *args)
|
2014-03-30 16:24:50 -07:00
|
|
|
This is the method which does the @emph{work} of the xmethod. The
|
|
|
|
|
@var{args} arguments is the tuple of arguments to the xmethod. Each
|
|
|
|
|
element in this tuple is a gdb.Value object. The first element is
|
|
|
|
|
always the @code{this} pointer value.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
For @value{GDBN} to lookup xmethods, the xmethod matchers
|
|
|
|
|
should be registered using the following function defined in the module
|
|
|
|
|
@code{gdb.xmethod}:
|
|
|
|
|
|
2014-06-09 06:47:22 -07:00
|
|
|
@defun register_xmethod_matcher (locus, matcher, replace=False)
|
2014-03-30 16:24:50 -07:00
|
|
|
The @code{matcher} is registered with @code{locus}, replacing an
|
|
|
|
|
existing matcher with the same name as @code{matcher} if
|
|
|
|
|
@code{replace} is @code{True}. @code{locus} can be a
|
|
|
|
|
@code{gdb.Objfile} object (@pxref{Objfiles In Python}), or a
|
2014-06-03 10:39:03 -07:00
|
|
|
@code{gdb.Progspace} object (@pxref{Progspaces In Python}), or
|
2014-03-30 16:24:50 -07:00
|
|
|
@code{None}. If it is @code{None}, then @code{matcher} is registered
|
|
|
|
|
globally.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@node Writing an Xmethod
|
|
|
|
|
@subsubsection Writing an Xmethod
|
|
|
|
|
@cindex writing xmethods in Python
|
|
|
|
|
|
|
|
|
|
Implementing xmethods in Python will require implementing xmethod
|
|
|
|
|
matchers and xmethod workers (@pxref{Xmethods In Python}). Consider
|
|
|
|
|
the following C@t{++} class:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class MyClass
|
|
|
|
|
@{
|
|
|
|
|
public:
|
|
|
|
|
MyClass (int a) : a_(a) @{ @}
|
|
|
|
|
|
|
|
|
|
int geta (void) @{ return a_; @}
|
|
|
|
|
int operator+ (int b);
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
int a_;
|
|
|
|
|
@};
|
|
|
|
|
|
|
|
|
|
int
|
|
|
|
|
MyClass::operator+ (int b)
|
|
|
|
|
@{
|
|
|
|
|
return a_ + b;
|
|
|
|
|
@}
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
Let us define two xmethods for the class @code{MyClass}, one
|
|
|
|
|
replacing the method @code{geta}, and another adding an overloaded
|
|
|
|
|
flavor of @code{operator+} which takes a @code{MyClass} argument (the
|
|
|
|
|
C@t{++} code above already has an overloaded @code{operator+}
|
|
|
|
|
which takes an @code{int} argument). The xmethod matcher can be
|
|
|
|
|
defined as follows:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class MyClass_geta(gdb.xmethod.XMethod):
|
|
|
|
|
def __init__(self):
|
|
|
|
|
gdb.xmethod.XMethod.__init__(self, 'geta')
|
|
|
|
|
|
|
|
|
|
def get_worker(self, method_name):
|
|
|
|
|
if method_name == 'geta':
|
|
|
|
|
return MyClassWorker_geta()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class MyClass_sum(gdb.xmethod.XMethod):
|
|
|
|
|
def __init__(self):
|
|
|
|
|
gdb.xmethod.XMethod.__init__(self, 'sum')
|
|
|
|
|
|
|
|
|
|
def get_worker(self, method_name):
|
|
|
|
|
if method_name == 'operator+':
|
|
|
|
|
return MyClassWorker_plus()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class MyClassMatcher(gdb.xmethod.XMethodMatcher):
|
|
|
|
|
def __init__(self):
|
|
|
|
|
gdb.xmethod.XMethodMatcher.__init__(self, 'MyClassMatcher')
|
|
|
|
|
# List of methods 'managed' by this matcher
|
|
|
|
|
self.methods = [MyClass_geta(), MyClass_sum()]
|
|
|
|
|
|
|
|
|
|
def match(self, class_type, method_name):
|
|
|
|
|
if class_type.tag != 'MyClass':
|
|
|
|
|
return None
|
|
|
|
|
workers = []
|
|
|
|
|
for method in self.methods:
|
|
|
|
|
if method.enabled:
|
|
|
|
|
worker = method.get_worker(method_name)
|
|
|
|
|
if worker:
|
|
|
|
|
workers.append(worker)
|
|
|
|
|
|
|
|
|
|
return workers
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
Notice that the @code{match} method of @code{MyClassMatcher} returns
|
|
|
|
|
a worker object of type @code{MyClassWorker_geta} for the @code{geta}
|
|
|
|
|
method, and a worker object of type @code{MyClassWorker_plus} for the
|
|
|
|
|
@code{operator+} method. This is done indirectly via helper classes
|
|
|
|
|
derived from @code{gdb.xmethod.XMethod}. One does not need to use the
|
|
|
|
|
@code{methods} attribute in a matcher as it is optional. However, if a
|
|
|
|
|
matcher manages more than one xmethod, it is a good practice to list the
|
|
|
|
|
xmethods in the @code{methods} attribute of the matcher. This will then
|
|
|
|
|
facilitate enabling and disabling individual xmethods via the
|
|
|
|
|
@code{enable/disable} commands. Notice also that a worker object is
|
|
|
|
|
returned only if the corresponding entry in the @code{methods} attribute
|
|
|
|
|
of the matcher is enabled.
|
|
|
|
|
|
|
|
|
|
The implementation of the worker classes returned by the matcher setup
|
|
|
|
|
above is as follows:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class MyClassWorker_geta(gdb.xmethod.XMethodWorker):
|
|
|
|
|
def get_arg_types(self):
|
|
|
|
|
return None
|
2015-04-29 13:24:21 -07:00
|
|
|
|
|
|
|
|
def get_result_type(self, obj):
|
|
|
|
|
return gdb.lookup_type('int')
|
2014-03-30 16:24:50 -07:00
|
|
|
|
|
|
|
|
def __call__(self, obj):
|
|
|
|
|
return obj['a_']
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class MyClassWorker_plus(gdb.xmethod.XMethodWorker):
|
|
|
|
|
def get_arg_types(self):
|
|
|
|
|
return gdb.lookup_type('MyClass')
|
2015-04-29 13:24:21 -07:00
|
|
|
|
|
|
|
|
def get_result_type(self, obj):
|
|
|
|
|
return gdb.lookup_type('int')
|
2014-03-30 16:24:50 -07:00
|
|
|
|
|
|
|
|
def __call__(self, obj, other):
|
|
|
|
|
return obj['a_'] + other['a_']
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
For @value{GDBN} to actually lookup a xmethod, it has to be
|
|
|
|
|
registered with it. The matcher defined above is registered with
|
|
|
|
|
@value{GDBN} globally as follows:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
gdb.xmethod.register_xmethod_matcher(None, MyClassMatcher())
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
If an object @code{obj} of type @code{MyClass} is initialized in C@t{++}
|
|
|
|
|
code as follows:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
MyClass obj(5);
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
then, after loading the Python script defining the xmethod matchers
|
2023-01-09 14:11:29 -05:00
|
|
|
and workers into @value{GDBN}, invoking the method @code{geta} or using
|
2014-03-30 16:24:50 -07:00
|
|
|
the operator @code{+} on @code{obj} will invoke the xmethods
|
|
|
|
|
defined above:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(gdb) p obj.geta()
|
|
|
|
|
$1 = 5
|
|
|
|
|
|
|
|
|
|
(gdb) p obj + obj
|
|
|
|
|
$2 = 10
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Consider another example with a C++ template class:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
template <class T>
|
|
|
|
|
class MyTemplate
|
|
|
|
|
@{
|
|
|
|
|
public:
|
|
|
|
|
MyTemplate () : dsize_(10), data_ (new T [10]) @{ @}
|
|
|
|
|
~MyTemplate () @{ delete [] data_; @}
|
|
|
|
|
|
|
|
|
|
int footprint (void)
|
|
|
|
|
@{
|
|
|
|
|
return sizeof (T) * dsize_ + sizeof (MyTemplate<T>);
|
|
|
|
|
@}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
int dsize_;
|
|
|
|
|
T *data_;
|
|
|
|
|
@};
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Let us implement an xmethod for the above class which serves as a
|
|
|
|
|
replacement for the @code{footprint} method. The full code listing
|
|
|
|
|
of the xmethod workers and xmethod matchers is as follows:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class MyTemplateWorker_footprint(gdb.xmethod.XMethodWorker):
|
|
|
|
|
def __init__(self, class_type):
|
|
|
|
|
self.class_type = class_type
|
2015-04-29 13:24:21 -07:00
|
|
|
|
2014-03-30 16:24:50 -07:00
|
|
|
def get_arg_types(self):
|
|
|
|
|
return None
|
2015-04-29 13:24:21 -07:00
|
|
|
|
|
|
|
|
def get_result_type(self):
|
|
|
|
|
return gdb.lookup_type('int')
|
|
|
|
|
|
2014-03-30 16:24:50 -07:00
|
|
|
def __call__(self, obj):
|
|
|
|
|
return (self.class_type.sizeof +
|
|
|
|
|
obj['dsize_'] *
|
|
|
|
|
self.class_type.template_argument(0).sizeof)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class MyTemplateMatcher_footprint(gdb.xmethod.XMethodMatcher):
|
|
|
|
|
def __init__(self):
|
|
|
|
|
gdb.xmethod.XMethodMatcher.__init__(self, 'MyTemplateMatcher')
|
|
|
|
|
|
|
|
|
|
def match(self, class_type, method_name):
|
|
|
|
|
if (re.match('MyTemplate<[ \t\n]*[_a-zA-Z][ _a-zA-Z0-9]*>',
|
|
|
|
|
class_type.tag) and
|
|
|
|
|
method_name == 'footprint'):
|
|
|
|
|
return MyTemplateWorker_footprint(class_type)
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Notice that, in this example, we have not used the @code{methods}
|
|
|
|
|
attribute of the matcher as the matcher manages only one xmethod. The
|
|
|
|
|
user can enable/disable this xmethod by enabling/disabling the matcher
|
|
|
|
|
itself.
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Inferiors In Python
|
|
|
|
|
@subsubsection Inferiors In Python
|
|
|
|
|
@cindex inferiors in Python
|
|
|
|
|
|
|
|
|
|
@findex gdb.Inferior
|
|
|
|
|
Programs which are being run under @value{GDBN} are called inferiors
|
2020-01-10 20:06:15 +00:00
|
|
|
(@pxref{Inferiors Connections and Programs}). Python scripts can access
|
2014-02-17 10:35:03 -08:00
|
|
|
information about and manipulate inferiors controlled by @value{GDBN}
|
|
|
|
|
via objects of the @code{gdb.Inferior} class.
|
|
|
|
|
|
|
|
|
|
The following inferior-related functions are available in the @code{gdb}
|
|
|
|
|
module:
|
|
|
|
|
|
|
|
|
|
@defun gdb.inferiors ()
|
|
|
|
|
Return a tuple containing all inferior objects.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.selected_inferior ()
|
|
|
|
|
Return an object representing the current inferior.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
A @code{gdb.Inferior} object has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar Inferior.num
|
gdb: add inferior-specific breakpoints
This commit extends the breakpoint mechanism to allow for inferior
specific breakpoints (but not watchpoints in this commit).
As GDB gains better support for multiple connections, and so for
running multiple (possibly unrelated) inferiors, then it is not hard
to imagine that a user might wish to create breakpoints that apply to
any thread in a single inferior. To achieve this currently, the user
would need to create a condition possibly making use of the $_inferior
convenience variable, which, though functional, isn't the most user
friendly.
This commit adds a new 'inferior' keyword that allows for the creation
of inferior specific breakpoints.
Inferior specific breakpoints are automatically deleted when the
associated inferior is removed from GDB, this is similar to how
thread-specific breakpoints are deleted when the associated thread is
deleted.
Watchpoints are already per-program-space, which in most cases mean
watchpoints are already inferior specific. There is a small window
where inferior-specific watchpoints might make sense, which is after a
vfork, when two processes are sharing the same address space.
However, I'm leaving that as an exercise for another day. For now,
attempting to use the inferior keyword with a watchpoint will give an
error, like this:
(gdb) watch a8 inferior 1
Cannot use 'inferior' keyword with watchpoints
A final note on the implementation: currently, inferior specific
breakpoints, like thread-specific breakpoints, are inserted into every
inferior, GDB then checks once the inferior stops if we are in the
correct thread or inferior, and resumes automatically if we stopped in
the wrong thread/inferior.
An obvious optimisation here is to only insert breakpoint locations
into the specific program space (which mostly means inferior) that
contains either the inferior or thread we are interested in. This
would reduce the number times GDB has to stop and then resume again in
a multi-inferior setup.
I have a series on the mailing list[1] that implements this
optimisation for thread-specific breakpoints. Once this series has
landed I'll update that series to also handle inferior specific
breakpoints in the same way. For now, inferior specific breakpoints
are just slightly less optimal, but this is no different to
thread-specific breakpoints in a multi-inferior debug session, so I
don't see this as a huge problem.
[1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/
2022-11-08 12:32:51 +00:00
|
|
|
ID of inferior, as assigned by @value{GDBN}. You can use this to make
|
|
|
|
|
Python breakpoints inferior-specific, for example
|
|
|
|
|
(@pxref{python_breakpoint_inferior,,The Breakpoint.inferior
|
|
|
|
|
attribute}).
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
gdb/python: introduce gdb.TargetConnection object type
This commit adds a new object type gdb.TargetConnection. This new
type represents a connection within GDB (a connection as displayed by
'info connections').
There's three ways to find a gdb.TargetConnection, there's a new
'gdb.connections()' function, which returns a list of all currently
active connections.
Or you can read the new 'connection' property on the gdb.Inferior
object type, this contains the connection for that inferior (or None
if the inferior has no connection, for example, it is exited).
Finally, there's a new gdb.events.connection_removed event registry,
this emits a new gdb.ConnectionEvent whenever a connection is removed
from GDB (this can happen when all inferiors using a connection exit,
though this is not always the case, depending on the connection type).
The gdb.ConnectionEvent has a 'connection' property, which is the
gdb.TargetConnection being removed from GDB.
The gdb.TargetConnection has an 'is_valid()' method. A connection
object becomes invalid when the underlying connection is removed from
GDB (as discussed above, this might be when all inferiors using a
connection exit, or it might be when the user explicitly replaces a
connection in GDB by issuing another 'target' command).
The gdb.TargetConnection has the following read-only properties:
'num': The number for this connection,
'type': e.g. 'native', 'remote', 'sim', etc
'description': The longer description as seen in the 'info
connections' command output.
'details': A string or None. Extra details for the connection, for
example, a remote connection's details might be
'hostname:port'.
2021-09-01 15:33:19 +01:00
|
|
|
@anchor{gdbpy_inferior_connection}
|
|
|
|
|
@defvar Inferior.connection
|
|
|
|
|
The @code{gdb.TargetConnection} for this inferior (@pxref{Connections
|
|
|
|
|
In Python}), or @code{None} if this inferior has no connection.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2021-05-14 11:56:31 +02:00
|
|
|
@defvar Inferior.connection_num
|
|
|
|
|
ID of inferior's connection as assigned by @value{GDBN}, or None if
|
gdb/python: introduce gdb.TargetConnection object type
This commit adds a new object type gdb.TargetConnection. This new
type represents a connection within GDB (a connection as displayed by
'info connections').
There's three ways to find a gdb.TargetConnection, there's a new
'gdb.connections()' function, which returns a list of all currently
active connections.
Or you can read the new 'connection' property on the gdb.Inferior
object type, this contains the connection for that inferior (or None
if the inferior has no connection, for example, it is exited).
Finally, there's a new gdb.events.connection_removed event registry,
this emits a new gdb.ConnectionEvent whenever a connection is removed
from GDB (this can happen when all inferiors using a connection exit,
though this is not always the case, depending on the connection type).
The gdb.ConnectionEvent has a 'connection' property, which is the
gdb.TargetConnection being removed from GDB.
The gdb.TargetConnection has an 'is_valid()' method. A connection
object becomes invalid when the underlying connection is removed from
GDB (as discussed above, this might be when all inferiors using a
connection exit, or it might be when the user explicitly replaces a
connection in GDB by issuing another 'target' command).
The gdb.TargetConnection has the following read-only properties:
'num': The number for this connection,
'type': e.g. 'native', 'remote', 'sim', etc
'description': The longer description as seen in the 'info
connections' command output.
'details': A string or None. Extra details for the connection, for
example, a remote connection's details might be
'hostname:port'.
2021-09-01 15:33:19 +01:00
|
|
|
the inferior is not connected to a target. @xref{Inferiors Connections
|
|
|
|
|
and Programs}. This is equivalent to
|
|
|
|
|
@code{gdb.Inferior.connection.num} in the case where
|
|
|
|
|
@code{gdb.Inferior.connection} is not @code{None}.
|
2021-05-14 11:56:31 +02:00
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar Inferior.pid
|
|
|
|
|
Process ID of the inferior, as assigned by the underlying operating
|
|
|
|
|
system.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Inferior.was_attached
|
|
|
|
|
Boolean signaling whether the inferior was created using `attach', or
|
|
|
|
|
started by @value{GDBN} itself.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2023-05-01 13:53:59 -06:00
|
|
|
@defvar Inferior.main_name
|
|
|
|
|
A string holding the name of this inferior's ``main'' function, if it
|
|
|
|
|
can be determined. If the name of main is not known, this is
|
|
|
|
|
@code{None}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2018-09-13 15:39:26 -04:00
|
|
|
@defvar Inferior.progspace
|
|
|
|
|
The inferior's program space. @xref{Progspaces In Python}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2023-05-01 13:53:59 -06:00
|
|
|
@defvar Inferior.arguments
|
|
|
|
|
The inferior's command line arguments, if known. This corresponds to
|
|
|
|
|
the @code{set args} and @code{show args} commands. @xref{Arguments}.
|
|
|
|
|
|
|
|
|
|
When accessed, the value is a string holding all the arguments. The
|
|
|
|
|
contents are quoted as they would be when passed to the shell. If
|
|
|
|
|
there are no arguments, the value is @code{None}.
|
|
|
|
|
|
|
|
|
|
Either a string or a sequence of strings can be assigned to this
|
|
|
|
|
attribute. When a string is assigned, it is assumed to have any
|
|
|
|
|
necessary quoting for the shell; when a sequence is assigned, the
|
|
|
|
|
quoting is applied by @value{GDBN}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
A @code{gdb.Inferior} object has the following methods:
|
|
|
|
|
|
|
|
|
|
@defun Inferior.is_valid ()
|
|
|
|
|
Returns @code{True} if the @code{gdb.Inferior} object is valid,
|
|
|
|
|
@code{False} if not. A @code{gdb.Inferior} object will become invalid
|
|
|
|
|
if the inferior no longer exists within @value{GDBN}. All other
|
|
|
|
|
@code{gdb.Inferior} methods will throw an exception if it is invalid
|
|
|
|
|
at the time the method is called.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Inferior.threads ()
|
|
|
|
|
This method returns a tuple holding all the threads which are valid
|
|
|
|
|
when it is called. If there are no valid threads, the method will
|
|
|
|
|
return an empty tuple.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2018-10-06 22:57:19 -06:00
|
|
|
@defun Inferior.architecture ()
|
|
|
|
|
Return the @code{gdb.Architecture} (@pxref{Architectures In Python})
|
|
|
|
|
for this inferior. This represents the architecture of the inferior
|
|
|
|
|
as a whole. Some platforms can have multiple architectures in a
|
|
|
|
|
single address space, so this may not match the architecture of a
|
2018-10-09 13:57:10 -06:00
|
|
|
particular frame (@pxref{Frames In Python}).
|
2018-10-08 09:48:04 +02:00
|
|
|
@end defun
|
2018-10-06 22:57:19 -06:00
|
|
|
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
@anchor{gdbpy_inferior_read_memory}
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun Inferior.read_memory (address, length)
|
2023-06-28 09:39:37 -06:00
|
|
|
Read @var{length} addressable memory units from the inferior, starting
|
|
|
|
|
at @var{address}. Returns a @code{memoryview} object, which behaves
|
|
|
|
|
much like an array or a string. It can be modified and given to the
|
|
|
|
|
@code{Inferior.write_memory} function.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Inferior.write_memory (address, buffer @r{[}, length@r{]})
|
|
|
|
|
Write the contents of @var{buffer} to the inferior, starting at
|
|
|
|
|
@var{address}. The @var{buffer} parameter must be a Python object
|
|
|
|
|
which supports the buffer protocol, i.e., a string, an array or the
|
|
|
|
|
object returned from @code{Inferior.read_memory}. If given, @var{length}
|
2015-06-15 15:31:00 -04:00
|
|
|
determines the number of addressable memory units from @var{buffer} to be
|
|
|
|
|
written.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Inferior.search_memory (address, length, pattern)
|
|
|
|
|
Search a region of the inferior memory starting at @var{address} with
|
|
|
|
|
the given @var{length} using the search pattern supplied in
|
|
|
|
|
@var{pattern}. The @var{pattern} parameter must be a Python object
|
|
|
|
|
which supports the buffer protocol, i.e., a string, an array or the
|
|
|
|
|
object returned from @code{gdb.read_memory}. Returns a Python @code{Long}
|
|
|
|
|
containing the address where the pattern was found, or @code{None} if
|
|
|
|
|
the pattern could not be found.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2016-05-04 16:46:50 -07:00
|
|
|
@findex Inferior.thread_from_thread_handle
|
2019-03-20 20:38:33 -07:00
|
|
|
@defun Inferior.thread_from_handle (handle)
|
|
|
|
|
Return the thread object corresponding to @var{handle}, a thread
|
2016-05-04 16:46:50 -07:00
|
|
|
library specific data structure such as @code{pthread_t} for pthreads
|
|
|
|
|
library implementations.
|
2019-03-20 20:38:33 -07:00
|
|
|
|
|
|
|
|
The function @code{Inferior.thread_from_thread_handle} provides
|
|
|
|
|
the same functionality, but use of @code{Inferior.thread_from_thread_handle}
|
|
|
|
|
is deprecated.
|
2016-05-04 16:46:50 -07:00
|
|
|
@end defun
|
|
|
|
|
|
2023-05-01 13:53:59 -06:00
|
|
|
|
|
|
|
|
The environment that will be passed to the inferior can be changed
|
|
|
|
|
from Python by using the following methods. These methods only take
|
|
|
|
|
effect when the inferior is started -- they will not affect an
|
|
|
|
|
inferior that is already executing.
|
|
|
|
|
|
|
|
|
|
@defun Inferior.clear_env ()
|
|
|
|
|
Clear the current environment variables that will be passed to this
|
|
|
|
|
inferior.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Inferior.set_env (name, value)
|
|
|
|
|
Set the environment variable @var{name} to have the indicated value.
|
|
|
|
|
Both parameters must be strings.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Inferior.unset_env (name)
|
|
|
|
|
Unset the environment variable @var{name}. @var{name} must be a
|
|
|
|
|
string.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2024-01-04 16:46:40 +00:00
|
|
|
One may add arbitrary attributes to @code{gdb.Inferior} objects in the
|
|
|
|
|
usual Python way. This is useful if, for example, one needs to do
|
|
|
|
|
some extra record keeping associated with the inferior.
|
|
|
|
|
|
2024-01-10 15:42:55 +00:00
|
|
|
@anchor{choosing attribute names}
|
|
|
|
|
When selecting a name for a new attribute, avoid starting the new
|
|
|
|
|
attribute name with a lower case letter; future attributes added by
|
|
|
|
|
@value{GDBN} will start with a lower case letter. Additionally, avoid
|
|
|
|
|
starting attribute names with two underscore characters, as these
|
|
|
|
|
could clash with Python builtin attribute names.
|
|
|
|
|
|
2024-01-04 16:46:40 +00:00
|
|
|
In this contrived example we record the time when an inferior last
|
|
|
|
|
stopped:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
@group
|
|
|
|
|
(@value{GDBP}) python
|
|
|
|
|
import datetime
|
|
|
|
|
|
|
|
|
|
def thread_stopped(event):
|
|
|
|
|
if event.inferior_thread is not None:
|
|
|
|
|
thread = event.inferior_thread
|
|
|
|
|
else:
|
|
|
|
|
thread = gdb.selected_thread()
|
|
|
|
|
inferior = thread.inferior
|
|
|
|
|
inferior._last_stop_time = datetime.datetime.today()
|
|
|
|
|
|
|
|
|
|
gdb.events.stop.connect(thread_stopped)
|
|
|
|
|
@end group
|
|
|
|
|
@group
|
|
|
|
|
(@value{GDBP}) file /tmp/hello
|
|
|
|
|
Reading symbols from /tmp/hello...
|
|
|
|
|
(@value{GDBP}) start
|
|
|
|
|
Temporary breakpoint 1 at 0x401198: file /tmp/hello.c, line 18.
|
|
|
|
|
Starting program: /tmp/hello
|
|
|
|
|
|
|
|
|
|
Temporary breakpoint 1, main () at /tmp/hello.c:18
|
|
|
|
|
18 printf ("Hello World\n");
|
|
|
|
|
(@value{GDBP}) python print(gdb.selected_inferior()._last_stop_time)
|
|
|
|
|
2024-01-04 14:48:41.347036
|
|
|
|
|
@end group
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Events In Python
|
|
|
|
|
@subsubsection Events In Python
|
|
|
|
|
@cindex inferior events in Python
|
|
|
|
|
|
|
|
|
|
@value{GDBN} provides a general event facility so that Python code can be
|
|
|
|
|
notified of various state changes, particularly changes that occur in
|
|
|
|
|
the inferior.
|
|
|
|
|
|
|
|
|
|
An @dfn{event} is just an object that describes some state change. The
|
|
|
|
|
type of the object and its attributes will vary depending on the details
|
|
|
|
|
of the change. All the existing events are described below.
|
|
|
|
|
|
|
|
|
|
In order to be notified of an event, you must register an event handler
|
|
|
|
|
with an @dfn{event registry}. An event registry is an object in the
|
|
|
|
|
@code{gdb.events} module which dispatches particular events. A registry
|
|
|
|
|
provides methods to register and unregister event handlers:
|
|
|
|
|
|
|
|
|
|
@defun EventRegistry.connect (object)
|
|
|
|
|
Add the given callable @var{object} to the registry. This object will be
|
|
|
|
|
called when an event corresponding to this registry occurs.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun EventRegistry.disconnect (object)
|
|
|
|
|
Remove the given @var{object} from the registry. Once removed, the object
|
|
|
|
|
will no longer receive notifications of events.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
Here is an example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
def exit_handler (event):
|
2021-01-25 10:28:53 -05:00
|
|
|
print ("event type: exit")
|
2021-09-08 13:27:38 +01:00
|
|
|
if hasattr (event, 'exit_code'):
|
|
|
|
|
print ("exit code: %d" % (event.exit_code))
|
|
|
|
|
else:
|
|
|
|
|
print ("exit code not available")
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
gdb.events.exited.connect (exit_handler)
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
In the above example we connect our handler @code{exit_handler} to the
|
|
|
|
|
registry @code{events.exited}. Once connected, @code{exit_handler} gets
|
|
|
|
|
called when the inferior exits. The argument @dfn{event} in this example is
|
|
|
|
|
of type @code{gdb.ExitedEvent}. As you can see in the example the
|
|
|
|
|
@code{ExitedEvent} object has an attribute which indicates the exit code of
|
|
|
|
|
the inferior.
|
|
|
|
|
|
2022-02-25 11:33:32 -07:00
|
|
|
Some events can be thread specific when @value{GDBN} is running in
|
|
|
|
|
non-stop mode. When represented in Python, these events all extend
|
|
|
|
|
@code{gdb.ThreadEvent}. This event is a base class and is never
|
|
|
|
|
emitted directly; instead, events which are emitted by this or other
|
|
|
|
|
modules might extend this event. Examples of these events are
|
|
|
|
|
@code{gdb.BreakpointEvent} and @code{gdb.ContinueEvent}.
|
|
|
|
|
@code{gdb.ThreadEvent} holds the following attributes:
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@defvar ThreadEvent.inferior_thread
|
|
|
|
|
In non-stop mode this attribute will be set to the specific thread which was
|
|
|
|
|
involved in the emitted event. Otherwise, it will be set to @code{None}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2022-02-25 11:33:32 -07:00
|
|
|
The following is a listing of the event registries that are available and
|
|
|
|
|
details of the events they emit:
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2022-02-25 11:33:32 -07:00
|
|
|
@table @code
|
|
|
|
|
|
|
|
|
|
@item events.cont
|
|
|
|
|
Emits @code{gdb.ContinueEvent}, which extends @code{gdb.ThreadEvent}.
|
|
|
|
|
This event indicates that the inferior has been continued after a
|
|
|
|
|
stop. For inherited attribute refer to @code{gdb.ThreadEvent} above.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@item events.exited
|
2022-02-25 11:33:32 -07:00
|
|
|
Emits @code{events.ExitedEvent}, which indicates that the inferior has
|
|
|
|
|
exited. @code{events.ExitedEvent} has two attributes:
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar ExitedEvent.exit_code
|
|
|
|
|
An integer representing the exit code, if available, which the inferior
|
|
|
|
|
has returned. (The exit code could be unavailable if, for example,
|
|
|
|
|
@value{GDBN} detaches from the inferior.) If the exit code is unavailable,
|
|
|
|
|
the attribute does not exist.
|
|
|
|
|
@end defvar
|
2022-02-25 11:33:32 -07:00
|
|
|
|
2017-01-24 15:29:14 -05:00
|
|
|
@defvar ExitedEvent.inferior
|
2014-02-17 10:35:03 -08:00
|
|
|
A reference to the inferior which triggered the @code{exited} event.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@item events.stop
|
2022-02-25 11:33:32 -07:00
|
|
|
Emits @code{gdb.StopEvent}, which extends @code{gdb.ThreadEvent}.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2022-02-25 11:33:32 -07:00
|
|
|
Indicates that the inferior has stopped. All events emitted by this
|
|
|
|
|
registry extend @code{gdb.StopEvent}. As a child of
|
|
|
|
|
@code{gdb.ThreadEvent}, @code{gdb.StopEvent} will indicate the stopped
|
|
|
|
|
thread when @value{GDBN} is running in non-stop mode. Refer to
|
|
|
|
|
@code{gdb.ThreadEvent} above for more details.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2023-11-03 13:23:41 -06:00
|
|
|
@code{gdb.StopEvent} has the following additional attributes:
|
|
|
|
|
|
|
|
|
|
@defvar StopEvent.details
|
|
|
|
|
A dictionary holding any details relevant to the stop. The exact keys
|
|
|
|
|
and values depend on the type of stop, but are identical to the
|
|
|
|
|
corresponding MI output (@pxref{GDB/MI Async Records}).
|
|
|
|
|
|
|
|
|
|
A dictionary was used for this (rather than adding attributes directly
|
|
|
|
|
to the event object) so that the MI keys could be used unchanged.
|
2024-02-12 08:12:02 -07:00
|
|
|
|
|
|
|
|
When a @code{StopEvent} results from a @code{finish} command, it will
|
|
|
|
|
also hold the return value from the function, if that is available.
|
|
|
|
|
This will be an entry named @samp{return-value} in the @code{details}
|
|
|
|
|
dictionary. The value of this entry will be a @code{gdb.Value}
|
|
|
|
|
object.
|
2023-11-03 13:23:41 -06:00
|
|
|
@end defvar
|
|
|
|
|
|
2022-02-25 11:33:32 -07:00
|
|
|
Emits @code{gdb.SignalEvent}, which extends @code{gdb.StopEvent}.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2022-02-25 11:33:32 -07:00
|
|
|
This event indicates that the inferior or one of its threads has
|
|
|
|
|
received a signal. @code{gdb.SignalEvent} has the following
|
|
|
|
|
attributes:
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@defvar SignalEvent.stop_signal
|
|
|
|
|
A string representing the signal received by the inferior. A list of possible
|
|
|
|
|
signal values can be obtained by running the command @code{info signals} in
|
|
|
|
|
the @value{GDBN} command prompt.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2022-02-25 11:33:32 -07:00
|
|
|
Also emits @code{gdb.BreakpointEvent}, which extends
|
|
|
|
|
@code{gdb.StopEvent}.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@code{gdb.BreakpointEvent} event indicates that one or more breakpoints have
|
|
|
|
|
been hit, and has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar BreakpointEvent.breakpoints
|
|
|
|
|
A sequence containing references to all the breakpoints (type
|
|
|
|
|
@code{gdb.Breakpoint}) that were hit.
|
|
|
|
|
@xref{Breakpoints In Python}, for details of the @code{gdb.Breakpoint} object.
|
|
|
|
|
@end defvar
|
2022-02-25 11:33:32 -07:00
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar BreakpointEvent.breakpoint
|
2022-06-09 09:40:51 -06:00
|
|
|
A reference to the first breakpoint that was hit. This attribute is
|
|
|
|
|
maintained for backward compatibility and is now deprecated in favor
|
|
|
|
|
of the @code{gdb.BreakpointEvent.breakpoints} attribute.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@item events.new_objfile
|
|
|
|
|
Emits @code{gdb.NewObjFileEvent} which indicates that a new object file has
|
|
|
|
|
been loaded by @value{GDBN}. @code{gdb.NewObjFileEvent} has one attribute:
|
|
|
|
|
|
|
|
|
|
@defvar NewObjFileEvent.new_objfile
|
|
|
|
|
A reference to the object file (@code{gdb.Objfile}) which has been loaded.
|
|
|
|
|
@xref{Objfiles In Python}, for details of the @code{gdb.Objfile} object.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2022-06-20 11:30:04 -06:00
|
|
|
@item events.free_objfile
|
|
|
|
|
Emits @code{gdb.FreeObjFileEvent} which indicates that an object file
|
|
|
|
|
is about to be removed from @value{GDBN}. One reason this can happen
|
|
|
|
|
is when the inferior calls @code{dlclose}.
|
|
|
|
|
@code{gdb.FreeObjFileEvent} has one attribute:
|
|
|
|
|
|
2023-08-04 09:51:54 -06:00
|
|
|
@defvar FreeObjFileEvent.objfile
|
2022-06-20 11:30:04 -06:00
|
|
|
A reference to the object file (@code{gdb.Objfile}) which will be unloaded.
|
|
|
|
|
@xref{Objfiles In Python}, for details of the @code{gdb.Objfile} object.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-10-17 11:12:17 -07:00
|
|
|
@item events.clear_objfiles
|
|
|
|
|
Emits @code{gdb.ClearObjFilesEvent} which indicates that the list of object
|
|
|
|
|
files for a program space has been reset.
|
|
|
|
|
@code{gdb.ClearObjFilesEvent} has one attribute:
|
|
|
|
|
|
|
|
|
|
@defvar ClearObjFilesEvent.progspace
|
|
|
|
|
A reference to the program space (@code{gdb.Progspace}) whose objfile list has
|
|
|
|
|
been cleared. @xref{Progspaces In Python}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2018-09-08 10:59:14 -06:00
|
|
|
@item events.inferior_call
|
|
|
|
|
Emits events just before and after a function in the inferior is
|
|
|
|
|
called by @value{GDBN}. Before an inferior call, this emits an event
|
|
|
|
|
of type @code{gdb.InferiorCallPreEvent}, and after an inferior call,
|
|
|
|
|
this emits an event of type @code{gdb.InferiorCallPostEvent}.
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@tindex gdb.InferiorCallPreEvent
|
|
|
|
|
@item @code{gdb.InferiorCallPreEvent}
|
|
|
|
|
Indicates that a function in the inferior is about to be called.
|
New python events: inferior call, register/memory changed.
gdb/ChangeLog:
* NEWS: Mention new Python events.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-infevents.o.
(SUBDIR_PYTHON_SRCS): Add py-infevents.c.
(py-infevents.o): New rule.
* doc/observer.texi (inferior_call_pre, inferior_call_post)
(memory_changed, register_changed): New observers.
* infcall.c (call_function_by_hand): Notify observer before and
after inferior call.
* python/py-event.h (inferior_call_kind): New enum.
(emit_inferior_call_event): New prototype.
(emit_register_changed_event): New prototype.
(emit_memory_changed_event): New prototype.
* python/py-events.h (events_object): New registries
inferior_call, memory_changed and register_changed.
* python/py-evts.c (gdbpy_initialize_py_events): Add the
inferior_call, memory_changed and register_changed registries.
* python/py-infevents.c: New.
* python/py-inferior.c (python_on_inferior_call_pre)
(python_on_inferior_call_post, python_on_register_change)
(python_on_memory_change): New functions.
(gdbpy_initialize_inferior): Attach python handler to new
observers.
* python/py-infthread.c(gdbpy_create_ptid_object): New.
(thpy_get_ptid) Use gdbpy_create_ptid_object.
* python/python-internal.h:
(gdbpy_create_ptid_object)
(gdbpy_initialize_inferior_call_pre_event)
(gdbpy_initialize_inferior_call_post_event)
(gdbpy_initialize_register_changed_event)
(gdbpy_initialize_memory_changed_event): New prototypes.
* python/python.c (_initialize_python): Initialize new events.
* valops.c (value_assign): Notify register_changed observer.
gdb/doc/ChangeLog:
* python.texi (Events In Python): Document new events
InferiorCallPreEvent, InferiorCallPostEvent, MemoryChangedEvent
and RegisterChangedEvent.
gdb/testsuite/ChangeLog:
* gdb.python/py-events.py (inferior_call_handler): New.
(register_changed_handler, memory_changed_handler): New.
(test_events.invoke): Register new handlers.
* gdb.python/py-events.exp: Add tests for inferior call,
memory_changed and register_changed events.
2014-12-02 11:15:29 -08:00
|
|
|
|
|
|
|
|
@defvar InferiorCallPreEvent.ptid
|
|
|
|
|
The thread in which the call will be run.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar InferiorCallPreEvent.address
|
|
|
|
|
The location of the function to be called.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2018-09-08 10:59:14 -06:00
|
|
|
@tindex gdb.InferiorCallPostEvent
|
|
|
|
|
@item @code{gdb.InferiorCallPostEvent}
|
|
|
|
|
Indicates that a function in the inferior has just been called.
|
New python events: inferior call, register/memory changed.
gdb/ChangeLog:
* NEWS: Mention new Python events.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-infevents.o.
(SUBDIR_PYTHON_SRCS): Add py-infevents.c.
(py-infevents.o): New rule.
* doc/observer.texi (inferior_call_pre, inferior_call_post)
(memory_changed, register_changed): New observers.
* infcall.c (call_function_by_hand): Notify observer before and
after inferior call.
* python/py-event.h (inferior_call_kind): New enum.
(emit_inferior_call_event): New prototype.
(emit_register_changed_event): New prototype.
(emit_memory_changed_event): New prototype.
* python/py-events.h (events_object): New registries
inferior_call, memory_changed and register_changed.
* python/py-evts.c (gdbpy_initialize_py_events): Add the
inferior_call, memory_changed and register_changed registries.
* python/py-infevents.c: New.
* python/py-inferior.c (python_on_inferior_call_pre)
(python_on_inferior_call_post, python_on_register_change)
(python_on_memory_change): New functions.
(gdbpy_initialize_inferior): Attach python handler to new
observers.
* python/py-infthread.c(gdbpy_create_ptid_object): New.
(thpy_get_ptid) Use gdbpy_create_ptid_object.
* python/python-internal.h:
(gdbpy_create_ptid_object)
(gdbpy_initialize_inferior_call_pre_event)
(gdbpy_initialize_inferior_call_post_event)
(gdbpy_initialize_register_changed_event)
(gdbpy_initialize_memory_changed_event): New prototypes.
* python/python.c (_initialize_python): Initialize new events.
* valops.c (value_assign): Notify register_changed observer.
gdb/doc/ChangeLog:
* python.texi (Events In Python): Document new events
InferiorCallPreEvent, InferiorCallPostEvent, MemoryChangedEvent
and RegisterChangedEvent.
gdb/testsuite/ChangeLog:
* gdb.python/py-events.py (inferior_call_handler): New.
(register_changed_handler, memory_changed_handler): New.
(test_events.invoke): Register new handlers.
* gdb.python/py-events.exp: Add tests for inferior call,
memory_changed and register_changed events.
2014-12-02 11:15:29 -08:00
|
|
|
|
|
|
|
|
@defvar InferiorCallPostEvent.ptid
|
|
|
|
|
The thread in which the call was run.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar InferiorCallPostEvent.address
|
|
|
|
|
The location of the function that was called.
|
|
|
|
|
@end defvar
|
2018-09-08 10:59:14 -06:00
|
|
|
@end table
|
New python events: inferior call, register/memory changed.
gdb/ChangeLog:
* NEWS: Mention new Python events.
* Makefile.in (SUBDIR_PYTHON_OBS): Add py-infevents.o.
(SUBDIR_PYTHON_SRCS): Add py-infevents.c.
(py-infevents.o): New rule.
* doc/observer.texi (inferior_call_pre, inferior_call_post)
(memory_changed, register_changed): New observers.
* infcall.c (call_function_by_hand): Notify observer before and
after inferior call.
* python/py-event.h (inferior_call_kind): New enum.
(emit_inferior_call_event): New prototype.
(emit_register_changed_event): New prototype.
(emit_memory_changed_event): New prototype.
* python/py-events.h (events_object): New registries
inferior_call, memory_changed and register_changed.
* python/py-evts.c (gdbpy_initialize_py_events): Add the
inferior_call, memory_changed and register_changed registries.
* python/py-infevents.c: New.
* python/py-inferior.c (python_on_inferior_call_pre)
(python_on_inferior_call_post, python_on_register_change)
(python_on_memory_change): New functions.
(gdbpy_initialize_inferior): Attach python handler to new
observers.
* python/py-infthread.c(gdbpy_create_ptid_object): New.
(thpy_get_ptid) Use gdbpy_create_ptid_object.
* python/python-internal.h:
(gdbpy_create_ptid_object)
(gdbpy_initialize_inferior_call_pre_event)
(gdbpy_initialize_inferior_call_post_event)
(gdbpy_initialize_register_changed_event)
(gdbpy_initialize_memory_changed_event): New prototypes.
* python/python.c (_initialize_python): Initialize new events.
* valops.c (value_assign): Notify register_changed observer.
gdb/doc/ChangeLog:
* python.texi (Events In Python): Document new events
InferiorCallPreEvent, InferiorCallPostEvent, MemoryChangedEvent
and RegisterChangedEvent.
gdb/testsuite/ChangeLog:
* gdb.python/py-events.py (inferior_call_handler): New.
(register_changed_handler, memory_changed_handler): New.
(test_events.invoke): Register new handlers.
* gdb.python/py-events.exp: Add tests for inferior call,
memory_changed and register_changed events.
2014-12-02 11:15:29 -08:00
|
|
|
|
|
|
|
|
@item events.memory_changed
|
|
|
|
|
Emits @code{gdb.MemoryChangedEvent} which indicates that the memory of the
|
|
|
|
|
inferior has been modified by the @value{GDBN} user, for instance via a
|
|
|
|
|
command like @w{@code{set *addr = value}}. The event has the following
|
|
|
|
|
attributes:
|
|
|
|
|
|
|
|
|
|
@defvar MemoryChangedEvent.address
|
|
|
|
|
The start address of the changed region.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar MemoryChangedEvent.length
|
|
|
|
|
Length in bytes of the changed region.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@item events.register_changed
|
|
|
|
|
Emits @code{gdb.RegisterChangedEvent} which indicates that a register in the
|
|
|
|
|
inferior has been modified by the @value{GDBN} user.
|
|
|
|
|
|
|
|
|
|
@defvar RegisterChangedEvent.frame
|
|
|
|
|
A gdb.Frame object representing the frame in which the register was modified.
|
|
|
|
|
@end defvar
|
|
|
|
|
@defvar RegisterChangedEvent.regnum
|
|
|
|
|
Denotes which register was modified.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
PR python/15620, PR python/18620 - breakpoint events in Python
This patch adds some breakpoint events to Python. In particular,
there is a creation event that is emitted when a breakpoint is
created; a modification event that is emitted when a breakpoint
changes somehow; and a deletion event that is emitted when a
breakpoint is deleted.
In this patch, the event's payload is the breakpoint itself. I
considered making a new event type to hold the breakpoint, but I
didn't see a need. Still, I thought I would mention this as a spot
where some other choice is possible.
Built and regtested on x86-64 Fedora 23.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/15620, PR python/18620:
* python/py-evts.c (gdbpy_initialize_py_events): Call
add_new_registry for new events.
* python/py-events.h (events_object) <breakpoint_created,
breakpoint_deleted, breakpoint_modified>: New fields.
* python/py-breakpoint.c (gdbpy_breakpoint_created): Emit the
breakpoint changed event.
(gdbpy_breakpoint_deleted): Emit the breakpoint deleted event.
(gdbpy_breakpoint_modified): New function.
(gdbpy_initialize_breakpoints): Attach to the breakpoint modified
observer.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/15620, PR python/18620:
* python.texi (Events In Python): Document new breakpoint events.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/15620, PR python/18620:
* gdb.python/py-breakpoint.exp (connect_event, check_last_event)
(test_bkpt_events): New procs.
2015-05-04 21:49:11 -06:00
|
|
|
@item events.breakpoint_created
|
|
|
|
|
This is emitted when a new breakpoint has been created. The argument
|
|
|
|
|
that is passed is the new @code{gdb.Breakpoint} object.
|
|
|
|
|
|
|
|
|
|
@item events.breakpoint_modified
|
|
|
|
|
This is emitted when a breakpoint has been modified in some way. The
|
|
|
|
|
argument that is passed is the new @code{gdb.Breakpoint} object.
|
|
|
|
|
|
|
|
|
|
@item events.breakpoint_deleted
|
|
|
|
|
This is emitted when a breakpoint has been deleted. The argument that
|
|
|
|
|
is passed is the @code{gdb.Breakpoint} object. When this event is
|
|
|
|
|
emitted, the @code{gdb.Breakpoint} object will already be in its
|
|
|
|
|
invalid state; that is, the @code{is_valid} method will return
|
|
|
|
|
@code{False}.
|
|
|
|
|
|
2015-04-29 09:44:24 -06:00
|
|
|
@item events.before_prompt
|
|
|
|
|
This event carries no payload. It is emitted each time @value{GDBN}
|
|
|
|
|
presents a prompt to the user.
|
|
|
|
|
|
Add new_inferior, inferior_deleted, and new_thread events
This adds a few new events to gdb's Python layer: new_inferior,
inferior_deleted, and new_thread. I wanted to be able to add a
combined inferior/thread display window to my GUI, and I needed a few
events to make this work. This is PR python/15622.
ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
PR python/15622:
* NEWS: Add entry.
* python/python.c (do_start_initialization): Initialize new event
types.
* python/python-internal.h (gdbpy_initialize_new_inferior_event)
(gdbpy_initialize_inferior_deleted_event)
(gdbpy_initialize_new_thread_event): Declare.
* python/py-threadevent.c (create_thread_event_object): Add option
"thread" parameter.
* python/py-inferior.c (new_thread_event_object_type)
(new_inferior_event_object_type)
(inferior_deleted_event_object_type): Declare.
(python_new_inferior, python_inferior_deleted): New functions.
(add_thread_object): Emit new_thread event.
(gdbpy_initialize_inferior): Attach new functions to corresponding
observers.
(new_thread, new_inferior, inferior_deleted): Define new event
types.
* python/py-evts.c (gdbpy_initialize_py_events): Add new
registries.
* python/py-events.h (events_object) <new_inferior,
inferior_deleted, new_thread>: New fields.
* python/py-event.h (create_thread_event_breakpoint): Add optional
"thread" parameter.
doc/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* python.texi (Events In Python): Document new events.
testsuite/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* gdb.python/py-infthread.exp: Add tests for new_thread event.
* gdb.python/py-inferior.exp: Add tests for new inferior events.
2017-09-05 12:07:00 -06:00
|
|
|
@item events.new_inferior
|
|
|
|
|
This is emitted when a new inferior is created. Note that the
|
|
|
|
|
inferior is not necessarily running; in fact, it may not even have an
|
|
|
|
|
associated executable.
|
|
|
|
|
|
|
|
|
|
The event is of type @code{gdb.NewInferiorEvent}. This has a single
|
|
|
|
|
attribute:
|
|
|
|
|
|
|
|
|
|
@defvar NewInferiorEvent.inferior
|
|
|
|
|
The new inferior, a @code{gdb.Inferior} object.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@item events.inferior_deleted
|
|
|
|
|
This is emitted when an inferior has been deleted. Note that this is
|
|
|
|
|
not the same as process exit; it is notified when the inferior itself
|
|
|
|
|
is removed, say via @code{remove-inferiors}.
|
|
|
|
|
|
|
|
|
|
The event is of type @code{gdb.InferiorDeletedEvent}. This has a single
|
|
|
|
|
attribute:
|
|
|
|
|
|
2022-02-25 11:33:32 -07:00
|
|
|
@defvar InferiorDeletedEvent.inferior
|
Add new_inferior, inferior_deleted, and new_thread events
This adds a few new events to gdb's Python layer: new_inferior,
inferior_deleted, and new_thread. I wanted to be able to add a
combined inferior/thread display window to my GUI, and I needed a few
events to make this work. This is PR python/15622.
ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
PR python/15622:
* NEWS: Add entry.
* python/python.c (do_start_initialization): Initialize new event
types.
* python/python-internal.h (gdbpy_initialize_new_inferior_event)
(gdbpy_initialize_inferior_deleted_event)
(gdbpy_initialize_new_thread_event): Declare.
* python/py-threadevent.c (create_thread_event_object): Add option
"thread" parameter.
* python/py-inferior.c (new_thread_event_object_type)
(new_inferior_event_object_type)
(inferior_deleted_event_object_type): Declare.
(python_new_inferior, python_inferior_deleted): New functions.
(add_thread_object): Emit new_thread event.
(gdbpy_initialize_inferior): Attach new functions to corresponding
observers.
(new_thread, new_inferior, inferior_deleted): Define new event
types.
* python/py-evts.c (gdbpy_initialize_py_events): Add new
registries.
* python/py-events.h (events_object) <new_inferior,
inferior_deleted, new_thread>: New fields.
* python/py-event.h (create_thread_event_breakpoint): Add optional
"thread" parameter.
doc/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* python.texi (Events In Python): Document new events.
testsuite/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* gdb.python/py-infthread.exp: Add tests for new_thread event.
* gdb.python/py-inferior.exp: Add tests for new inferior events.
2017-09-05 12:07:00 -06:00
|
|
|
The inferior that is being removed, a @code{gdb.Inferior} object.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@item events.new_thread
|
|
|
|
|
This is emitted when @value{GDBN} notices a new thread. The event is of
|
|
|
|
|
type @code{gdb.NewThreadEvent}, which extends @code{gdb.ThreadEvent}.
|
|
|
|
|
This has a single attribute:
|
|
|
|
|
|
|
|
|
|
@defvar NewThreadEvent.inferior_thread
|
|
|
|
|
The new thread.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/Python: Added ThreadExitedEvent
v6:
Fix comments.
Fix copyright
Remove unnecessary test suite stuff. save_var had to stay, as it mutates
some test suite state that otherwise fails.
v5:
Did what Tom Tromey requested in v4; which can be found here: https://pi.simark.ca/gdb-patches/87pmjm0xar.fsf@tromey.com/
v4:
Doc formatting fixed.
v3:
Eli:
Updated docs & NEWS to reflect new changes. Added
a reference from the .ptid attribute of the ThreadExitedEvent
to the ptid attribute of InferiorThread. To do this,
I've added an anchor to that attribute.
Tom:
Tom requested that I should probably just emit the thread object;
I ran into two issues for this, which I could not resolve in this patch;
1 - The Thread Object (the python type) checks it's own validity
by doing a comparison of it's `thread_info* thread` to nullptr. This
means that any access of it's attributes may (probably, since we are
in "async" land) throw Python exceptions because the thread has been
removed from the thread object. Therefore I've decided in v3 of this
patch to just emit most of the same fields that gdb.InferiorThread has, namely
global_num, name, num and ptid (the 3-attribute tuple provided by
gdb.InferiorThread.ptid).
2 - A python user can hold a global reference to an exiting thread. Thus
in order to have a ThreadExit event that can provide attribute access
reliably (both as a global reference, but also inside the thread exit
handler, as we can never guarantee that it's executed _before_ the
thread_info pointer is removed from the gdbpy thread object),
the `thread_info *` thread pointer must not be null. However, this
comes at the cost of gdb.InferiorThread believing it is "valid" - which means,
that if a user holds takes a global reference to that
exiting event thread object, they can some time later do `t.switch()` at which
point GDB will 'explode' so to speak.
v2:
Fixed white space issues and NULL/nullptr stuff,
as requested by Tom Tromey.
v1:
Currently no event is emitted for a thread exit.
This adds this functionality by emitting a new gdb.ThreadExitedEvent.
It currently provides four attributes:
- global_num: The GDB assigned global thread number
- num: the per-inferior thread number
- name: name of the thread or none if not set
- ptid: the PTID of the thread, a 3-attribute tuple, identical to
InferiorThread.ptid attribute
Added info to docs & the NEWS file as well.
Added test to test suite.
Fixed formatting.
Feedback wanted and appreciated.
2022-04-20 10:25:47 +02:00
|
|
|
@item events.thread_exited
|
|
|
|
|
This is emitted when @value{GDBN} notices a thread has exited. The event
|
|
|
|
|
is of type @code{gdb.ThreadExitedEvent} which extends @code{gdb.ThreadEvent}.
|
|
|
|
|
This has a single attribute:
|
|
|
|
|
|
|
|
|
|
@defvar ThreadExitedEvent.inferior_thread
|
|
|
|
|
The exiting thread.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/python: add a new gdb_exiting event
Add a new event, gdb.events.gdb_exiting, which is called once GDB
decides it is going to exit.
This event is not triggered in the case that GDB performs a hard
abort, for example, when handling an internal error and the user
decides to quit the debug session, or if GDB hits an unexpected,
fatal, signal.
This event is triggered if the user just types 'quit' at the command
prompt, or if GDB is run with '-batch' and has processed all of the
required commands.
The new event type is gdb.GdbExitingEvent, and it has a single
attribute exit_code, which is the value that GDB is about to exit
with.
The event is triggered before GDB starts dismantling any of its own
internal state, so, my expectation is that most Python calls should
work just fine at this point.
When considering this functionality I wondered about using the
'atexit' Python module. However, this is triggered when the Python
environment is shut down, which is done from a final cleanup. At
this point we don't know for sure what other GDB state has already
been cleaned up.
2021-09-07 11:45:55 +01:00
|
|
|
@item events.gdb_exiting
|
|
|
|
|
This is emitted when @value{GDBN} exits. This event is not emitted if
|
|
|
|
|
@value{GDBN} exits as a result of an internal error, or after an
|
|
|
|
|
unexpected signal. The event is of type @code{gdb.GdbExitingEvent},
|
|
|
|
|
which has a single attribute:
|
|
|
|
|
|
|
|
|
|
@defvar GdbExitingEvent.exit_code
|
|
|
|
|
An integer, the value of the exit code @value{GDBN} will return.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/python: introduce gdb.TargetConnection object type
This commit adds a new object type gdb.TargetConnection. This new
type represents a connection within GDB (a connection as displayed by
'info connections').
There's three ways to find a gdb.TargetConnection, there's a new
'gdb.connections()' function, which returns a list of all currently
active connections.
Or you can read the new 'connection' property on the gdb.Inferior
object type, this contains the connection for that inferior (or None
if the inferior has no connection, for example, it is exited).
Finally, there's a new gdb.events.connection_removed event registry,
this emits a new gdb.ConnectionEvent whenever a connection is removed
from GDB (this can happen when all inferiors using a connection exit,
though this is not always the case, depending on the connection type).
The gdb.ConnectionEvent has a 'connection' property, which is the
gdb.TargetConnection being removed from GDB.
The gdb.TargetConnection has an 'is_valid()' method. A connection
object becomes invalid when the underlying connection is removed from
GDB (as discussed above, this might be when all inferiors using a
connection exit, or it might be when the user explicitly replaces a
connection in GDB by issuing another 'target' command).
The gdb.TargetConnection has the following read-only properties:
'num': The number for this connection,
'type': e.g. 'native', 'remote', 'sim', etc
'description': The longer description as seen in the 'info
connections' command output.
'details': A string or None. Extra details for the connection, for
example, a remote connection's details might be
'hostname:port'.
2021-09-01 15:33:19 +01:00
|
|
|
@item events.connection_removed
|
|
|
|
|
This is emitted when @value{GDBN} removes a connection
|
|
|
|
|
(@pxref{Connections In Python}). The event is of type
|
|
|
|
|
@code{gdb.ConnectionEvent}. This has a single read-only attribute:
|
|
|
|
|
|
|
|
|
|
@defvar ConnectionEvent.connection
|
|
|
|
|
The @code{gdb.TargetConnection} that is being removed.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/python: make the executable_changed event available from Python
This commit makes the executable_changed observable available through
the Python API as an event. There's nothing particularly interesting
going on here, it just follows the same pattern as many of the other
Python events we support.
The new event registry is called events.executable_changed, and this
emits an ExecutableChangedEvent object which has two attributes, a
gdb.Progspace called 'progspace', this is the program space in which
the executable changed, and a Boolean called 'reload', which is True
if the same executable changed on disk and has been reloaded, or is
False when a new executable has been loaded.
One interesting thing did come up during testing though, you'll notice
the test contains a setup_kfail call. During testing I observed that
the executable_changed event would trigger twice when GDB restarted an
inferior. However, the ExecutableChangedEvent object is identical for
both calls, so the wrong information is never sent out, we just see
one too many events.
I tracked this down to how the reload_symbols function (symfile.c)
takes care to also reload the executable, however, I've split fixing
this into a separate commit, so see the next commit for details.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
2023-08-28 16:22:36 +01:00
|
|
|
@item events.executable_changed
|
|
|
|
|
Emits @code{gdb.ExecutableChangedEvent} which indicates that the
|
|
|
|
|
@code{gdb.Progspace.executable_filename} has changed.
|
|
|
|
|
|
|
|
|
|
This event is emitted when either the value of
|
|
|
|
|
@code{gdb.Progspace.executable_filename } has changed to name a
|
|
|
|
|
different file, or the executable file named by
|
|
|
|
|
@code{gdb.Progspace.executable_filename} has changed on disk, and
|
|
|
|
|
@value{GDBN} has therefore reloaded it.
|
|
|
|
|
|
|
|
|
|
@defvar ExecutableChangedEvent.progspace
|
|
|
|
|
The @code{gdb.Progspace} in which the current executable has changed.
|
|
|
|
|
The file name of the updated executable will be visible in
|
|
|
|
|
@code{gdb.Progspace.executable_filename} (@pxref{Progspaces In Python}).
|
|
|
|
|
@end defvar
|
|
|
|
|
@defvar ExecutableChangedEvent.reload
|
|
|
|
|
This attribute will be @code{True} if the value of
|
|
|
|
|
@code{gdb.Progspace.executable_filename} didn't change, but the file
|
|
|
|
|
it names changed on disk instead, and @value{GDBN} reloaded it.
|
|
|
|
|
|
|
|
|
|
When this attribute is @code{False}, the value in
|
|
|
|
|
@code{gdb.Progspace.executable_filename} was changed to name a
|
|
|
|
|
different file.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
Remember that @value{GDBN} tracks the executable file and the symbol
|
|
|
|
|
file separately, these are visible as
|
|
|
|
|
@code{gdb.Progspace.executable_filename} and
|
|
|
|
|
@code{gdb.Progspace.filename} respectively. When using the @kbd{file}
|
|
|
|
|
command, @value{GDBN} updates both of these fields, but the executable
|
|
|
|
|
file is updated first, so when this event is emitted, the executable
|
|
|
|
|
filename will have changed, but the symbol filename might still hold
|
|
|
|
|
its previous value.
|
gdb: add Python events for program space addition and removal
Initially I just wanted a Python event for when GDB removes a program
space, I'm writing a Python extension that caches information for each
program space, and need to know when I should discard entries for a
particular program space.
But, it seemed easy enough to also add an event for when GDB adds a
new program space, so I went ahead and added both new events.
Of course, we don't currently have an observable for program space
addition or removal, so I first needed to add these. After that it's
pretty simple to add two new Python events and have these trigger.
The two new event registries are:
events.new_progspace
events.free_progspace
These emit NewProgspaceEvent and FreeProgspaceEvent objects
respectively, each of these new event types has a 'progspace'
attribute that contains the relevant gdb.Progspace object.
There's a couple of things to be mindful of.
First, it is not possible to catch the NewProgspaceEvent for the very
first program space, the one that is created when GDB first starts, as
this program space is created before any Python scripts are sourced.
In order to allow this event to be caught we would need to defer
creating the first program space, and as a consequence the first
inferior, until some later time. But, existing scripts could easily
depend on there being an initial inferior, so I really don't think we
should change that -- and so, we end up with the consequence that we
can't catch the event for the first program space.
The second, I think minor, issue, is that GDB doesn't clean up its
program spaces upon exit -- or at least, they are not cleaned up
before Python is shut down. As a result, any program spaces in use at
the time GDB exits don't generate a FreeProgspaceEvent. I'm not
particularly worried about this for my use case, I'm using the event
to ensure that a cache doesn't hold stale entries within a single GDB
session. It's also easy enough to add a Python at-exit callback which
can do any final cleanup if needed.
Finally, when testing, I did hit a slightly weird issue with some of
the remote boards (e.g. remote-stdio-gdbserver). As a consequence of
this issue I see some output like this in the gdb.log:
(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
step
FreeProgspaceEvent: <gdb.Progspace object at 0x7fb7e1d19c10>
warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target
and then try again.
warning: cannot close "target:/lib64/libc.so.6": Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target
and then try again.
warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target
and then try again.
do_parent_stuff () at py-progspace-events.c:41
41 ++global_var;
(gdb) PASS: gdb.python/py-progspace-events.exp: step
The 'FreeProgspaceEvent ...' line is expected, that's my test Python
extension logging the event. What isn't expected are all the blocks
like:
warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target
and then try again.
It turns out that this has nothing to do with my changes, this is just
a consequence of reading files over the remote protocol. The test
forks a child process which GDB stays attached too. When the child
exits, GDB cleans up by calling prune_inferiors, which in turn can
result in GDB trying to close some files that are open because of the
inferior being deleted.
If the prune_inferiors call occurs when the remote target is
running (and in non-async mode) then GDB will try to send a fileio
packet while the remote target is waiting for a stop reply, and the
remote target will throw an error, see remote_target::putpkt_binary in
remote.c for details.
I'm going to look at fixing this, but, as I said, this is nothing to
do with this change, I just mention it because I ended up needing to
account for these warning messages in one of my tests, and it all
looks a bit weird.
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-09-19 11:45:36 +01:00
|
|
|
|
|
|
|
|
@item events.new_progspace
|
|
|
|
|
This is emitted when @value{GDBN} adds a new program space
|
|
|
|
|
(@pxref{Progspaces In Python,,Program Spaces In Python}). The event
|
|
|
|
|
is of type @code{gdb.NewProgspaceEvent}, and has a single read-only
|
|
|
|
|
attribute:
|
|
|
|
|
|
|
|
|
|
@defvar NewProgspaceEvent.progspace
|
|
|
|
|
The @code{gdb.Progspace} that was added to @value{GDBN}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
No @code{NewProgspaceEvent} is emitted for the very first program
|
|
|
|
|
space, which is assigned to the first inferior. This first program
|
|
|
|
|
space is created within @value{GDBN} before any Python scripts are
|
|
|
|
|
sourced.
|
|
|
|
|
|
|
|
|
|
@item events.free_progspace
|
|
|
|
|
This is emitted when @value{GDBN} removes a program space
|
|
|
|
|
(@pxref{Progspaces In Python,,Program Spaces In Python}), for example
|
|
|
|
|
as a result of the @kbd{remove-inferiors} command
|
|
|
|
|
(@pxref{remove_inferiors_cli,,@kbd{remove-inferiors}}). The event is
|
|
|
|
|
of type @code{gdb.FreeProgspaceEvent}, and has a single read-only
|
|
|
|
|
attribute:
|
|
|
|
|
|
|
|
|
|
@defvar FreeProgspaceEvent.progspace
|
|
|
|
|
The @code{gdb.Progspace} that is about to be removed from
|
|
|
|
|
@value{GDBN}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2024-09-25 08:27:51 -06:00
|
|
|
@item events.tui_enabled
|
|
|
|
|
This is emitted when the TUI is enabled or disabled. The event is of
|
|
|
|
|
type @code{gdb.TuiEnabledEvent}, which has a single read-only
|
|
|
|
|
attribute:
|
|
|
|
|
|
2024-12-18 08:34:31 -07:00
|
|
|
@defvar TuiEnabledEvent.enabled
|
2024-09-25 08:27:51 -06:00
|
|
|
If the TUI has just been enabled, this is @code{True}; otherwise it is
|
|
|
|
|
@code{False}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@end table
|
|
|
|
|
|
|
|
|
|
@node Threads In Python
|
|
|
|
|
@subsubsection Threads In Python
|
|
|
|
|
@cindex threads in python
|
|
|
|
|
|
|
|
|
|
@findex gdb.InferiorThread
|
|
|
|
|
Python scripts can access information about, and manipulate inferior threads
|
|
|
|
|
controlled by @value{GDBN}, via objects of the @code{gdb.InferiorThread} class.
|
|
|
|
|
|
|
|
|
|
The following thread-related functions are available in the @code{gdb}
|
|
|
|
|
module:
|
|
|
|
|
|
|
|
|
|
@defun gdb.selected_thread ()
|
|
|
|
|
This function returns the thread object for the selected thread. If there
|
|
|
|
|
is no selected thread, this will return @code{None}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2019-10-22 18:17:24 -05:00
|
|
|
To get the list of threads for an inferior, use the @code{Inferior.threads()}
|
2020-04-15 09:44:12 +02:00
|
|
|
method. @xref{Inferiors In Python}.
|
2019-10-22 18:17:24 -05:00
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
A @code{gdb.InferiorThread} object has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar InferiorThread.name
|
|
|
|
|
The name of the thread. If the user specified a name using
|
|
|
|
|
@code{thread name}, then this returns that name. Otherwise, if an
|
|
|
|
|
OS-supplied name is available, then it is returned. Otherwise, this
|
|
|
|
|
returns @code{None}.
|
|
|
|
|
|
|
|
|
|
This attribute can be assigned to. The new value must be a string
|
|
|
|
|
object, which sets the new name, or @code{None}, which removes any
|
|
|
|
|
user-specified thread name.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar InferiorThread.num
|
Per-inferior/Inferior-qualified thread IDs
This commit changes GDB to track thread numbers per-inferior. Then,
if you're debugging multiple inferiors, GDB displays
"inferior-num.thread-num" instead of just "thread-num" whenever it
needs to display a thread:
(gdb) info inferiors
Num Description Executable
1 process 6022 /home/pedro/gdb/tests/threads
* 2 process 6037 /home/pedro/gdb/tests/threads
(gdb) info threads
Id Target Id Frame
1.1 Thread 0x7ffff7fc2740 (LWP 6022) "threads" (running)
1.2 Thread 0x7ffff77c0700 (LWP 6028) "threads" (running)
1.3 Thread 0x7ffff7fc2740 (LWP 6032) "threads" (running)
2.1 Thread 0x7ffff7fc1700 (LWP 6037) "threads" (running)
2.2 Thread 0x7ffff77c0700 (LWP 6038) "threads" (running)
* 2.3 Thread 0x7ffff7fc2740 (LWP 6039) "threads" (running)
(gdb)
...
(gdb) thread 1.1
[Switching to thread 1.1 (Thread 0x7ffff7fc2740 (LWP 8155))]
(gdb)
...
etc.
You can still use "thread NUM", in which case GDB infers you're
referring to thread NUM of the current inferior.
The $_thread convenience var and Python's InferiorThread.num attribute
are remapped to the new per-inferior thread number. It's a backward
compatibility break, but since it only matters when debugging multiple
inferiors, I think it's worth doing.
Because MI thread IDs need to be a single integer, we keep giving
threads a global identifier, _in addition_ to the per-inferior number,
and make MI always refer to the global thread IDs. IOW, nothing
changes from a MI frontend's perspective.
Similarly, since Python's Breakpoint.thread and Guile's
breakpoint-thread/set-breakpoint-thread breakpoint methods need to
work with integers, those are adjusted to work with global thread IDs
too. Follow up patches will provide convenient means to access
threads' global IDs.
To avoid potencially confusing users (which also avoids updating much
of the testsuite), if there's only one inferior and its ID is "1",
IOW, the user hasn't done anything multi-process/inferior related,
then the "INF." part of thread IDs is not shown. E.g,.:
(gdb) info inferiors
Num Description Executable
* 1 process 15275 /home/pedro/gdb/tests/threads
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fc1740 (LWP 15275) "threads" main () at threads.c:40
(gdb) add-inferior
Added inferior 2
(gdb) info threads
Id Target Id Frame
* 1.1 Thread 0x7ffff7fc1740 (LWP 15275) "threads" main () at threads.c:40
(gdb)
No regressions on x86_64 Fedora 20.
gdb/ChangeLog:
2016-01-13 Pedro Alves <palves@redhat.com>
* NEWS: Mention that thread IDs are now per inferior and global
thread IDs.
* Makefile.in (SFILES): Add tid-parse.c.
(COMMON_OBS): Add tid-parse.o.
(HFILES_NO_SRCDIR): Add tid-parse.h.
* ada-tasks.c: Adjust to use ptid_to_global_thread_id.
* breakpoint.c (insert_breakpoint_locations)
(remove_threaded_breakpoints, bpstat_check_breakpoint_conditions)
(print_one_breakpoint_location, set_longjmp_breakpoint)
(check_longjmp_breakpoint_for_call_dummy)
(set_momentary_breakpoint): Adjust to use global IDs.
(find_condition_and_thread, watch_command_1): Use parse_thread_id.
(until_break_command, longjmp_bkpt_dtor)
(breakpoint_re_set_thread, insert_single_step_breakpoint): Adjust
to use global IDs.
* dummy-frame.c (pop_dummy_frame_bpt): Adjust to use
ptid_to_global_thread_id.
* elfread.c (elf_gnu_ifunc_resolver_stop): Likewise.
* gdbthread.h (struct thread_info): Rename field 'num' to
'global_num. Add new fields 'per_inf_num' and 'inf'.
(thread_id_to_pid): Rename thread_id_to_pid to
global_thread_id_to_ptid.
(pid_to_thread_id): Rename to ...
(ptid_to_global_thread_id): ... this.
(valid_thread_id): Rename to ...
(valid_global_thread_id): ... this.
(find_thread_id): Rename to ...
(find_thread_global_id): ... this.
(ALL_THREADS, ALL_THREADS_BY_INFERIOR): Declare.
(print_thread_info): Add comment.
* tid-parse.h: New file.
* tid-parse.c: New file.
* infcmd.c (step_command_fsm_prepare)
(step_command_fsm_should_stop): Adjust to use the global thread
ID.
(until_next_command, until_next_command)
(finish_command_fsm_should_stop): Adjust to use the global thread
ID.
(attach_post_wait): Adjust to check the inferior number too.
* inferior.h (struct inferior) <highest_thread_num>: New field.
* infrun.c (handle_signal_stop)
(insert_exception_resume_breakpoint)
(insert_exception_resume_from_probe): Adjust to use the global
thread ID.
* record-btrace.c (record_btrace_open): Use global thread IDs.
* remote.c (process_initial_stop_replies): Also consider the
inferior number.
* target.c (target_pre_inferior): Clear the inferior's highest
thread num.
* thread.c (clear_thread_inferior_resources): Adjust to use the
global thread ID.
(new_thread): New inferior parameter. Adjust to use it. Set both
the thread's global ID and the thread's per-inferior ID.
(add_thread_silent): Adjust.
(find_thread_global_id): New.
(find_thread_id): Make static. Adjust to rename.
(valid_thread_id): Rename to ...
(valid_global_thread_id): ... this.
(pid_to_thread_id): Rename to ...
(ptid_to_global_thread_id): ... this.
(thread_id_to_pid): Rename to ...
(global_thread_id_to_ptid): ... this. Adjust.
(first_thread_of_process): Adjust.
(do_captured_list_thread_ids): Adjust to use global thread IDs.
(should_print_thread): New function.
(print_thread_info): Rename to ...
(print_thread_info_1): ... this, and add new show_global_ids
parameter. Handle it. Iterate over inferiors.
(print_thread_info): Reimplement as wrapper around
print_thread_info_1.
(show_inferior_qualified_tids): New function.
(print_thread_id): Use it.
(tp_array_compar): Compare inferior numbers too.
(thread_apply_command): Use tid_range_parser.
(do_captured_thread_select): Use parse_thread_id.
(thread_id_make_value): Adjust.
(_initialize_thread): Adjust "info threads" help string.
* varobj.c (struct varobj_root): Update comment.
(varobj_create): Adjust to use global thread IDs.
(value_of_root_1): Adjust to use global_thread_id_to_ptid.
* windows-tdep.c (display_tib): No longer accept an argument.
* cli/cli-utils.c (get_number_trailer): Make extern.
* cli/cli-utils.h (get_number_trailer): Declare.
(get_number_const): Adjust documentation.
* mi/mi-cmd-var.c (mi_cmd_var_update_iter): Adjust to use global
thread IDs.
* mi/mi-interp.c (mi_new_thread, mi_thread_exit)
(mi_on_normal_stop, mi_output_running_pid, mi_on_resume):
* mi/mi-main.c (mi_execute_command, mi_cmd_execute): Likewise.
* guile/scm-breakpoint.c (gdbscm_set_breakpoint_thread_x):
Likewise.
* python/py-breakpoint.c (bppy_set_thread): Likewise.
* python/py-finishbreakpoint.c (bpfinishpy_init): Likewise.
* python/py-infthread.c (thpy_get_num): Add comment and return the
per-inferior thread ID.
(thread_object_getset): Update comment of "num".
gdb/testsuite/ChangeLog:
2016-01-07 Pedro Alves <palves@redhat.com>
* gdb.base/break.exp: Adjust to output changes.
* gdb.base/hbreak2.exp: Likewise.
* gdb.base/sepdebug.exp: Likewise.
* gdb.base/watch_thread_num.exp: Likewise.
* gdb.linespec/keywords.exp: Likewise.
* gdb.multi/info-threads.exp: Likewise.
* gdb.threads/thread-find.exp: Likewise.
* gdb.multi/tids.c: New file.
* gdb.multi/tids.exp: New file.
gdb/doc/ChangeLog:
2016-01-07 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Threads): Document per-inferior thread IDs,
qualified thread IDs, global thread IDs and thread ID lists.
(Set Watchpoints, Thread-Specific Breakpoints): Adjust to refer to
thread IDs.
(Convenience Vars): Document the $_thread convenience variable.
(Ada Tasks): Adjust to refer to thread IDs.
(GDB/MI Async Records, GDB/MI Thread Commands, GDB/MI Ada Tasking
Commands, GDB/MI Variable Objects): Update to mention global
thread IDs.
* guile.texi (Breakpoints In Guile)
<breakpoint-thread/set-breakpoint-thread breakpoint>: Mention
global thread IDs instead of thread IDs.
* python.texi (Threads In Python): Adjust documentation of
InferiorThread.num.
(Breakpoint.thread): Mention global thread IDs instead of thread
IDs.
2016-01-13 10:56:07 +00:00
|
|
|
The per-inferior number of the thread, as assigned by GDB.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
2016-01-13 10:56:08 +00:00
|
|
|
@defvar InferiorThread.global_num
|
|
|
|
|
The global ID of the thread, as assigned by GDB. You can use this to
|
|
|
|
|
make Python breakpoints thread-specific, for example
|
|
|
|
|
(@pxref{python_breakpoint_thread,,The Breakpoint.thread attribute}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/Python: Added ThreadExitedEvent
v6:
Fix comments.
Fix copyright
Remove unnecessary test suite stuff. save_var had to stay, as it mutates
some test suite state that otherwise fails.
v5:
Did what Tom Tromey requested in v4; which can be found here: https://pi.simark.ca/gdb-patches/87pmjm0xar.fsf@tromey.com/
v4:
Doc formatting fixed.
v3:
Eli:
Updated docs & NEWS to reflect new changes. Added
a reference from the .ptid attribute of the ThreadExitedEvent
to the ptid attribute of InferiorThread. To do this,
I've added an anchor to that attribute.
Tom:
Tom requested that I should probably just emit the thread object;
I ran into two issues for this, which I could not resolve in this patch;
1 - The Thread Object (the python type) checks it's own validity
by doing a comparison of it's `thread_info* thread` to nullptr. This
means that any access of it's attributes may (probably, since we are
in "async" land) throw Python exceptions because the thread has been
removed from the thread object. Therefore I've decided in v3 of this
patch to just emit most of the same fields that gdb.InferiorThread has, namely
global_num, name, num and ptid (the 3-attribute tuple provided by
gdb.InferiorThread.ptid).
2 - A python user can hold a global reference to an exiting thread. Thus
in order to have a ThreadExit event that can provide attribute access
reliably (both as a global reference, but also inside the thread exit
handler, as we can never guarantee that it's executed _before_ the
thread_info pointer is removed from the gdbpy thread object),
the `thread_info *` thread pointer must not be null. However, this
comes at the cost of gdb.InferiorThread believing it is "valid" - which means,
that if a user holds takes a global reference to that
exiting event thread object, they can some time later do `t.switch()` at which
point GDB will 'explode' so to speak.
v2:
Fixed white space issues and NULL/nullptr stuff,
as requested by Tom Tromey.
v1:
Currently no event is emitted for a thread exit.
This adds this functionality by emitting a new gdb.ThreadExitedEvent.
It currently provides four attributes:
- global_num: The GDB assigned global thread number
- num: the per-inferior thread number
- name: name of the thread or none if not set
- ptid: the PTID of the thread, a 3-attribute tuple, identical to
InferiorThread.ptid attribute
Added info to docs & the NEWS file as well.
Added test to test suite.
Fixed formatting.
Feedback wanted and appreciated.
2022-04-20 10:25:47 +02:00
|
|
|
@anchor{inferior_thread_ptid}
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar InferiorThread.ptid
|
|
|
|
|
ID of the thread, as assigned by the operating system. This attribute is a
|
|
|
|
|
tuple containing three integers. The first is the Process ID (PID); the second
|
|
|
|
|
is the Lightweight Process ID (LWPID), and the third is the Thread ID (TID).
|
|
|
|
|
Either the LWPID or TID may be 0, which indicates that the operating system
|
|
|
|
|
does not use that identifier.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2024-01-09 17:29:24 +00:00
|
|
|
@defvar InferiorThread.ptid_string
|
|
|
|
|
This read-only attribute contains a string representing
|
|
|
|
|
@code{InferiorThread.ptid}. This is the string that @value{GDBN} uses
|
|
|
|
|
in the @samp{Target Id} column in the @kbd{info threads} output
|
|
|
|
|
(@pxref{info_threads,,@samp{info threads}}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2016-01-13 10:56:06 +00:00
|
|
|
@defvar InferiorThread.inferior
|
|
|
|
|
The inferior this thread belongs to. This attribute is represented as
|
|
|
|
|
a @code{gdb.Inferior} object. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/python: Add gdb.InferiorThread.details attribute
This adds a new read-only attribute gdb.InferiorThread.details, this
attribute contains a string, the results of target_extra_thread_info
for the thread, or None, if target_extra_thread_info returns nullptr.
As the string returned by target_extra_thread_info is unstructured,
this attribute is only really useful for echoing straight through to
the user, but, if a user wants to write a command that displays the
same, or a similar 'Thread Id' to the one seen in 'info threads', then
they need access to this string.
Given that the string produced by target_extra_thread_info varies by
target, there's only minimal testing of this attribute, I check that
the attribute can be accessed, and that the return value is either
None, or a string.
2022-02-14 17:02:03 +00:00
|
|
|
@defvar InferiorThread.details
|
|
|
|
|
A string containing target specific thread state information. The
|
|
|
|
|
format of this string varies by target. If there is no additional
|
|
|
|
|
state information for this thread, then this attribute contains
|
|
|
|
|
@code{None}.
|
|
|
|
|
|
|
|
|
|
For example, on a @sc{gnu}/Linux system, a thread that is in the
|
|
|
|
|
process of exiting will return the string @samp{Exiting}. For remote
|
|
|
|
|
targets the @code{details} string will be obtained with the
|
|
|
|
|
@samp{qThreadExtraInfo} remote packet, if the target supports it
|
|
|
|
|
(@pxref{qThreadExtraInfo,,@samp{qThreadExtraInfo}}).
|
|
|
|
|
|
|
|
|
|
@value{GDBN} displays the @code{details} string as part of the
|
|
|
|
|
@samp{Target Id} column, in the @code{info threads} output
|
|
|
|
|
(@pxref{info_threads,,@samp{info threads}}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
A @code{gdb.InferiorThread} object has the following methods:
|
|
|
|
|
|
|
|
|
|
@defun InferiorThread.is_valid ()
|
|
|
|
|
Returns @code{True} if the @code{gdb.InferiorThread} object is valid,
|
|
|
|
|
@code{False} if not. A @code{gdb.InferiorThread} object will become
|
|
|
|
|
invalid if the thread exits, or the inferior that the thread belongs
|
|
|
|
|
is deleted. All other @code{gdb.InferiorThread} methods will throw an
|
|
|
|
|
exception if it is invalid at the time the method is called.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun InferiorThread.switch ()
|
|
|
|
|
This changes @value{GDBN}'s currently selected thread to the one represented
|
|
|
|
|
by this object.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun InferiorThread.is_stopped ()
|
|
|
|
|
Return a Boolean indicating whether the thread is stopped.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun InferiorThread.is_running ()
|
|
|
|
|
Return a Boolean indicating whether the thread is running.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun InferiorThread.is_exited ()
|
|
|
|
|
Return a Boolean indicating whether the thread is exited.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2018-09-15 21:53:38 -07:00
|
|
|
@defun InferiorThread.handle ()
|
|
|
|
|
Return the thread object's handle, represented as a Python @code{bytes}
|
|
|
|
|
object. A @code{gdb.Value} representation of the handle may be
|
|
|
|
|
constructed via @code{gdb.Value(bufobj, type)} where @var{bufobj} is
|
|
|
|
|
the Python @code{bytes} representation of the handle and @var{type} is
|
|
|
|
|
a @code{gdb.Type} for the handle type.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2024-01-05 11:05:51 +00:00
|
|
|
One may add arbitrary attributes to @code{gdb.InferiorThread} objects
|
|
|
|
|
in the usual Python way. This is useful if, for example, one needs to
|
|
|
|
|
do some extra record keeping associated with the thread.
|
|
|
|
|
|
2024-01-10 15:42:55 +00:00
|
|
|
@xref{choosing attribute names}, for guidance on selecting a suitable
|
|
|
|
|
name for new attributes.
|
|
|
|
|
|
2024-01-05 11:05:51 +00:00
|
|
|
In this contrived example we record the time when a thread last
|
|
|
|
|
stopped:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
@group
|
|
|
|
|
(@value{GDBP}) python
|
|
|
|
|
import datetime
|
|
|
|
|
|
|
|
|
|
def thread_stopped(event):
|
|
|
|
|
if event.inferior_thread is not None:
|
|
|
|
|
thread = event.inferior_thread
|
|
|
|
|
else:
|
|
|
|
|
thread = gdb.selected_thread()
|
|
|
|
|
thread._last_stop_time = datetime.datetime.today()
|
|
|
|
|
|
|
|
|
|
gdb.events.stop.connect(thread_stopped)
|
|
|
|
|
@end group
|
|
|
|
|
@group
|
|
|
|
|
(@value{GDBP}) file /tmp/hello
|
|
|
|
|
Reading symbols from /tmp/hello...
|
|
|
|
|
(@value{GDBP}) start
|
|
|
|
|
Temporary breakpoint 1 at 0x401198: file /tmp/hello.c, line 18.
|
|
|
|
|
Starting program: /tmp/hello
|
|
|
|
|
|
|
|
|
|
Temporary breakpoint 1, main () at /tmp/hello.c:18
|
|
|
|
|
18 printf ("Hello World\n");
|
|
|
|
|
(@value{GDBP}) python print(gdb.selected_thread()._last_stop_time)
|
|
|
|
|
2024-01-04 14:48:41.347036
|
|
|
|
|
@end group
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
2016-11-21 16:39:57 +01:00
|
|
|
@node Recordings In Python
|
|
|
|
|
@subsubsection Recordings In Python
|
|
|
|
|
@cindex recordings in python
|
|
|
|
|
|
|
|
|
|
The following recordings-related functions
|
|
|
|
|
(@pxref{Process Record and Replay}) are available in the @code{gdb}
|
|
|
|
|
module:
|
|
|
|
|
|
|
|
|
|
@defun gdb.start_recording (@r{[}method@r{]}, @r{[}format@r{]})
|
|
|
|
|
Start a recording using the given @var{method} and @var{format}. If
|
|
|
|
|
no @var{format} is given, the default format for the recording method
|
|
|
|
|
is used. If no @var{method} is given, the default method will be used.
|
|
|
|
|
Returns a @code{gdb.Record} object on success. Throw an exception on
|
|
|
|
|
failure.
|
|
|
|
|
|
|
|
|
|
The following strings can be passed as @var{method}:
|
|
|
|
|
|
|
|
|
|
@itemize @bullet
|
|
|
|
|
@item
|
|
|
|
|
@code{"full"}
|
|
|
|
|
@item
|
|
|
|
|
@code{"btrace"}: Possible values for @var{format}: @code{"pt"},
|
|
|
|
|
@code{"bts"} or leave out for default format.
|
|
|
|
|
@end itemize
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.current_recording ()
|
|
|
|
|
Access a currently running recording. Return a @code{gdb.Record}
|
|
|
|
|
object on success. Return @code{None} if no recording is currently
|
|
|
|
|
active.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.stop_recording ()
|
|
|
|
|
Stop the current recording. Throw an exception if no recording is
|
|
|
|
|
currently active. All record objects become invalid after this call.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
A @code{gdb.Record} object has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar Record.method
|
|
|
|
|
A string with the current recording method, e.g.@: @code{full} or
|
|
|
|
|
@code{btrace}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Record.format
|
|
|
|
|
A string with the current recording format, e.g.@: @code{bt}, @code{pts} or
|
|
|
|
|
@code{None}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Record.begin
|
|
|
|
|
A method specific instruction object representing the first instruction
|
|
|
|
|
in this recording.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Record.end
|
|
|
|
|
A method specific instruction object representing the current
|
|
|
|
|
instruction, that is not actually part of the recording.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Record.replay_position
|
|
|
|
|
The instruction representing the current replay position. If there is
|
|
|
|
|
no replay active, this will be @code{None}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Record.instruction_history
|
|
|
|
|
A list with all recorded instructions.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Record.function_call_history
|
|
|
|
|
A list with all recorded function call segments.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
A @code{gdb.Record} object has the following methods:
|
|
|
|
|
|
|
|
|
|
@defun Record.goto (instruction)
|
|
|
|
|
Move the replay position to the given @var{instruction}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2019-02-25 15:30:29 +01:00
|
|
|
@defun Record.clear ()
|
|
|
|
|
Clear the trace data of the current recording. This forces re-decoding of the
|
|
|
|
|
trace for successive commands.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
The common @code{gdb.Instruction} class that recording method specific
|
|
|
|
|
instruction objects inherit from, has the following attributes:
|
2016-11-21 16:39:57 +01:00
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar Instruction.pc
|
2017-05-02 11:35:54 +02:00
|
|
|
An integer representing this instruction's address.
|
2016-11-21 16:39:57 +01:00
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar Instruction.data
|
2023-06-28 09:39:37 -06:00
|
|
|
A @code{memoryview} object holding the raw instruction data.
|
2016-11-21 16:39:57 +01:00
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar Instruction.decoded
|
2017-05-02 11:35:54 +02:00
|
|
|
A human readable string with the disassembled instruction.
|
2016-11-21 16:39:57 +01:00
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar Instruction.size
|
2017-05-02 11:35:54 +02:00
|
|
|
The size of the instruction in bytes.
|
2016-11-21 16:39:57 +01:00
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
Additionally @code{gdb.RecordInstruction} has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar RecordInstruction.number
|
|
|
|
|
An integer identifying this instruction. @code{number} corresponds to
|
|
|
|
|
the numbers seen in @code{record instruction-history}
|
|
|
|
|
(@pxref{Process Record and Replay}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar RecordInstruction.sal
|
|
|
|
|
A @code{gdb.Symtab_and_line} object representing the associated symtab
|
|
|
|
|
and line of this instruction. May be @code{None} if no debug information is
|
|
|
|
|
available.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar RecordInstruction.is_speculative
|
2017-05-02 11:35:54 +02:00
|
|
|
A boolean indicating whether the instruction was executed speculatively.
|
2017-05-02 11:35:54 +02:00
|
|
|
@end defvar
|
|
|
|
|
|
2023-06-03 22:43:57 +02:00
|
|
|
If an error occurred during recording or decoding a recording, this error is
|
2017-05-02 11:35:54 +02:00
|
|
|
represented by a @code{gdb.RecordGap} object in the instruction list. It has
|
|
|
|
|
the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar RecordGap.number
|
|
|
|
|
An integer identifying this gap. @code{number} corresponds to the numbers seen
|
|
|
|
|
in @code{record instruction-history} (@pxref{Process Record and Replay}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar RecordGap.error_code
|
|
|
|
|
A numerical representation of the reason for the gap. The value is specific to
|
|
|
|
|
the current recording method.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar RecordGap.error_string
|
|
|
|
|
A human readable string with the reason for the gap.
|
2016-11-21 16:39:57 +01:00
|
|
|
@end defvar
|
|
|
|
|
|
2019-02-21 10:48:35 +01:00
|
|
|
Some @value{GDBN} features write auxiliary information into the execution
|
|
|
|
|
history. This information is represented by a @code{gdb.RecordAuxiliary} object
|
|
|
|
|
in the instruction list. It has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar RecordAuxiliary.@var{number}
|
|
|
|
|
An integer identifying this auxiliary. @var{number} corresponds to the numbers
|
|
|
|
|
seen in @code{record instruction-history} (@pxref{Process Record and Replay}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar RecordAuxiliary.data
|
|
|
|
|
A string representation of the auxiliary data.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
A @code{gdb.RecordFunctionSegment} object has the following attributes:
|
2016-11-21 16:39:57 +01:00
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar RecordFunctionSegment.number
|
|
|
|
|
An integer identifying this function segment. @code{number} corresponds to
|
2016-11-21 16:39:57 +01:00
|
|
|
the numbers seen in @code{record function-call-history}
|
|
|
|
|
(@pxref{Process Record and Replay}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar RecordFunctionSegment.symbol
|
2016-11-21 16:39:57 +01:00
|
|
|
A @code{gdb.Symbol} object representing the associated symbol. May be
|
2017-05-02 11:35:54 +02:00
|
|
|
@code{None} if no debug information is available.
|
2016-11-21 16:39:57 +01:00
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar RecordFunctionSegment.level
|
2016-11-21 16:39:57 +01:00
|
|
|
An integer representing the function call's stack level. May be
|
|
|
|
|
@code{None} if the function call is a gap.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar RecordFunctionSegment.instructions
|
2017-05-02 11:35:54 +02:00
|
|
|
A list of @code{gdb.RecordInstruction} or @code{gdb.RecordGap} objects
|
2017-05-02 11:35:54 +02:00
|
|
|
associated with this function call.
|
2016-11-21 16:39:57 +01:00
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar RecordFunctionSegment.up
|
|
|
|
|
A @code{gdb.RecordFunctionSegment} object representing the caller's
|
2016-11-21 16:39:57 +01:00
|
|
|
function segment. If the call has not been recorded, this will be the
|
|
|
|
|
function segment to which control returns. If neither the call nor the
|
|
|
|
|
return have been recorded, this will be @code{None}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar RecordFunctionSegment.prev
|
|
|
|
|
A @code{gdb.RecordFunctionSegment} object representing the previous
|
2016-11-21 16:39:57 +01:00
|
|
|
segment of this function call. May be @code{None}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2017-05-02 11:35:54 +02:00
|
|
|
@defvar RecordFunctionSegment.next
|
|
|
|
|
A @code{gdb.RecordFunctionSegment} object representing the next segment of
|
2016-11-21 16:39:57 +01:00
|
|
|
this function call. May be @code{None}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
The following example demonstrates the usage of these objects and
|
|
|
|
|
functions to create a function that will rewind a record to the last
|
|
|
|
|
time a function in a different file was executed. This would typically
|
|
|
|
|
be used to track the execution of user provided callback functions in a
|
|
|
|
|
library which typically are not visible in a back trace.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
def bringback ():
|
|
|
|
|
rec = gdb.current_recording ()
|
|
|
|
|
if not rec:
|
|
|
|
|
return
|
|
|
|
|
|
|
|
|
|
insn = rec.instruction_history
|
|
|
|
|
if len (insn) == 0:
|
|
|
|
|
return
|
|
|
|
|
|
|
|
|
|
try:
|
|
|
|
|
position = insn.index (rec.replay_position)
|
|
|
|
|
except:
|
|
|
|
|
position = -1
|
|
|
|
|
try:
|
|
|
|
|
filename = insn[position].sal.symtab.fullname ()
|
|
|
|
|
except:
|
|
|
|
|
filename = None
|
|
|
|
|
|
|
|
|
|
for i in reversed (insn[:position]):
|
|
|
|
|
try:
|
|
|
|
|
current = i.sal.symtab.fullname ()
|
|
|
|
|
except:
|
|
|
|
|
current = None
|
|
|
|
|
|
|
|
|
|
if filename == current:
|
|
|
|
|
continue
|
|
|
|
|
|
|
|
|
|
rec.goto (i)
|
|
|
|
|
return
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Another possible application is to write a function that counts the
|
|
|
|
|
number of code executions in a given line range. This line range can
|
|
|
|
|
contain parts of functions or span across several functions and is not
|
|
|
|
|
limited to be contiguous.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
def countrange (filename, linerange):
|
|
|
|
|
count = 0
|
|
|
|
|
|
|
|
|
|
def filter_only (file_name):
|
|
|
|
|
for call in gdb.current_recording ().function_call_history:
|
|
|
|
|
try:
|
|
|
|
|
if file_name in call.symbol.symtab.fullname ():
|
|
|
|
|
yield call
|
|
|
|
|
except:
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
for c in filter_only (filename):
|
|
|
|
|
for i in c.instructions:
|
|
|
|
|
try:
|
|
|
|
|
if i.sal.line in linerange:
|
|
|
|
|
count += 1
|
|
|
|
|
break;
|
|
|
|
|
except:
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
return count
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
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
|
|
|
@node CLI Commands In Python
|
|
|
|
|
@subsubsection CLI Commands In Python
|
2014-02-17 10:35:03 -08:00
|
|
|
|
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
|
|
|
@cindex CLI commands in python
|
|
|
|
|
@cindex commands in python, CLI
|
|
|
|
|
@cindex python commands, CLI
|
2014-02-17 10:35:03 -08:00
|
|
|
You can implement new @value{GDBN} CLI commands in Python. A CLI
|
|
|
|
|
command is implemented using an instance of the @code{gdb.Command}
|
|
|
|
|
class, most commonly using a subclass.
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Command.__init__ (name, command_class @r{[}, completer_class @r{[}, prefix@r{]]})
|
2014-02-17 10:35:03 -08:00
|
|
|
The object initializer for @code{Command} registers the new command
|
|
|
|
|
with @value{GDBN}. This initializer is normally invoked from the
|
|
|
|
|
subclass' own @code{__init__} method.
|
|
|
|
|
|
|
|
|
|
@var{name} is the name of the command. If @var{name} consists of
|
|
|
|
|
multiple words, then the initial words are looked for as prefix
|
|
|
|
|
commands. In this case, if one of the prefix commands does not exist,
|
|
|
|
|
an exception is raised.
|
|
|
|
|
|
|
|
|
|
There is no support for multi-line commands.
|
|
|
|
|
|
|
|
|
|
@var{command_class} should be one of the @samp{COMMAND_} constants
|
|
|
|
|
defined below. This argument tells @value{GDBN} how to categorize the
|
|
|
|
|
new command in the help system.
|
|
|
|
|
|
|
|
|
|
@var{completer_class} is an optional argument. If given, it should be
|
|
|
|
|
one of the @samp{COMPLETE_} constants defined below. This argument
|
|
|
|
|
tells @value{GDBN} how to perform completion for this command. If not
|
|
|
|
|
given, @value{GDBN} will attempt to complete using the object's
|
|
|
|
|
@code{complete} method (see below); if no such method is found, an
|
|
|
|
|
error will occur when completion is attempted.
|
|
|
|
|
|
|
|
|
|
@var{prefix} is an optional argument. If @code{True}, then the new
|
|
|
|
|
command is a prefix command; sub-commands of this command may be
|
|
|
|
|
registered.
|
|
|
|
|
|
|
|
|
|
The help text for the new command is taken from the Python
|
|
|
|
|
documentation string for the command's class, if there is one. If no
|
2025-04-22 17:32:53 +01:00
|
|
|
documentation string is provided, the default value @samp{This command
|
|
|
|
|
is not documented.} is used.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
gdb/python: new gdb.ParameterPrefix class
This commit adds a new gdb.ParameterPrefix class to GDB's Python API.
When creating multiple gdb.Parameters, it is often desirable to group
these together under a sub-command, for example, 'set print' has lots
of parameters nested under it, like 'set print address', and 'set
print symbol'. In the Python API the 'print' part of these commands
are called prefix commands, and are created using gdb.Command objects.
However, as parameters are set via the 'set ....' command list, and
shown through the 'show ....' command list, creating a prefix for a
parameter usually requires two prefix commands to be created, one for
the 'set' command, and one for the 'show' command.
This often leads to some duplication, or at the very least, each user
will end up creating their own helper class to simplify creation of
the two prefix commands.
This commit adds a new gdb.ParameterPrefix class. Creating a single
instance of this class will create both the 'set' and 'show' prefix
commands, which can then be used while creating the gdb.Parameter.
Here is an example of it in use:
gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE)
This adds 'set my-prefix' and 'show my-prefix', both of which are
prefix commands. The user can then add gdb.Parameter objects under
these prefixes.
The gdb.ParameterPrefix initialise method also supports documentation
strings, so we can write:
gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE,
"Configuration setting relating to my special extension.")
which will set the documentation string for the prefix command.
Also, it is possible to support prefix commands that use the `invoke`
functionality to handle unknown sub-commands. This is done by
sub-classing gdb.ParameterPrefix and overriding either 'invoke_set' or
'invoke_show' to handle the 'set' or 'show' prefix command
respectively.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2025-04-13 11:26:41 +01:00
|
|
|
@anchor{Command.dont_repeat}
|
2014-02-17 10:35:03 -08:00
|
|
|
@cindex don't repeat Python command
|
|
|
|
|
@defun Command.dont_repeat ()
|
|
|
|
|
By default, a @value{GDBN} command is repeated when the user enters a
|
|
|
|
|
blank line at the command prompt. A command can suppress this
|
2022-02-19 09:33:12 -07:00
|
|
|
behavior by invoking the @code{dont_repeat} method at some point in
|
|
|
|
|
its @code{invoke} method (normally this is done early in case of
|
|
|
|
|
exception). This is similar to the user command @code{dont-repeat},
|
|
|
|
|
see @ref{Define, dont-repeat}.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
gdb/python: new gdb.ParameterPrefix class
This commit adds a new gdb.ParameterPrefix class to GDB's Python API.
When creating multiple gdb.Parameters, it is often desirable to group
these together under a sub-command, for example, 'set print' has lots
of parameters nested under it, like 'set print address', and 'set
print symbol'. In the Python API the 'print' part of these commands
are called prefix commands, and are created using gdb.Command objects.
However, as parameters are set via the 'set ....' command list, and
shown through the 'show ....' command list, creating a prefix for a
parameter usually requires two prefix commands to be created, one for
the 'set' command, and one for the 'show' command.
This often leads to some duplication, or at the very least, each user
will end up creating their own helper class to simplify creation of
the two prefix commands.
This commit adds a new gdb.ParameterPrefix class. Creating a single
instance of this class will create both the 'set' and 'show' prefix
commands, which can then be used while creating the gdb.Parameter.
Here is an example of it in use:
gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE)
This adds 'set my-prefix' and 'show my-prefix', both of which are
prefix commands. The user can then add gdb.Parameter objects under
these prefixes.
The gdb.ParameterPrefix initialise method also supports documentation
strings, so we can write:
gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE,
"Configuration setting relating to my special extension.")
which will set the documentation string for the prefix command.
Also, it is possible to support prefix commands that use the `invoke`
functionality to handle unknown sub-commands. This is done by
sub-classing gdb.ParameterPrefix and overriding either 'invoke_set' or
'invoke_show' to handle the 'set' or 'show' prefix command
respectively.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2025-04-13 11:26:41 +01:00
|
|
|
@anchor{Command.invoke}
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun Command.invoke (argument, from_tty)
|
|
|
|
|
This method is called by @value{GDBN} when this command is invoked.
|
|
|
|
|
|
|
|
|
|
@var{argument} is a string. It is the argument to the command, after
|
|
|
|
|
leading and trailing whitespace has been stripped.
|
|
|
|
|
|
|
|
|
|
@var{from_tty} is a boolean argument. When true, this means that the
|
|
|
|
|
command was entered by the user at the terminal; when false it means
|
|
|
|
|
that the command came from elsewhere.
|
|
|
|
|
|
|
|
|
|
If this method throws an exception, it is turned into a @value{GDBN}
|
|
|
|
|
@code{error} call. Otherwise, the return value is ignored.
|
|
|
|
|
|
|
|
|
|
@findex gdb.string_to_argv
|
|
|
|
|
To break @var{argument} up into an argv-like string use
|
|
|
|
|
@code{gdb.string_to_argv}. This function behaves identically to
|
|
|
|
|
@value{GDBN}'s internal argument lexer @code{buildargv}.
|
|
|
|
|
It is recommended to use this for consistency.
|
|
|
|
|
Arguments are separated by spaces and may be quoted.
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
print gdb.string_to_argv ("1 2\ \\\"3 '4 \"5' \"6 '7\"")
|
|
|
|
|
['1', '2 "3', '4 "5', "6 '7"]
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@cindex completion of Python commands
|
|
|
|
|
@defun Command.complete (text, word)
|
|
|
|
|
This method is called by @value{GDBN} when the user attempts
|
|
|
|
|
completion on this command. All forms of completion are handled by
|
|
|
|
|
this method, that is, the @key{TAB} and @key{M-?} key bindings
|
|
|
|
|
(@pxref{Completion}), and the @code{complete} command (@pxref{Help,
|
|
|
|
|
complete}).
|
|
|
|
|
|
Don't use @var at the beginning of a sentence in GDB documentation.
gdb/doc/guile.texi (Types In Guile, Basic Guile, Frames In Guile)
(Breakpoints In Guile, Guile Printing Module)
(Guile Exception Handling, Values From Inferior In Guile)
(Objfiles In Guile, Breakpoints In Guile, Memory Ports in Guile):
Don't use @var at the beginning of a sentence.
gdb/doc/gdb.texinfo (Frame Filter Management, Trace Files)
(C Operators, Ada Tasks, Calling, Bootstrapping, ARM)
(PowerPC Embedded, Define, Annotations for Running)
(IPA Protocol Commands, Packets, General Query Packets)
(Tracepoint Packets, Notification Packets, Environment)
(Inferiors and Programs, Set Breaks, Set Catchpoints)
(Continuing and Stepping, Signals, Thread-Specific Breakpoints)
(Frames, Backtrace, Selection, Expressions, Registers)
(Trace State Variables, Built-In Func/Proc, Signaling, Files)
(Numbers, GDB/MI Async Records, GDB/MI Data Manipulation)
(Source Annotations, Using JIT Debug Info Readers, Packets)
(Stop Reply Packets, Host I/O Packets)
(Target Description Format): Don't use @var at the beginning of a
sentence.
gdb/doc/python.texi (Basic Python, Types In Python)
(Commands In Python, Frames In Python, Line Tables In Python)
(Breakpoints In Python, gdb.printing, gdb.types)
(Type Printing API): Don't use @var at the beginning of a
sentence.
2014-05-24 13:02:42 +03:00
|
|
|
The arguments @var{text} and @var{word} are both strings; @var{text}
|
|
|
|
|
holds the complete command line up to the cursor's location, while
|
2014-02-17 10:35:03 -08:00
|
|
|
@var{word} holds the last word of the command line; this is computed
|
|
|
|
|
using a word-breaking heuristic.
|
|
|
|
|
|
|
|
|
|
The @code{complete} method can return several values:
|
|
|
|
|
@itemize @bullet
|
|
|
|
|
@item
|
|
|
|
|
If the return value is a sequence, the contents of the sequence are
|
|
|
|
|
used as the completions. It is up to @code{complete} to ensure that the
|
|
|
|
|
contents actually do complete the word. A zero-length sequence is
|
|
|
|
|
allowed, it means that there were no completions available. Only
|
|
|
|
|
string elements of the sequence are used; other elements in the
|
|
|
|
|
sequence are ignored.
|
|
|
|
|
|
|
|
|
|
@item
|
|
|
|
|
If the return value is one of the @samp{COMPLETE_} constants defined
|
|
|
|
|
below, then the corresponding @value{GDBN}-internal completion
|
|
|
|
|
function is invoked, and its result is used.
|
|
|
|
|
|
|
|
|
|
@item
|
|
|
|
|
All other results are treated as though there were no available
|
|
|
|
|
completions.
|
|
|
|
|
@end itemize
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
When a new command is registered, it must be declared as a member of
|
|
|
|
|
some general class of commands. This is used to classify top-level
|
|
|
|
|
commands in the on-line help system; note that prefix commands are not
|
|
|
|
|
listed under their own category but rather that of their top-level
|
|
|
|
|
command. The available classifications are represented by constants
|
|
|
|
|
defined in the @code{gdb} module:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@findex COMMAND_NONE
|
|
|
|
|
@findex gdb.COMMAND_NONE
|
|
|
|
|
@item gdb.COMMAND_NONE
|
|
|
|
|
The command does not belong to any particular class. A command in
|
|
|
|
|
this category will not be displayed in any of the help categories.
|
|
|
|
|
|
|
|
|
|
@findex COMMAND_RUNNING
|
|
|
|
|
@findex gdb.COMMAND_RUNNING
|
|
|
|
|
@item gdb.COMMAND_RUNNING
|
|
|
|
|
The command is related to running the inferior. For example,
|
|
|
|
|
@code{start}, @code{step}, and @code{continue} are in this category.
|
|
|
|
|
Type @kbd{help running} at the @value{GDBN} prompt to see a list of
|
|
|
|
|
commands in this category.
|
|
|
|
|
|
|
|
|
|
@findex COMMAND_DATA
|
|
|
|
|
@findex gdb.COMMAND_DATA
|
|
|
|
|
@item gdb.COMMAND_DATA
|
|
|
|
|
The command is related to data or variables. For example,
|
|
|
|
|
@code{call}, @code{find}, and @code{print} are in this category. Type
|
|
|
|
|
@kbd{help data} at the @value{GDBN} prompt to see a list of commands
|
|
|
|
|
in this category.
|
|
|
|
|
|
|
|
|
|
@findex COMMAND_STACK
|
|
|
|
|
@findex gdb.COMMAND_STACK
|
|
|
|
|
@item gdb.COMMAND_STACK
|
|
|
|
|
The command has to do with manipulation of the stack. For example,
|
|
|
|
|
@code{backtrace}, @code{frame}, and @code{return} are in this
|
|
|
|
|
category. Type @kbd{help stack} at the @value{GDBN} prompt to see a
|
|
|
|
|
list of commands in this category.
|
|
|
|
|
|
|
|
|
|
@findex COMMAND_FILES
|
|
|
|
|
@findex gdb.COMMAND_FILES
|
|
|
|
|
@item gdb.COMMAND_FILES
|
|
|
|
|
This class is used for file-related commands. For example,
|
|
|
|
|
@code{file}, @code{list} and @code{section} are in this category.
|
|
|
|
|
Type @kbd{help files} at the @value{GDBN} prompt to see a list of
|
|
|
|
|
commands in this category.
|
|
|
|
|
|
|
|
|
|
@findex COMMAND_SUPPORT
|
|
|
|
|
@findex gdb.COMMAND_SUPPORT
|
|
|
|
|
@item gdb.COMMAND_SUPPORT
|
|
|
|
|
This should be used for ``support facilities'', generally meaning
|
|
|
|
|
things that are useful to the user when interacting with @value{GDBN},
|
|
|
|
|
but not related to the state of the inferior. For example,
|
|
|
|
|
@code{help}, @code{make}, and @code{shell} are in this category. Type
|
|
|
|
|
@kbd{help support} at the @value{GDBN} prompt to see a list of
|
|
|
|
|
commands in this category.
|
|
|
|
|
|
|
|
|
|
@findex COMMAND_STATUS
|
|
|
|
|
@findex gdb.COMMAND_STATUS
|
|
|
|
|
@item gdb.COMMAND_STATUS
|
|
|
|
|
The command is an @samp{info}-related command, that is, related to the
|
|
|
|
|
state of @value{GDBN} itself. For example, @code{info}, @code{macro},
|
|
|
|
|
and @code{show} are in this category. Type @kbd{help status} at the
|
|
|
|
|
@value{GDBN} prompt to see a list of commands in this category.
|
|
|
|
|
|
|
|
|
|
@findex COMMAND_BREAKPOINTS
|
|
|
|
|
@findex gdb.COMMAND_BREAKPOINTS
|
|
|
|
|
@item gdb.COMMAND_BREAKPOINTS
|
|
|
|
|
The command has to do with breakpoints. For example, @code{break},
|
|
|
|
|
@code{clear}, and @code{delete} are in this category. Type @kbd{help
|
|
|
|
|
breakpoints} at the @value{GDBN} prompt to see a list of commands in
|
|
|
|
|
this category.
|
|
|
|
|
|
|
|
|
|
@findex COMMAND_TRACEPOINTS
|
|
|
|
|
@findex gdb.COMMAND_TRACEPOINTS
|
|
|
|
|
@item gdb.COMMAND_TRACEPOINTS
|
|
|
|
|
The command has to do with tracepoints. For example, @code{trace},
|
|
|
|
|
@code{actions}, and @code{tfind} are in this category. Type
|
|
|
|
|
@kbd{help tracepoints} at the @value{GDBN} prompt to see a list of
|
|
|
|
|
commands in this category.
|
|
|
|
|
|
2020-04-28 08:54:17 -06:00
|
|
|
@findex COMMAND_TUI
|
|
|
|
|
@findex gdb.COMMAND_TUI
|
|
|
|
|
@item gdb.COMMAND_TUI
|
|
|
|
|
The command has to do with the text user interface (@pxref{TUI}).
|
|
|
|
|
Type @kbd{help tui} at the @value{GDBN} prompt to see a list of
|
|
|
|
|
commands in this category.
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@findex COMMAND_USER
|
|
|
|
|
@findex gdb.COMMAND_USER
|
|
|
|
|
@item gdb.COMMAND_USER
|
|
|
|
|
The command is a general purpose command for the user, and typically
|
|
|
|
|
does not fit in one of the other categories.
|
|
|
|
|
Type @kbd{help user-defined} at the @value{GDBN} prompt to see
|
|
|
|
|
a list of commands in this category, as well as the list of gdb macros
|
|
|
|
|
(@pxref{Sequences}).
|
|
|
|
|
|
|
|
|
|
@findex COMMAND_OBSCURE
|
|
|
|
|
@findex gdb.COMMAND_OBSCURE
|
|
|
|
|
@item gdb.COMMAND_OBSCURE
|
|
|
|
|
The command is only used in unusual circumstances, or is not of
|
|
|
|
|
general interest to users. For example, @code{checkpoint},
|
|
|
|
|
@code{fork}, and @code{stop} are in this category. Type @kbd{help
|
|
|
|
|
obscure} at the @value{GDBN} prompt to see a list of commands in this
|
|
|
|
|
category.
|
|
|
|
|
|
|
|
|
|
@findex COMMAND_MAINTENANCE
|
|
|
|
|
@findex gdb.COMMAND_MAINTENANCE
|
|
|
|
|
@item gdb.COMMAND_MAINTENANCE
|
|
|
|
|
The command is only useful to @value{GDBN} maintainers. The
|
|
|
|
|
@code{maintenance} and @code{flushregs} commands are in this category.
|
|
|
|
|
Type @kbd{help internals} at the @value{GDBN} prompt to see a list of
|
|
|
|
|
commands in this category.
|
|
|
|
|
@end table
|
|
|
|
|
|
|
|
|
|
A new command can use a predefined completion function, either by
|
|
|
|
|
specifying it via an argument at initialization, or by returning it
|
|
|
|
|
from the @code{complete} method. These predefined completion
|
|
|
|
|
constants are all defined in the @code{gdb} module:
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vtable @code
|
|
|
|
|
@vindex COMPLETE_NONE
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.COMPLETE_NONE
|
|
|
|
|
This constant means that no completion should be done.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex COMPLETE_FILENAME
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.COMPLETE_FILENAME
|
|
|
|
|
This constant means that filename completion should be performed.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex COMPLETE_LOCATION
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.COMPLETE_LOCATION
|
|
|
|
|
This constant means that location completion should be done.
|
gdb/manual: Introduce location specs
The current "Specify Location" section of the GDB manual starts with:
"Several @value{GDBN} commands accept arguments that specify a location
of your program's code."
And then, such commands are documented as taking a "location"
argument. For example, here's a representative subset:
@item break @var{location}
@item clear @var{location}
@item until @var{location}
@item list @var{location}
@item edit @var{location}
@itemx info line @var{location}
@item info macros @var{location}
@item trace @var{location}
@item info scope @var{location}
@item maint agent @r{[}-at @var{location}@r{,}@r{]} @var{expression}
The issue here is that "location" isn't really correct for most of
these commands. Instead, the "location" argument is really a
placeholder that represent an umbrella term for all of the
"linespecs", "explicit location", and "address location" input
formats. GDB parses these and then finds the actual code locations
(plural) in the program that match. For example, a "location"
specified like "-function func" will actually match all the code
locations in the program that correspond to the address/file/lineno of
all the functions named "func" in all the loaded programs and shared
libraries of all the inferiors. A location specified like "-function
func -label lab" matches all the addresses of C labels named "lab" in
all functions named "func". Etc.
This means that several of the commands that claim they accept a
"location", actually end up working with multiple locations, and the
manual doesn't explain that all that well. In some cases, the command
will work with all the resolved locations. In other cases, the
command aborts with an error if the location specification resolves to
multiple locations in the program. In other cases, GDB just
arbitrarily and silently picks whatever is the first resolved code
location (which sounds like should be improved).
To clarify this, I propose we use the term "Location Specification",
with shorthand "locaction spec", when we're talking about the user
input, the argument or arguments that is/are passed to commands to
instruct GDB how to find locations of interest. This is distinct from
the actual code locations in the program, which are what GDB finds
based on the user-specified location spec. Then use "location
specification or the shorter "location spec" thoughout instead of
"location" when we're talking about the user input.
Thus, this commit does the following:
- renames the "Specify Location" section of the manual to "Location
Specifications".
- It then introduces the term "Location Specification", with
corresponding shorthand "location spec", as something distinct from
an actual code location in the program. It explains what a concrete
code location is. It explains that a location specification may be
incomplete, and that may match multiple code locations in the
program, or no code location at all. It gives examples. Some
pre-existing examples were moved from the "Set Breaks" section, and
a few new ones that didn't exist yet were added. I think it is
better to have these centralized in this "Location Specification"
section, since all the other commands that accept a location spec
have an xref that points there.
- Goes through the manual, and where "@var{location}" was used for a
command argument, updated it to say "@var{locspec}" instead. At the
same time, tweaks the description of the affected commands to
describe what happens when the location spec resolves to more than
one location. Most commands just did not say anything about that.
One command -- "maint agent -at @var{location}" -- currently says it
accepts a "location", suggesting it can accept address and explicit
locations too, but that's incorrect. In reality, it only accepts
linespecs, so fix it accordingly.
One MI command -- "-trace-find line" -- currently says it accepts a
"line specification", but it can accept address and explicit
locations too, so fix it accordingly.
Special thanks goes to Eli Zaretskii for reviews and rewording
suggestions.
Change-Id: Ic42ad8565e79ca67bfebb22cbb4794ea816fd08b
2022-05-17 13:12:04 +01:00
|
|
|
@xref{Location Specifications}.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex COMPLETE_COMMAND
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.COMPLETE_COMMAND
|
|
|
|
|
This constant means that completion should examine @value{GDBN}
|
|
|
|
|
command names.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex COMPLETE_SYMBOL
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.COMPLETE_SYMBOL
|
|
|
|
|
This constant means that completion should be done using symbol names
|
|
|
|
|
as the source.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex COMPLETE_EXPRESSION
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.COMPLETE_EXPRESSION
|
|
|
|
|
This constant means that completion should be done on expressions.
|
|
|
|
|
Often this means completing on symbol names, but some language
|
|
|
|
|
parsers also have support for completing on field names.
|
2014-05-17 09:13:00 -07:00
|
|
|
@end vtable
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
The following code snippet shows how a trivial CLI command can be
|
|
|
|
|
implemented in Python:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class HelloWorld (gdb.Command):
|
|
|
|
|
"""Greet the whole world."""
|
|
|
|
|
|
|
|
|
|
def __init__ (self):
|
|
|
|
|
super (HelloWorld, self).__init__ ("hello-world", gdb.COMMAND_USER)
|
|
|
|
|
|
|
|
|
|
def invoke (self, arg, from_tty):
|
2021-01-25 10:28:53 -05:00
|
|
|
print ("Hello, World!")
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
HelloWorld ()
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The last line instantiates the class, and is necessary to trigger the
|
|
|
|
|
registration of the command with @value{GDBN}. Depending on how the
|
|
|
|
|
Python code is read into @value{GDBN}, you may need to import the
|
|
|
|
|
@code{gdb} module explicitly.
|
|
|
|
|
|
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
|
|
|
@node GDB/MI Commands In Python
|
2023-05-18 12:15:59 -06:00
|
|
|
@subsubsection @sc{gdb/mi} Commands In Python
|
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
|
|
|
|
|
|
|
|
@cindex MI commands in python
|
|
|
|
|
@cindex commands in python, GDB/MI
|
|
|
|
|
@cindex python commands, GDB/MI
|
2023-05-18 12:15:59 -06:00
|
|
|
It is possible to add @sc{gdb/mi} (@pxref{GDB/MI}) commands
|
|
|
|
|
implemented in Python. A @sc{gdb/mi} command is implemented using an
|
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
|
|
|
instance of the @code{gdb.MICommand} class, most commonly using a
|
|
|
|
|
subclass.
|
|
|
|
|
|
|
|
|
|
@defun MICommand.__init__ (name)
|
|
|
|
|
The object initializer for @code{MICommand} registers the new command
|
|
|
|
|
with @value{GDBN}. This initializer is normally invoked from the
|
|
|
|
|
subclass' own @code{__init__} method.
|
|
|
|
|
|
|
|
|
|
@var{name} is the name of the command. It must be a valid name of a
|
2023-05-18 12:15:59 -06:00
|
|
|
@sc{gdb/mi} command, and in particular must start with a hyphen
|
|
|
|
|
(@code{-}). Reusing the name of a built-in @sc{gdb/mi} is not
|
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
|
|
|
allowed, and a @code{RuntimeError} will be raised. Using the name
|
2023-05-18 12:15:59 -06:00
|
|
|
of an @sc{gdb/mi} command previously defined in Python is allowed, the
|
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
|
|
|
previous command will be replaced with the new command.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun MICommand.invoke (arguments)
|
|
|
|
|
This method is called by @value{GDBN} when the new MI command is
|
|
|
|
|
invoked.
|
|
|
|
|
|
|
|
|
|
@var{arguments} is a list of strings. Note, that @code{--thread}
|
|
|
|
|
and @code{--frame} arguments are handled by @value{GDBN} itself therefore
|
|
|
|
|
they do not show up in @code{arguments}.
|
|
|
|
|
|
|
|
|
|
If this method raises an exception, then it is turned into a
|
2023-05-18 12:15:59 -06:00
|
|
|
@sc{gdb/mi} @code{^error} response. Only @code{gdb.GdbError}
|
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
|
|
|
exceptions (or its sub-classes) should be used for reporting errors to
|
|
|
|
|
users, any other exception type is treated as a failure of the
|
|
|
|
|
@code{invoke} method, and the exception will be printed to the error
|
|
|
|
|
stream according to the @kbd{set python print-stack} setting
|
|
|
|
|
(@pxref{set_python_print_stack,,@kbd{set python print-stack}}).
|
|
|
|
|
|
2023-05-18 12:15:59 -06:00
|
|
|
If this method returns @code{None}, then the @sc{gdb/mi} command will
|
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 a @code{^done} response with no additional values.
|
|
|
|
|
|
|
|
|
|
Otherwise, the return value must be a dictionary, which is converted
|
2023-05-18 12:15:59 -06:00
|
|
|
to a @sc{gdb/mi} @var{result-record} (@pxref{GDB/MI Output Syntax}).
|
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 keys of this dictionary must be strings, and are used as
|
|
|
|
|
@var{variable} names in the @var{result-record}, these strings must
|
|
|
|
|
comply with the naming rules detailed below. The values of this
|
|
|
|
|
dictionary are recursively handled as follows:
|
|
|
|
|
|
|
|
|
|
@itemize
|
|
|
|
|
@item
|
|
|
|
|
If the value is Python sequence or iterator, it is converted to
|
2023-05-18 12:15:59 -06:00
|
|
|
@sc{gdb/mi} @var{list} with elements converted recursively.
|
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
|
|
|
|
|
|
|
|
@item
|
|
|
|
|
If the value is Python dictionary, it is converted to
|
2023-05-18 12:15:59 -06:00
|
|
|
@sc{gdb/mi} @var{tuple}. Keys in that dictionary must be strings,
|
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
|
|
|
which comply with the @var{variable} naming rules detailed below.
|
|
|
|
|
Values are converted recursively.
|
|
|
|
|
|
|
|
|
|
@item
|
|
|
|
|
Otherwise, value is first converted to a Python string using
|
2023-05-18 12:15:59 -06:00
|
|
|
@code{str ()} and then converted to @sc{gdb/mi} @var{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
|
|
|
@end itemize
|
|
|
|
|
|
2023-05-18 12:15:59 -06:00
|
|
|
The strings used for @var{variable} names in the @sc{gdb/mi} output
|
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
|
|
|
must follow the following rules; the string must be at least one
|
|
|
|
|
character long, the first character must be in the set
|
|
|
|
|
@code{[a-zA-Z]}, while every subsequent character must be in the set
|
|
|
|
|
@code{[-_a-zA-Z0-9]}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
An instance of @code{MICommand} has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar MICommand.name
|
2023-05-18 12:15:59 -06:00
|
|
|
A string, the name of this @sc{gdb/mi} command, as was passed to the
|
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
|
|
|
@code{__init__} method. This attribute is read-only.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar MICommand.installed
|
|
|
|
|
A boolean value indicating if this command is installed ready for a
|
|
|
|
|
user to call from the command line. Commands are automatically
|
|
|
|
|
installed when they are instantiated, after which this attribute will
|
|
|
|
|
be @code{True}.
|
|
|
|
|
|
|
|
|
|
If later, a new command is created with the same name, then the
|
|
|
|
|
original command will become uninstalled, and this attribute will be
|
|
|
|
|
@code{False}.
|
|
|
|
|
|
|
|
|
|
This attribute is read-write, setting this attribute to @code{False}
|
|
|
|
|
will uninstall the command, removing it from the set of available
|
|
|
|
|
commands. Setting this attribute to @code{True} will install the
|
|
|
|
|
command for use. If there is already a Python command with this name
|
|
|
|
|
installed, the currently installed command will be uninstalled, and
|
2023-03-08 15:26:32 +00:00
|
|
|
this command installed in its stead.
|
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
|
|
|
@end defvar
|
|
|
|
|
|
2023-03-23 10:46:31 -06:00
|
|
|
The following code snippet shows how some trivial MI commands can be
|
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
|
|
|
implemented in Python:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class MIEcho(gdb.MICommand):
|
|
|
|
|
"""Echo arguments passed to the command."""
|
|
|
|
|
|
|
|
|
|
def __init__(self, name, mode):
|
|
|
|
|
self._mode = mode
|
|
|
|
|
super(MIEcho, self).__init__(name)
|
|
|
|
|
|
|
|
|
|
def invoke(self, argv):
|
|
|
|
|
if self._mode == 'dict':
|
|
|
|
|
return @{ 'dict': @{ 'argv' : argv @} @}
|
|
|
|
|
elif self._mode == 'list':
|
|
|
|
|
return @{ 'list': argv @}
|
|
|
|
|
else:
|
|
|
|
|
return @{ 'string': ", ".join(argv) @}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MIEcho("-echo-dict", "dict")
|
|
|
|
|
MIEcho("-echo-list", "list")
|
|
|
|
|
MIEcho("-echo-string", "string")
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The last three lines instantiate the class three times, creating three
|
2023-05-18 12:15:59 -06:00
|
|
|
new @sc{gdb/mi} commands @code{-echo-dict}, @code{-echo-list}, and
|
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
|
|
|
@code{-echo-string}. Each time a subclass of @code{gdb.MICommand} is
|
|
|
|
|
instantiated, the new command is automatically registered with
|
|
|
|
|
@value{GDBN}.
|
|
|
|
|
|
|
|
|
|
Depending on how the Python code is read into @value{GDBN}, you may
|
|
|
|
|
need to import the @code{gdb} module explicitly.
|
|
|
|
|
|
|
|
|
|
The following example shows a @value{GDBN} session in which the above
|
|
|
|
|
commands have been added:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(@value{GDBP})
|
|
|
|
|
-echo-dict abc def ghi
|
|
|
|
|
^done,dict=@{argv=["abc","def","ghi"]@}
|
|
|
|
|
(@value{GDBP})
|
|
|
|
|
-echo-list abc def ghi
|
|
|
|
|
^done,list=["abc","def","ghi"]
|
|
|
|
|
(@value{GDBP})
|
|
|
|
|
-echo-string abc def ghi
|
|
|
|
|
^done,string="abc, def, ghi"
|
|
|
|
|
(@value{GDBP})
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
2023-03-16 10:57:32 -06:00
|
|
|
Conversely, it is possible to execute @sc{gdb/mi} commands from
|
|
|
|
|
Python, with the results being a Python object and not a
|
|
|
|
|
specially-formatted string. This is done with the
|
|
|
|
|
@code{gdb.execute_mi} function.
|
|
|
|
|
|
|
|
|
|
@defun gdb.execute_mi (command @r{[}, arg @r{]}@dots{})
|
|
|
|
|
Invoke a @sc{gdb/mi} command. @var{command} is the name of the
|
|
|
|
|
command, a string. The arguments, @var{arg}, are passed to the
|
|
|
|
|
command. Each argument must also be a string.
|
|
|
|
|
|
|
|
|
|
This function returns a Python dictionary whose contents reflect the
|
2025-01-27 12:39:56 +01:00
|
|
|
corresponding @sc{gdb/mi} command's output. Refer to the
|
2023-03-16 10:57:32 -06:00
|
|
|
documentation for these commands for details. Lists are represented
|
|
|
|
|
as Python lists, and tuples are represented as Python dictionaries.
|
|
|
|
|
|
|
|
|
|
If the command fails, it will raise a Python exception.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
Here is how this works using the commands from the example above:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(@value{GDBP}) python print(gdb.execute_mi("-echo-dict", "abc", "def", "ghi"))
|
|
|
|
|
@{'dict': @{'argv': ['abc', 'def', 'ghi']@}@}
|
|
|
|
|
(@value{GDBP}) python print(gdb.execute_mi("-echo-list", "abc", "def", "ghi"))
|
|
|
|
|
@{'list': ['abc', 'def', 'ghi']@}
|
|
|
|
|
(@value{GDBP}) python print(gdb.execute_mi("-echo-string", "abc", "def", "ghi"))
|
|
|
|
|
@{'string': 'abc, def, ghi'@}
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
2023-10-10 11:22:56 +01:00
|
|
|
@node GDB/MI Notifications In Python
|
|
|
|
|
@subsubsection @sc{gdb/mi} Notifications In Python
|
|
|
|
|
|
|
|
|
|
@cindex MI notifications in python
|
|
|
|
|
@cindex notifications in python, GDB/MI
|
|
|
|
|
@cindex python notifications, GDB/MI
|
|
|
|
|
|
|
|
|
|
It is possible to emit @sc{gdb/mi} notifications from
|
|
|
|
|
Python. Use the @code{gdb.notify_mi} function to do that.
|
|
|
|
|
|
|
|
|
|
@defun gdb.notify_mi (name @r{[}, data@r{]})
|
|
|
|
|
Emit a @sc{gdb/mi} asynchronous notification. @var{name} is the name of the
|
|
|
|
|
notification, consisting of alphanumeric characters and a hyphen (@code{-}).
|
|
|
|
|
@var{data} is any additional data to be emitted with the notification, passed
|
|
|
|
|
as a Python dictionary. This argument is optional. The dictionary is converted
|
|
|
|
|
to a @sc{gdb/mi} @var{result} records (@pxref{GDB/MI Output Syntax}) the same way
|
|
|
|
|
as result of Python MI command (@pxref{GDB/MI Commands In Python}).
|
|
|
|
|
|
|
|
|
|
If @var{data} is @code{None} then no additional values are emitted.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
While using existing notification names (@pxref{GDB/MI Async Records}) with
|
|
|
|
|
@code{gdb.notify_mi} is allowed, users are encouraged to prefix user-defined
|
|
|
|
|
notification with a hyphen (@code{-}) to avoid possible conflict.
|
|
|
|
|
@value{GDBN} will never introduce notification starting with hyphen.
|
|
|
|
|
|
|
|
|
|
Here is how to emit @code{=-connection-removed} whenever a connection to remote
|
|
|
|
|
GDB server is closed (@pxref{Connections In Python}):
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
def notify_connection_removed(event):
|
|
|
|
|
data = @{"id": event.connection.num, "type": event.connection.type@}
|
|
|
|
|
gdb.notify_mi("-connection-removed", data)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gdb.events.connection_removed.connect(notify_connection_removed)
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Then, each time a connection is closed, there will be a notification on MI channel:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
=-connection-removed,id="1",type="remote"
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Parameters In Python
|
|
|
|
|
@subsubsection Parameters In Python
|
|
|
|
|
|
|
|
|
|
@cindex parameters in python
|
|
|
|
|
@cindex python parameters
|
|
|
|
|
@tindex gdb.Parameter
|
|
|
|
|
@tindex Parameter
|
|
|
|
|
You can implement new @value{GDBN} parameters using Python. A new
|
|
|
|
|
parameter is implemented as an instance of the @code{gdb.Parameter}
|
|
|
|
|
class.
|
|
|
|
|
|
|
|
|
|
Parameters are exposed to the user via the @code{set} and
|
|
|
|
|
@code{show} commands. @xref{Help}.
|
|
|
|
|
|
|
|
|
|
There are many parameters that already exist and can be set in
|
|
|
|
|
@value{GDBN}. Two examples are: @code{set follow fork} and
|
|
|
|
|
@code{set charset}. Setting these parameters influences certain
|
|
|
|
|
behavior in @value{GDBN}. Similarly, you can define parameters that
|
|
|
|
|
can be used to influence behavior in custom Python scripts and commands.
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Parameter.__init__ (name, command_class, parameter_class @r{[}, enum_sequence@r{]})
|
2014-02-17 10:35:03 -08:00
|
|
|
The object initializer for @code{Parameter} registers the new
|
|
|
|
|
parameter with @value{GDBN}. This initializer is normally invoked
|
|
|
|
|
from the subclass' own @code{__init__} method.
|
|
|
|
|
|
|
|
|
|
@var{name} is the name of the new parameter. If @var{name} consists
|
|
|
|
|
of multiple words, then the initial words are looked for as prefix
|
|
|
|
|
parameters. An example of this can be illustrated with the
|
|
|
|
|
@code{set print} set of parameters. If @var{name} is
|
|
|
|
|
@code{print foo}, then @code{print} will be searched as the prefix
|
|
|
|
|
parameter. In this case the parameter can subsequently be accessed in
|
|
|
|
|
@value{GDBN} as @code{set print foo}.
|
|
|
|
|
|
|
|
|
|
If @var{name} consists of multiple words, and no prefix parameter group
|
|
|
|
|
can be found, an exception is raised.
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@var{command_class} should be one of the @samp{COMMAND_} constants
|
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
|
|
|
(@pxref{CLI Commands In Python}). This argument tells @value{GDBN} how to
|
2014-02-17 10:35:03 -08:00
|
|
|
categorize the new parameter in the help system.
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@var{parameter_class} should be one of the @samp{PARAM_} constants
|
2014-02-17 10:35:03 -08:00
|
|
|
defined below. This argument tells @value{GDBN} the type of the new
|
|
|
|
|
parameter; this information is used for input validation and
|
|
|
|
|
completion.
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
If @var{parameter_class} is @code{PARAM_ENUM}, then
|
|
|
|
|
@var{enum_sequence} must be a sequence of strings. These strings
|
2014-02-17 10:35:03 -08:00
|
|
|
represent the possible values for the parameter.
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
If @var{parameter_class} is not @code{PARAM_ENUM}, then the presence
|
2014-02-17 10:35:03 -08:00
|
|
|
of a fourth argument will cause an exception to be thrown.
|
|
|
|
|
|
gdb/python: improve the auto help text for gdb.Parameter
This commit attempts to improve the help text that is generated for
gdb.Parameter objects when the user fails to provide their own
documentation.
Documentation for a gdb.Parameter is currently pulled from two
sources: the class documentation string, and the set_doc/show_doc
class attributes. Thus, a fully documented parameter might look like
this:
class Param_All (gdb.Parameter):
"""This is the class documentation string."""
show_doc = "Show the state of this parameter"
set_doc = "Set the state of this parameter"
def get_set_string (self):
val = "on"
if (self.value == False):
val = "off"
return "Test Parameter has been set to " + val
def __init__ (self, name):
super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
self._value = True
Param_All ('param-all')
Then in GDB we see this:
(gdb) help set param-all
Set the state of this parameter
This is the class documentation string.
Which is fine. But, if the user skips both of the documentation parts
like this:
class Param_None (gdb.Parameter):
def get_set_string (self):
val = "on"
if (self.value == False):
val = "off"
return "Test Parameter has been set to " + val
def __init__ (self, name):
super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
self._value = True
Param_None ('param-none')
Now in GDB we see this:
(gdb) help set param-none
This command is not documented.
This command is not documented.
That's not great, the duplicated text looks a bit weird. If we drop
different parts we get different results. Here's what we get if the
user drops the set_doc and show_doc attributes:
(gdb) help set param-doc
This command is not documented.
This is the class documentation string.
That kind of sucks, we say it's undocumented, then proceed to print
the documentation. Finally, if we drop the class documentation but
keep the set_doc and show_doc:
(gdb) help set param-set-show
Set the state of this parameter
This command is not documented.
That seems OK.
So, I think there's room for improvement.
With this patch, for the four cases above we now see this:
# All values provided by the user, no change in this case:
(gdb) help set param-all
Set the state of this parameter
This is the class documentation string.
# Nothing provided by the user, the first string is now different:
(gdb) help set param-none
Set the current value of 'param-none'.
This command is not documented.
# Only the class documentation is provided, the first string is
# changed as in the previous case:
(gdb) help set param-doc
Set the current value of 'param-doc'.
This is the class documentation string.
# Only the set_doc and show_doc are provided, this case is unchanged
# from before the patch:
(gdb) help set param-set-show
Set the state of this parameter
This command is not documented.
The one place where this change might be considered a negative is when
dealing with prefix commands. If we create a prefix command but don't
supply the set_doc / show_doc strings, then this is what we saw before
my patch:
(gdb) python Param_None ('print param-none')
(gdb) help set print
set print, set pr, set p
Generic command for setting how things print.
List of set print subcommands:
... snip ...
set print param-none -- This command is not documented.
... snip ...
And after my patch:
(gdb) python Param_None ('print param-none')
(gdb) help set print
set print, set pr, set p
Generic command for setting how things print.
List of set print subcommands:
... snip ...
set print param-none -- Set the current value of 'print param-none'.
... snip ...
This seems slightly less helpful than before, but I don't think its
terrible.
Additionally, I've changed what we print when the get_show_string
method is not provided in Python.
Back when gdb.Parameter was first added to GDB, we didn't provide a
show function when registering the internal command object within
GDB. As a result, GDB would make use of its "magic" mangling of the
show_doc string to create a sentence that would display the current
value (see deprecated_show_value_hack in cli/cli-setshow.c).
However, when we added support for the get_show_string method to
gdb.Parameter, there was an attempt to maintain backward compatibility
by displaying the show_doc string with the current value appended, see
get_show_value in py-param.c. Unfortunately, this isn't anywhere
close to what deprecated_show_value_hack does, and the results are
pretty poor, for example, this is GDB before my patch:
(gdb) show param-none
This command is not documented. off
I think we can all agree that this is pretty bad.
After my patch, we how show this:
(gdb) show param-none
The current value of 'param-none' is "off".
Which at least is a real sentence, even if it's not very informative.
This patch does change the way that the Python API behaves slightly,
but only in the cases when the user has missed providing GDB with some
information. In most cases I think the new behaviour is a lot better,
there's the one case (noted above) which is a bit iffy, but I think is
still OK.
I've updated the existing gdb.python/py-parameter.exp test to cover
the modified behaviour.
Finally, I've updated the documentation to (I hope) make it clearer
how the various bits of help text come together.
2022-01-07 16:48:49 +00:00
|
|
|
The help text for the new parameter includes the Python documentation
|
|
|
|
|
string from the parameter's class, if there is one. If there is no
|
|
|
|
|
documentation string, a default value is used. The documentation
|
|
|
|
|
string is included in the output of the parameters @code{help set} and
|
|
|
|
|
@code{help show} commands, and should be written taking this into
|
gdb/python: allow empty gdb.Parameter.__doc__ string
I was recently attempting to create some parameters via the Python
API. I wanted these parameters to appear similar to how GDB handles
the existing 'style' parameters.
Specifically, I was interested in this behaviour:
(gdb) help show style filename foreground
Show the foreground color for this property.
(gdb) help set style filename foreground
Set the foreground color for this property.
(gdb)
Notice how each 'help' command only gets a single line of output.
I tried to reproduce this behaviour via the Python API and was unable.
The problem is that, in order to get just a single line of output like
this, the style parameters are registered with a call to
add_setshow_color_cmd with the 'help_doc' being passed as nullptr.
On the Python side, when parameters are created, the 'help_doc' is
obtained with a call to get_doc_string (python/py-param.c). This
function either returns the __doc__ string, or a default string: "This
command is not documented.".
To avoid returning the default we could try setting __doc__ to an
empty string, but setting this field to any string means that GDB
prints a line for that string, like this:
class test_param(gdb.Parameter):
__doc__ = ""
def __init__(self, name):
super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
self.value = True
test_param('print test')
Then in GDB:
(gdb) help set print test
Set the current value of 'print test'.
(gdb)
The blank line is the problem I'd like to solve.
This commit makes a couple of changes to how parameter doc strings are
handled.
If the doc string is set to an empty string, then GDB now converts
this to nullptr, which removes the blank line problem, the new
behaviour in GDB (for the above `test_param`) is:
(gdb) help set print test
Set the current value of 'print test'.
(gdb)
Next, I noticed that if the set/show docs are set to empty strings,
then the results are less than ideal:
class test_param(gdb.Parameter):
set_doc = ""
def __init__(self, name):
super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
self.value = True
test_param('print test')
And in GDB:
(gdb) help set print test
This command is not documented.
(gdb)
So, if the set/show docs are the empty string, GDB now forces these to
be the default string instead, the new behaviour in GDB is:
(gdb) help set print test
Set the current value of 'print test'.
This command is not documented.
(gdb)
I've added some additional asserts; the set/show docs should always be
non-empty strings, which I believe is the case after this commit. And
the 'doc' string returned from get_doc_string should never nullptr,
but could be empty.
There are new tests to cover all these changes.
2025-04-11 23:45:51 +01:00
|
|
|
account. If the documentation string for the parameter's class is the
|
|
|
|
|
empty string then @value{GDBN} will only use @code{Parameter.set_doc}
|
|
|
|
|
or @code{Parameter.show_doc} (see below) in the @kbd{help} output.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defvar Parameter.set_doc
|
|
|
|
|
If this attribute exists, and is a string, then its value is used as
|
gdb/python: improve the auto help text for gdb.Parameter
This commit attempts to improve the help text that is generated for
gdb.Parameter objects when the user fails to provide their own
documentation.
Documentation for a gdb.Parameter is currently pulled from two
sources: the class documentation string, and the set_doc/show_doc
class attributes. Thus, a fully documented parameter might look like
this:
class Param_All (gdb.Parameter):
"""This is the class documentation string."""
show_doc = "Show the state of this parameter"
set_doc = "Set the state of this parameter"
def get_set_string (self):
val = "on"
if (self.value == False):
val = "off"
return "Test Parameter has been set to " + val
def __init__ (self, name):
super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
self._value = True
Param_All ('param-all')
Then in GDB we see this:
(gdb) help set param-all
Set the state of this parameter
This is the class documentation string.
Which is fine. But, if the user skips both of the documentation parts
like this:
class Param_None (gdb.Parameter):
def get_set_string (self):
val = "on"
if (self.value == False):
val = "off"
return "Test Parameter has been set to " + val
def __init__ (self, name):
super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
self._value = True
Param_None ('param-none')
Now in GDB we see this:
(gdb) help set param-none
This command is not documented.
This command is not documented.
That's not great, the duplicated text looks a bit weird. If we drop
different parts we get different results. Here's what we get if the
user drops the set_doc and show_doc attributes:
(gdb) help set param-doc
This command is not documented.
This is the class documentation string.
That kind of sucks, we say it's undocumented, then proceed to print
the documentation. Finally, if we drop the class documentation but
keep the set_doc and show_doc:
(gdb) help set param-set-show
Set the state of this parameter
This command is not documented.
That seems OK.
So, I think there's room for improvement.
With this patch, for the four cases above we now see this:
# All values provided by the user, no change in this case:
(gdb) help set param-all
Set the state of this parameter
This is the class documentation string.
# Nothing provided by the user, the first string is now different:
(gdb) help set param-none
Set the current value of 'param-none'.
This command is not documented.
# Only the class documentation is provided, the first string is
# changed as in the previous case:
(gdb) help set param-doc
Set the current value of 'param-doc'.
This is the class documentation string.
# Only the set_doc and show_doc are provided, this case is unchanged
# from before the patch:
(gdb) help set param-set-show
Set the state of this parameter
This command is not documented.
The one place where this change might be considered a negative is when
dealing with prefix commands. If we create a prefix command but don't
supply the set_doc / show_doc strings, then this is what we saw before
my patch:
(gdb) python Param_None ('print param-none')
(gdb) help set print
set print, set pr, set p
Generic command for setting how things print.
List of set print subcommands:
... snip ...
set print param-none -- This command is not documented.
... snip ...
And after my patch:
(gdb) python Param_None ('print param-none')
(gdb) help set print
set print, set pr, set p
Generic command for setting how things print.
List of set print subcommands:
... snip ...
set print param-none -- Set the current value of 'print param-none'.
... snip ...
This seems slightly less helpful than before, but I don't think its
terrible.
Additionally, I've changed what we print when the get_show_string
method is not provided in Python.
Back when gdb.Parameter was first added to GDB, we didn't provide a
show function when registering the internal command object within
GDB. As a result, GDB would make use of its "magic" mangling of the
show_doc string to create a sentence that would display the current
value (see deprecated_show_value_hack in cli/cli-setshow.c).
However, when we added support for the get_show_string method to
gdb.Parameter, there was an attempt to maintain backward compatibility
by displaying the show_doc string with the current value appended, see
get_show_value in py-param.c. Unfortunately, this isn't anywhere
close to what deprecated_show_value_hack does, and the results are
pretty poor, for example, this is GDB before my patch:
(gdb) show param-none
This command is not documented. off
I think we can all agree that this is pretty bad.
After my patch, we how show this:
(gdb) show param-none
The current value of 'param-none' is "off".
Which at least is a real sentence, even if it's not very informative.
This patch does change the way that the Python API behaves slightly,
but only in the cases when the user has missed providing GDB with some
information. In most cases I think the new behaviour is a lot better,
there's the one case (noted above) which is a bit iffy, but I think is
still OK.
I've updated the existing gdb.python/py-parameter.exp test to cover
the modified behaviour.
Finally, I've updated the documentation to (I hope) make it clearer
how the various bits of help text come together.
2022-01-07 16:48:49 +00:00
|
|
|
the first part of the help text for this parameter's @code{set}
|
|
|
|
|
command. The second part of the help text is taken from the
|
|
|
|
|
documentation string for the parameter's class, if there is one.
|
|
|
|
|
|
|
|
|
|
The value of @code{set_doc} should give a brief summary specific to
|
|
|
|
|
the set action, this text is only displayed when the user runs the
|
|
|
|
|
@code{help set} command for this parameter. The class documentation
|
|
|
|
|
should be used to give a fuller description of what the parameter
|
|
|
|
|
does, this text is displayed for both the @code{help set} and
|
|
|
|
|
@code{help show} commands.
|
|
|
|
|
|
|
|
|
|
The @code{set_doc} value is examined when @code{Parameter.__init__} is
|
|
|
|
|
invoked; subsequent changes have no effect.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Parameter.show_doc
|
|
|
|
|
If this attribute exists, and is a string, then its value is used as
|
gdb/python: improve the auto help text for gdb.Parameter
This commit attempts to improve the help text that is generated for
gdb.Parameter objects when the user fails to provide their own
documentation.
Documentation for a gdb.Parameter is currently pulled from two
sources: the class documentation string, and the set_doc/show_doc
class attributes. Thus, a fully documented parameter might look like
this:
class Param_All (gdb.Parameter):
"""This is the class documentation string."""
show_doc = "Show the state of this parameter"
set_doc = "Set the state of this parameter"
def get_set_string (self):
val = "on"
if (self.value == False):
val = "off"
return "Test Parameter has been set to " + val
def __init__ (self, name):
super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
self._value = True
Param_All ('param-all')
Then in GDB we see this:
(gdb) help set param-all
Set the state of this parameter
This is the class documentation string.
Which is fine. But, if the user skips both of the documentation parts
like this:
class Param_None (gdb.Parameter):
def get_set_string (self):
val = "on"
if (self.value == False):
val = "off"
return "Test Parameter has been set to " + val
def __init__ (self, name):
super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
self._value = True
Param_None ('param-none')
Now in GDB we see this:
(gdb) help set param-none
This command is not documented.
This command is not documented.
That's not great, the duplicated text looks a bit weird. If we drop
different parts we get different results. Here's what we get if the
user drops the set_doc and show_doc attributes:
(gdb) help set param-doc
This command is not documented.
This is the class documentation string.
That kind of sucks, we say it's undocumented, then proceed to print
the documentation. Finally, if we drop the class documentation but
keep the set_doc and show_doc:
(gdb) help set param-set-show
Set the state of this parameter
This command is not documented.
That seems OK.
So, I think there's room for improvement.
With this patch, for the four cases above we now see this:
# All values provided by the user, no change in this case:
(gdb) help set param-all
Set the state of this parameter
This is the class documentation string.
# Nothing provided by the user, the first string is now different:
(gdb) help set param-none
Set the current value of 'param-none'.
This command is not documented.
# Only the class documentation is provided, the first string is
# changed as in the previous case:
(gdb) help set param-doc
Set the current value of 'param-doc'.
This is the class documentation string.
# Only the set_doc and show_doc are provided, this case is unchanged
# from before the patch:
(gdb) help set param-set-show
Set the state of this parameter
This command is not documented.
The one place where this change might be considered a negative is when
dealing with prefix commands. If we create a prefix command but don't
supply the set_doc / show_doc strings, then this is what we saw before
my patch:
(gdb) python Param_None ('print param-none')
(gdb) help set print
set print, set pr, set p
Generic command for setting how things print.
List of set print subcommands:
... snip ...
set print param-none -- This command is not documented.
... snip ...
And after my patch:
(gdb) python Param_None ('print param-none')
(gdb) help set print
set print, set pr, set p
Generic command for setting how things print.
List of set print subcommands:
... snip ...
set print param-none -- Set the current value of 'print param-none'.
... snip ...
This seems slightly less helpful than before, but I don't think its
terrible.
Additionally, I've changed what we print when the get_show_string
method is not provided in Python.
Back when gdb.Parameter was first added to GDB, we didn't provide a
show function when registering the internal command object within
GDB. As a result, GDB would make use of its "magic" mangling of the
show_doc string to create a sentence that would display the current
value (see deprecated_show_value_hack in cli/cli-setshow.c).
However, when we added support for the get_show_string method to
gdb.Parameter, there was an attempt to maintain backward compatibility
by displaying the show_doc string with the current value appended, see
get_show_value in py-param.c. Unfortunately, this isn't anywhere
close to what deprecated_show_value_hack does, and the results are
pretty poor, for example, this is GDB before my patch:
(gdb) show param-none
This command is not documented. off
I think we can all agree that this is pretty bad.
After my patch, we how show this:
(gdb) show param-none
The current value of 'param-none' is "off".
Which at least is a real sentence, even if it's not very informative.
This patch does change the way that the Python API behaves slightly,
but only in the cases when the user has missed providing GDB with some
information. In most cases I think the new behaviour is a lot better,
there's the one case (noted above) which is a bit iffy, but I think is
still OK.
I've updated the existing gdb.python/py-parameter.exp test to cover
the modified behaviour.
Finally, I've updated the documentation to (I hope) make it clearer
how the various bits of help text come together.
2022-01-07 16:48:49 +00:00
|
|
|
the first part of the help text for this parameter's @code{show}
|
|
|
|
|
command. The second part of the help text is taken from the
|
|
|
|
|
documentation string for the parameter's class, if there is one.
|
|
|
|
|
|
|
|
|
|
The value of @code{show_doc} should give a brief summary specific to
|
|
|
|
|
the show action, this text is only displayed when the user runs the
|
|
|
|
|
@code{help show} command for this parameter. The class documentation
|
|
|
|
|
should be used to give a fuller description of what the parameter
|
|
|
|
|
does, this text is displayed for both the @code{help set} and
|
|
|
|
|
@code{help show} commands.
|
|
|
|
|
|
|
|
|
|
The @code{show_doc} value is examined when @code{Parameter.__init__}
|
|
|
|
|
is invoked; subsequent changes have no effect.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Parameter.value
|
|
|
|
|
The @code{value} attribute holds the underlying value of the
|
|
|
|
|
parameter. It can be read and assigned to just as any other
|
|
|
|
|
attribute. @value{GDBN} does validation when assignments are made.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2018-04-26 16:51:40 -06:00
|
|
|
There are two methods that may be implemented in any @code{Parameter}
|
|
|
|
|
class. These are:
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@defun Parameter.get_set_string (self)
|
2018-04-26 16:51:40 -06:00
|
|
|
If this method exists, @value{GDBN} will call it when a
|
|
|
|
|
@var{parameter}'s value has been changed via the @code{set} API (for
|
|
|
|
|
example, @kbd{set foo off}). The @code{value} attribute has already
|
|
|
|
|
been populated with the new value and may be used in output. This
|
|
|
|
|
method must return a string. If the returned string is not empty,
|
|
|
|
|
@value{GDBN} will present it to the user.
|
2018-09-15 01:09:22 -06:00
|
|
|
|
|
|
|
|
If this method raises the @code{gdb.GdbError} exception
|
|
|
|
|
(@pxref{Exception Handling}), then @value{GDBN} will print the
|
|
|
|
|
exception's string and the @code{set} command will fail. Note,
|
|
|
|
|
however, that the @code{value} attribute will not be reset in this
|
|
|
|
|
case. So, if your parameter must validate values, it should store the
|
|
|
|
|
old value internally and reset the exposed value, like so:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class ExampleParam (gdb.Parameter):
|
|
|
|
|
def __init__ (self, name):
|
|
|
|
|
super (ExampleParam, self).__init__ (name,
|
|
|
|
|
gdb.COMMAND_DATA,
|
|
|
|
|
gdb.PARAM_BOOLEAN)
|
|
|
|
|
self.value = True
|
|
|
|
|
self.saved_value = True
|
|
|
|
|
def validate(self):
|
|
|
|
|
return False
|
|
|
|
|
def get_set_string (self):
|
|
|
|
|
if not self.validate():
|
|
|
|
|
self.value = self.saved_value
|
|
|
|
|
raise gdb.GdbError('Failed to validate')
|
|
|
|
|
self.saved_value = self.value
|
2021-03-18 16:44:14 +00:00
|
|
|
return ""
|
2018-09-15 01:09:22 -06:00
|
|
|
@end smallexample
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Parameter.get_show_string (self, svalue)
|
|
|
|
|
@value{GDBN} will call this method when a @var{parameter}'s
|
|
|
|
|
@code{show} API has been invoked (for example, @kbd{show foo}). The
|
|
|
|
|
argument @code{svalue} receives the string representation of the
|
|
|
|
|
current value. This method must return a string.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
When a new parameter is defined, its type must be specified. The
|
|
|
|
|
available types are represented by constants defined in the @code{gdb}
|
|
|
|
|
module:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@findex PARAM_BOOLEAN
|
|
|
|
|
@findex gdb.PARAM_BOOLEAN
|
|
|
|
|
@item gdb.PARAM_BOOLEAN
|
|
|
|
|
The value is a plain boolean. The Python boolean values, @code{True}
|
|
|
|
|
and @code{False} are the only valid values.
|
|
|
|
|
|
|
|
|
|
@findex PARAM_AUTO_BOOLEAN
|
|
|
|
|
@findex gdb.PARAM_AUTO_BOOLEAN
|
|
|
|
|
@item gdb.PARAM_AUTO_BOOLEAN
|
|
|
|
|
The value has three possible states: true, false, and @samp{auto}. In
|
|
|
|
|
Python, true and false are represented using boolean constants, and
|
|
|
|
|
@samp{auto} is represented using @code{None}.
|
|
|
|
|
|
|
|
|
|
@findex PARAM_UINTEGER
|
|
|
|
|
@findex gdb.PARAM_UINTEGER
|
|
|
|
|
@item gdb.PARAM_UINTEGER
|
GDB: Allow arbitrary keywords in integer set commands
Rather than just `unlimited' allow the integer set commands (or command
options) to define arbitrary keywords for the user to use, removing
hardcoded arrangements for the `unlimited' keyword.
Remove the confusingly named `var_zinteger', `var_zuinteger' and
`var_zuinteger_unlimited' `set'/`show' command variable types redefining
them in terms of `var_uinteger', `var_integer' and `var_pinteger', which
have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.
Following existing practice `var_pinteger' allows extra negative values
to be used, however unlike `var_zuinteger_unlimited' any number of such
values can be defined rather than just `-1'.
The "p" in `var_pinteger' stands for "positive", for the lack of a more
appropriate unambiguous letter, even though 0 obviously is not positive;
"n" would be confusing as to whether it stands for "non-negative" or
"negative".
Add a new structure, `literal_def', the entries of which define extra
keywords allowed for a command and numerical values they correspond to.
Those values are not verified against the basic range supported by the
underlying variable type, allowing extra values to be allowed outside
that range, which may or may not be individually made visible to the
user. An optional value translation is possible with the structure to
follow the existing practice for some commands where user-entered 0 is
internally translated to UINT_MAX or INT_MAX. Such translation can now
be arbitrary. Literals defined by this structure are automatically used
for completion as necessary.
So for example:
const literal_def integer_unlimited_literals[] =
{
{ "unlimited", INT_MAX, 0 },
{ nullptr }
};
defines an extra `unlimited' keyword and a user-visible 0 value, both of
which get translated to INT_MAX for the setting to be used with.
Similarly:
const literal_def zuinteger_unlimited_literals[] =
{
{ "unlimited", -1, -1 },
{ nullptr }
};
defines the same keyword and a corresponding user-visible -1 value that
is used for the requested setting. If the last member were omitted (or
set to `{}') here, then only the keyword would be allowed for the user
to enter and while -1 would still be used internally trying to enter it
as a part of a command would result in an "integer -1 out of range"
error.
Use said error message in all cases (citing the invalid value requested)
replacing "only -1 is allowed to set as unlimited" previously used for
`var_zuinteger_unlimited' settings only rather than propagating it to
`var_pinteger' type. It could only be used for the specific case where
a single extra `unlimited' keyword was defined standing for -1 and the
use of numeric equivalents is discouraged anyway as it is for historical
reasons only that they expose GDB internals, confusingly different
across variable types. Similarly update the "must be >= -1" Guile error
message.
Redefine Guile and Python parameter types in terms of the new variable
types and interpret extra keywords as Scheme keywords and Python strings
used to communicate corresponding parameter values. Do not add a new
PARAM_INTEGER Guile parameter type, however do handle the `var_integer'
variable type now, permitting existing parameters defined by GDB proper,
such as `listsize', to be accessed from Scheme code.
With these changes in place it should be trivial for a Scheme or Python
programmer to expand the syntax of the `make-parameter' command and the
`gdb.Parameter' class initializer to have arbitrary extra literals along
with their internal representation supplied.
Update the testsuite accordingly.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
|
|
|
The value is an unsigned integer. The value of @code{None} should be
|
|
|
|
|
interpreted to mean ``unlimited'' (literal @code{'unlimited'} can also
|
|
|
|
|
be used to set that value), and the value of 0 is reserved and should
|
|
|
|
|
not be used.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@findex PARAM_INTEGER
|
|
|
|
|
@findex gdb.PARAM_INTEGER
|
|
|
|
|
@item gdb.PARAM_INTEGER
|
GDB: Allow arbitrary keywords in integer set commands
Rather than just `unlimited' allow the integer set commands (or command
options) to define arbitrary keywords for the user to use, removing
hardcoded arrangements for the `unlimited' keyword.
Remove the confusingly named `var_zinteger', `var_zuinteger' and
`var_zuinteger_unlimited' `set'/`show' command variable types redefining
them in terms of `var_uinteger', `var_integer' and `var_pinteger', which
have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.
Following existing practice `var_pinteger' allows extra negative values
to be used, however unlike `var_zuinteger_unlimited' any number of such
values can be defined rather than just `-1'.
The "p" in `var_pinteger' stands for "positive", for the lack of a more
appropriate unambiguous letter, even though 0 obviously is not positive;
"n" would be confusing as to whether it stands for "non-negative" or
"negative".
Add a new structure, `literal_def', the entries of which define extra
keywords allowed for a command and numerical values they correspond to.
Those values are not verified against the basic range supported by the
underlying variable type, allowing extra values to be allowed outside
that range, which may or may not be individually made visible to the
user. An optional value translation is possible with the structure to
follow the existing practice for some commands where user-entered 0 is
internally translated to UINT_MAX or INT_MAX. Such translation can now
be arbitrary. Literals defined by this structure are automatically used
for completion as necessary.
So for example:
const literal_def integer_unlimited_literals[] =
{
{ "unlimited", INT_MAX, 0 },
{ nullptr }
};
defines an extra `unlimited' keyword and a user-visible 0 value, both of
which get translated to INT_MAX for the setting to be used with.
Similarly:
const literal_def zuinteger_unlimited_literals[] =
{
{ "unlimited", -1, -1 },
{ nullptr }
};
defines the same keyword and a corresponding user-visible -1 value that
is used for the requested setting. If the last member were omitted (or
set to `{}') here, then only the keyword would be allowed for the user
to enter and while -1 would still be used internally trying to enter it
as a part of a command would result in an "integer -1 out of range"
error.
Use said error message in all cases (citing the invalid value requested)
replacing "only -1 is allowed to set as unlimited" previously used for
`var_zuinteger_unlimited' settings only rather than propagating it to
`var_pinteger' type. It could only be used for the specific case where
a single extra `unlimited' keyword was defined standing for -1 and the
use of numeric equivalents is discouraged anyway as it is for historical
reasons only that they expose GDB internals, confusingly different
across variable types. Similarly update the "must be >= -1" Guile error
message.
Redefine Guile and Python parameter types in terms of the new variable
types and interpret extra keywords as Scheme keywords and Python strings
used to communicate corresponding parameter values. Do not add a new
PARAM_INTEGER Guile parameter type, however do handle the `var_integer'
variable type now, permitting existing parameters defined by GDB proper,
such as `listsize', to be accessed from Scheme code.
With these changes in place it should be trivial for a Scheme or Python
programmer to expand the syntax of the `make-parameter' command and the
`gdb.Parameter' class initializer to have arbitrary extra literals along
with their internal representation supplied.
Update the testsuite accordingly.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
|
|
|
The value is a signed integer. The value of @code{None} should be
|
|
|
|
|
interpreted to mean ``unlimited'' (literal @code{'unlimited'} can also
|
|
|
|
|
be used to set that value), and the value of 0 is reserved and should
|
|
|
|
|
not be used.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@findex PARAM_STRING
|
|
|
|
|
@findex gdb.PARAM_STRING
|
|
|
|
|
@item gdb.PARAM_STRING
|
|
|
|
|
The value is a string. When the user modifies the string, any escape
|
|
|
|
|
sequences, such as @samp{\t}, @samp{\f}, and octal escapes, are
|
|
|
|
|
translated into corresponding characters and encoded into the current
|
|
|
|
|
host charset.
|
|
|
|
|
|
|
|
|
|
@findex PARAM_STRING_NOESCAPE
|
|
|
|
|
@findex gdb.PARAM_STRING_NOESCAPE
|
|
|
|
|
@item gdb.PARAM_STRING_NOESCAPE
|
|
|
|
|
The value is a string. When the user modifies the string, escapes are
|
|
|
|
|
passed through untranslated.
|
|
|
|
|
|
|
|
|
|
@findex PARAM_OPTIONAL_FILENAME
|
|
|
|
|
@findex gdb.PARAM_OPTIONAL_FILENAME
|
|
|
|
|
@item gdb.PARAM_OPTIONAL_FILENAME
|
|
|
|
|
The value is a either a filename (a string), or @code{None}.
|
|
|
|
|
|
|
|
|
|
@findex PARAM_FILENAME
|
|
|
|
|
@findex gdb.PARAM_FILENAME
|
|
|
|
|
@item gdb.PARAM_FILENAME
|
|
|
|
|
The value is a filename. This is just like
|
|
|
|
|
@code{PARAM_STRING_NOESCAPE}, but uses file names for completion.
|
|
|
|
|
|
|
|
|
|
@findex PARAM_ZINTEGER
|
|
|
|
|
@findex gdb.PARAM_ZINTEGER
|
|
|
|
|
@item gdb.PARAM_ZINTEGER
|
GDB: Allow arbitrary keywords in integer set commands
Rather than just `unlimited' allow the integer set commands (or command
options) to define arbitrary keywords for the user to use, removing
hardcoded arrangements for the `unlimited' keyword.
Remove the confusingly named `var_zinteger', `var_zuinteger' and
`var_zuinteger_unlimited' `set'/`show' command variable types redefining
them in terms of `var_uinteger', `var_integer' and `var_pinteger', which
have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.
Following existing practice `var_pinteger' allows extra negative values
to be used, however unlike `var_zuinteger_unlimited' any number of such
values can be defined rather than just `-1'.
The "p" in `var_pinteger' stands for "positive", for the lack of a more
appropriate unambiguous letter, even though 0 obviously is not positive;
"n" would be confusing as to whether it stands for "non-negative" or
"negative".
Add a new structure, `literal_def', the entries of which define extra
keywords allowed for a command and numerical values they correspond to.
Those values are not verified against the basic range supported by the
underlying variable type, allowing extra values to be allowed outside
that range, which may or may not be individually made visible to the
user. An optional value translation is possible with the structure to
follow the existing practice for some commands where user-entered 0 is
internally translated to UINT_MAX or INT_MAX. Such translation can now
be arbitrary. Literals defined by this structure are automatically used
for completion as necessary.
So for example:
const literal_def integer_unlimited_literals[] =
{
{ "unlimited", INT_MAX, 0 },
{ nullptr }
};
defines an extra `unlimited' keyword and a user-visible 0 value, both of
which get translated to INT_MAX for the setting to be used with.
Similarly:
const literal_def zuinteger_unlimited_literals[] =
{
{ "unlimited", -1, -1 },
{ nullptr }
};
defines the same keyword and a corresponding user-visible -1 value that
is used for the requested setting. If the last member were omitted (or
set to `{}') here, then only the keyword would be allowed for the user
to enter and while -1 would still be used internally trying to enter it
as a part of a command would result in an "integer -1 out of range"
error.
Use said error message in all cases (citing the invalid value requested)
replacing "only -1 is allowed to set as unlimited" previously used for
`var_zuinteger_unlimited' settings only rather than propagating it to
`var_pinteger' type. It could only be used for the specific case where
a single extra `unlimited' keyword was defined standing for -1 and the
use of numeric equivalents is discouraged anyway as it is for historical
reasons only that they expose GDB internals, confusingly different
across variable types. Similarly update the "must be >= -1" Guile error
message.
Redefine Guile and Python parameter types in terms of the new variable
types and interpret extra keywords as Scheme keywords and Python strings
used to communicate corresponding parameter values. Do not add a new
PARAM_INTEGER Guile parameter type, however do handle the `var_integer'
variable type now, permitting existing parameters defined by GDB proper,
such as `listsize', to be accessed from Scheme code.
With these changes in place it should be trivial for a Scheme or Python
programmer to expand the syntax of the `make-parameter' command and the
`gdb.Parameter' class initializer to have arbitrary extra literals along
with their internal representation supplied.
Update the testsuite accordingly.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
|
|
|
The value is a signed integer. This is like @code{PARAM_INTEGER},
|
|
|
|
|
except that 0 is allowed and the value of @code{None} is not supported.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2018-04-26 16:18:07 -06:00
|
|
|
@findex PARAM_ZUINTEGER
|
|
|
|
|
@findex gdb.PARAM_ZUINTEGER
|
|
|
|
|
@item gdb.PARAM_ZUINTEGER
|
GDB: Allow arbitrary keywords in integer set commands
Rather than just `unlimited' allow the integer set commands (or command
options) to define arbitrary keywords for the user to use, removing
hardcoded arrangements for the `unlimited' keyword.
Remove the confusingly named `var_zinteger', `var_zuinteger' and
`var_zuinteger_unlimited' `set'/`show' command variable types redefining
them in terms of `var_uinteger', `var_integer' and `var_pinteger', which
have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.
Following existing practice `var_pinteger' allows extra negative values
to be used, however unlike `var_zuinteger_unlimited' any number of such
values can be defined rather than just `-1'.
The "p" in `var_pinteger' stands for "positive", for the lack of a more
appropriate unambiguous letter, even though 0 obviously is not positive;
"n" would be confusing as to whether it stands for "non-negative" or
"negative".
Add a new structure, `literal_def', the entries of which define extra
keywords allowed for a command and numerical values they correspond to.
Those values are not verified against the basic range supported by the
underlying variable type, allowing extra values to be allowed outside
that range, which may or may not be individually made visible to the
user. An optional value translation is possible with the structure to
follow the existing practice for some commands where user-entered 0 is
internally translated to UINT_MAX or INT_MAX. Such translation can now
be arbitrary. Literals defined by this structure are automatically used
for completion as necessary.
So for example:
const literal_def integer_unlimited_literals[] =
{
{ "unlimited", INT_MAX, 0 },
{ nullptr }
};
defines an extra `unlimited' keyword and a user-visible 0 value, both of
which get translated to INT_MAX for the setting to be used with.
Similarly:
const literal_def zuinteger_unlimited_literals[] =
{
{ "unlimited", -1, -1 },
{ nullptr }
};
defines the same keyword and a corresponding user-visible -1 value that
is used for the requested setting. If the last member were omitted (or
set to `{}') here, then only the keyword would be allowed for the user
to enter and while -1 would still be used internally trying to enter it
as a part of a command would result in an "integer -1 out of range"
error.
Use said error message in all cases (citing the invalid value requested)
replacing "only -1 is allowed to set as unlimited" previously used for
`var_zuinteger_unlimited' settings only rather than propagating it to
`var_pinteger' type. It could only be used for the specific case where
a single extra `unlimited' keyword was defined standing for -1 and the
use of numeric equivalents is discouraged anyway as it is for historical
reasons only that they expose GDB internals, confusingly different
across variable types. Similarly update the "must be >= -1" Guile error
message.
Redefine Guile and Python parameter types in terms of the new variable
types and interpret extra keywords as Scheme keywords and Python strings
used to communicate corresponding parameter values. Do not add a new
PARAM_INTEGER Guile parameter type, however do handle the `var_integer'
variable type now, permitting existing parameters defined by GDB proper,
such as `listsize', to be accessed from Scheme code.
With these changes in place it should be trivial for a Scheme or Python
programmer to expand the syntax of the `make-parameter' command and the
`gdb.Parameter' class initializer to have arbitrary extra literals along
with their internal representation supplied.
Update the testsuite accordingly.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
|
|
|
The value is an unsigned integer. This is like @code{PARAM_UINTEGER},
|
|
|
|
|
except that 0 is allowed and the value of @code{None} is not supported.
|
2018-04-26 16:18:07 -06:00
|
|
|
|
|
|
|
|
@findex PARAM_ZUINTEGER_UNLIMITED
|
|
|
|
|
@findex gdb.PARAM_ZUINTEGER_UNLIMITED
|
|
|
|
|
@item gdb.PARAM_ZUINTEGER_UNLIMITED
|
GDB: Allow arbitrary keywords in integer set commands
Rather than just `unlimited' allow the integer set commands (or command
options) to define arbitrary keywords for the user to use, removing
hardcoded arrangements for the `unlimited' keyword.
Remove the confusingly named `var_zinteger', `var_zuinteger' and
`var_zuinteger_unlimited' `set'/`show' command variable types redefining
them in terms of `var_uinteger', `var_integer' and `var_pinteger', which
have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.
Following existing practice `var_pinteger' allows extra negative values
to be used, however unlike `var_zuinteger_unlimited' any number of such
values can be defined rather than just `-1'.
The "p" in `var_pinteger' stands for "positive", for the lack of a more
appropriate unambiguous letter, even though 0 obviously is not positive;
"n" would be confusing as to whether it stands for "non-negative" or
"negative".
Add a new structure, `literal_def', the entries of which define extra
keywords allowed for a command and numerical values they correspond to.
Those values are not verified against the basic range supported by the
underlying variable type, allowing extra values to be allowed outside
that range, which may or may not be individually made visible to the
user. An optional value translation is possible with the structure to
follow the existing practice for some commands where user-entered 0 is
internally translated to UINT_MAX or INT_MAX. Such translation can now
be arbitrary. Literals defined by this structure are automatically used
for completion as necessary.
So for example:
const literal_def integer_unlimited_literals[] =
{
{ "unlimited", INT_MAX, 0 },
{ nullptr }
};
defines an extra `unlimited' keyword and a user-visible 0 value, both of
which get translated to INT_MAX for the setting to be used with.
Similarly:
const literal_def zuinteger_unlimited_literals[] =
{
{ "unlimited", -1, -1 },
{ nullptr }
};
defines the same keyword and a corresponding user-visible -1 value that
is used for the requested setting. If the last member were omitted (or
set to `{}') here, then only the keyword would be allowed for the user
to enter and while -1 would still be used internally trying to enter it
as a part of a command would result in an "integer -1 out of range"
error.
Use said error message in all cases (citing the invalid value requested)
replacing "only -1 is allowed to set as unlimited" previously used for
`var_zuinteger_unlimited' settings only rather than propagating it to
`var_pinteger' type. It could only be used for the specific case where
a single extra `unlimited' keyword was defined standing for -1 and the
use of numeric equivalents is discouraged anyway as it is for historical
reasons only that they expose GDB internals, confusingly different
across variable types. Similarly update the "must be >= -1" Guile error
message.
Redefine Guile and Python parameter types in terms of the new variable
types and interpret extra keywords as Scheme keywords and Python strings
used to communicate corresponding parameter values. Do not add a new
PARAM_INTEGER Guile parameter type, however do handle the `var_integer'
variable type now, permitting existing parameters defined by GDB proper,
such as `listsize', to be accessed from Scheme code.
With these changes in place it should be trivial for a Scheme or Python
programmer to expand the syntax of the `make-parameter' command and the
`gdb.Parameter' class initializer to have arbitrary extra literals along
with their internal representation supplied.
Update the testsuite accordingly.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
|
|
|
The value is a signed integer. This is like @code{PARAM_INTEGER}
|
|
|
|
|
including that the value of @code{None} should be interpreted to mean
|
|
|
|
|
``unlimited'' (literal @code{'unlimited'} can also be used to set that
|
|
|
|
|
value), except that 0 is allowed, and the value cannot be negative,
|
|
|
|
|
except the special value -1 is returned for the setting of ``unlimited''.
|
2018-04-26 16:18:07 -06:00
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@findex PARAM_ENUM
|
|
|
|
|
@findex gdb.PARAM_ENUM
|
|
|
|
|
@item gdb.PARAM_ENUM
|
|
|
|
|
The value is a string, which must be one of a collection string
|
|
|
|
|
constants provided when the parameter is created.
|
2024-10-05 22:27:44 +03:00
|
|
|
|
|
|
|
|
@findex PARAM_COLOR
|
|
|
|
|
@findex gdb.PARAM_COLOR
|
|
|
|
|
@item gdb.PARAM_COLOR
|
|
|
|
|
The value is @code{gdb.Color} instance.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end table
|
|
|
|
|
|
gdb/python: new gdb.ParameterPrefix class
This commit adds a new gdb.ParameterPrefix class to GDB's Python API.
When creating multiple gdb.Parameters, it is often desirable to group
these together under a sub-command, for example, 'set print' has lots
of parameters nested under it, like 'set print address', and 'set
print symbol'. In the Python API the 'print' part of these commands
are called prefix commands, and are created using gdb.Command objects.
However, as parameters are set via the 'set ....' command list, and
shown through the 'show ....' command list, creating a prefix for a
parameter usually requires two prefix commands to be created, one for
the 'set' command, and one for the 'show' command.
This often leads to some duplication, or at the very least, each user
will end up creating their own helper class to simplify creation of
the two prefix commands.
This commit adds a new gdb.ParameterPrefix class. Creating a single
instance of this class will create both the 'set' and 'show' prefix
commands, which can then be used while creating the gdb.Parameter.
Here is an example of it in use:
gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE)
This adds 'set my-prefix' and 'show my-prefix', both of which are
prefix commands. The user can then add gdb.Parameter objects under
these prefixes.
The gdb.ParameterPrefix initialise method also supports documentation
strings, so we can write:
gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE,
"Configuration setting relating to my special extension.")
which will set the documentation string for the prefix command.
Also, it is possible to support prefix commands that use the `invoke`
functionality to handle unknown sub-commands. This is done by
sub-classing gdb.ParameterPrefix and overriding either 'invoke_set' or
'invoke_show' to handle the 'set' or 'show' prefix command
respectively.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2025-04-13 11:26:41 +01:00
|
|
|
When creating multiple new parameters using @code{gdb.Parameter}, it
|
|
|
|
|
is often desirable to create a prefix command that can be used to
|
|
|
|
|
group related parameters together, for example, if you wished to add
|
|
|
|
|
the parameters @kbd{plugin-name feature-1} and @kbd{plugin-name
|
|
|
|
|
feature-2}, then the @kbd{plugin-name} would need to be a prefix
|
|
|
|
|
command (@pxref{CLI Commands In Python}).
|
|
|
|
|
|
|
|
|
|
However, when creating parameters, you will almost always need to
|
|
|
|
|
create two prefix commands, one as a @kbd{set} sub-command, and one as
|
|
|
|
|
a @kbd{show} sub-command. @value{GDBN} provides the
|
|
|
|
|
@code{gdb.ParameterPrefix} helper class to make creation of these two
|
|
|
|
|
prefixes easier.
|
|
|
|
|
|
|
|
|
|
@defun ParameterPrefix.__init__ (name, command_class, doc = @code{None})
|
|
|
|
|
The object initializer for @code{ParameterPrefix} registers two new
|
|
|
|
|
@code{gdb.Command} prefixes, one as a @kbd{set} sub-command, and the
|
|
|
|
|
other as a @kbd{show} sub-command.
|
|
|
|
|
|
|
|
|
|
@var{name}, a string, is the name of the new prefix, without either
|
|
|
|
|
@kbd{set} or @kbd{show}, similar to the @var{name} passed to
|
|
|
|
|
@code{gdb.Parameter} (@pxref{Parameters In Python}). For example, to
|
|
|
|
|
create the prefixes @kbd{set plugin-name} and @kbd{show plugin-name},
|
|
|
|
|
you would pass the string @kbd{plugin-name}.
|
|
|
|
|
|
|
|
|
|
@var{command_class} should be one of the @samp{COMMAND_} constants
|
|
|
|
|
(@pxref{CLI Commands In Python}). This argument tells @value{GDBN} how to
|
|
|
|
|
categorize the new parameter prefixes in the help system.
|
|
|
|
|
|
|
|
|
|
There are a number of ways in which the help text for the two new
|
|
|
|
|
prefix commands can be provided. If the @var{doc} parameter is not
|
|
|
|
|
@code{None}, then this will be used as the documentation string for
|
|
|
|
|
both prefix commands.
|
|
|
|
|
|
|
|
|
|
If @var{doc} is @code{None}, but @code{gdb.ParameterPrefix} has been
|
|
|
|
|
sub-classed, then the prefix command documentation will be taken from
|
|
|
|
|
sub-classes documentation string (i.e., the @code{__doc__} attribute).
|
|
|
|
|
|
|
|
|
|
If @var{doc} is @code{None}, and there is no @code{__doc__} string,
|
|
|
|
|
then the default value @samp{This command is not documented.} is used.
|
|
|
|
|
|
|
|
|
|
When writing the help text, keep in mind that the same text is used
|
|
|
|
|
for both the @kbd{set} and @kbd{show} prefix commands.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun ParameterPrefix.invoke_set (argument, from_tty)
|
|
|
|
|
If a sub-class defines this method, then @value{GDBN} will call this
|
|
|
|
|
when the prefix command is used with an unknown sub-command. The
|
|
|
|
|
@var{argument} and @var{from_tty} parameters are the same as for
|
|
|
|
|
@code{gdb.Command.invoke} (@pxref{Command.invoke}).
|
|
|
|
|
|
|
|
|
|
If this method throws an exception, it is turned into a @value{GDBN}
|
|
|
|
|
@code{error} call. Otherwise, the return value is ignored.
|
|
|
|
|
|
|
|
|
|
It is not required that a @code{ParameterPrefix} sub-class override
|
|
|
|
|
this method. Usually, a parameter prefix only exists as a means to
|
|
|
|
|
group related parameters together. @value{GDBN} handles this use case
|
|
|
|
|
automatically with no need to implement @code{invoke_set}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun ParameterPrefix.invoke_show (argument, from_tty)
|
|
|
|
|
This is like the @code{invoke_set} method, but for the @kbd{show}
|
|
|
|
|
prefix command. As with @code{invoke_set}, implementation of this
|
|
|
|
|
method is optional, and usually not required.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@cindex don't repeat Python command
|
|
|
|
|
@defun ParameterPrefix.dont_repeat ()
|
|
|
|
|
Like @code{Command.dont_repeat} (@pxref{Command.dont_repeat}), this
|
|
|
|
|
can be called from @code{ParameterPrefix.invoke_set} or
|
|
|
|
|
@code{ParameterPrefix.invoke_show} to prevent the prefix commands from
|
|
|
|
|
being repeated.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
Here is a small example that uses @code{gdb.ParameterPrefix} along
|
|
|
|
|
with @code{gdb.Parameter} to create two new parameters
|
|
|
|
|
@kbd{plugin-name feature-1} and @kbd{plugin-name feature-2}. As
|
|
|
|
|
neither @code{invoke_set} or @code{invoke_show} is needed, this
|
|
|
|
|
example does not sub-class @code{gdb.ParameterPrefix}:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class ExampleParam(gdb.Parameter):
|
|
|
|
|
def __init__ (self, name):
|
|
|
|
|
super ().__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
|
|
|
|
|
self.value = True
|
|
|
|
|
|
|
|
|
|
gdb.ParameterPrefix("plugin-name", gdb.COMMAND_NONE,
|
|
|
|
|
"""An example parameter prefix.
|
|
|
|
|
|
|
|
|
|
This groups together some parameters.""")
|
|
|
|
|
ExampleParam("plugin-name feature-1")
|
|
|
|
|
ExampleParam("plugin-name feature-2")
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Functions In Python
|
|
|
|
|
@subsubsection Writing new convenience functions
|
|
|
|
|
|
|
|
|
|
@cindex writing convenience functions
|
|
|
|
|
@cindex convenience functions in python
|
|
|
|
|
@cindex python convenience functions
|
|
|
|
|
@tindex gdb.Function
|
|
|
|
|
@tindex Function
|
|
|
|
|
You can implement new convenience functions (@pxref{Convenience Vars})
|
|
|
|
|
in Python. A convenience function is an instance of a subclass of the
|
|
|
|
|
class @code{gdb.Function}.
|
|
|
|
|
|
|
|
|
|
@defun Function.__init__ (name)
|
|
|
|
|
The initializer for @code{Function} registers the new function with
|
|
|
|
|
@value{GDBN}. The argument @var{name} is the name of the function,
|
|
|
|
|
a string. The function will be visible to the user as a convenience
|
|
|
|
|
variable of type @code{internal function}, whose name is the same as
|
|
|
|
|
the given @var{name}.
|
|
|
|
|
|
|
|
|
|
The documentation for the new function is taken from the documentation
|
|
|
|
|
string for the new class.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Function.invoke (*args)
|
2014-02-17 10:35:03 -08:00
|
|
|
When a convenience function is evaluated, its arguments are converted
|
|
|
|
|
to instances of @code{gdb.Value}, and then the function's
|
|
|
|
|
@code{invoke} method is called. Note that @value{GDBN} does not
|
|
|
|
|
predetermine the arity of convenience functions. Instead, all
|
|
|
|
|
available arguments are passed to @code{invoke}, following the
|
|
|
|
|
standard Python calling convention. In particular, a convenience
|
|
|
|
|
function can have default values for parameters without ill effect.
|
|
|
|
|
|
|
|
|
|
The return value of this method is used as its value in the enclosing
|
|
|
|
|
expression. If an ordinary Python value is returned, it is converted
|
|
|
|
|
to a @code{gdb.Value} following the usual rules.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
The following code snippet shows how a trivial convenience function can
|
|
|
|
|
be implemented in Python:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class Greet (gdb.Function):
|
|
|
|
|
"""Return string to greet someone.
|
|
|
|
|
Takes a name as argument."""
|
|
|
|
|
|
|
|
|
|
def __init__ (self):
|
|
|
|
|
super (Greet, self).__init__ ("greet")
|
|
|
|
|
|
|
|
|
|
def invoke (self, name):
|
|
|
|
|
return "Hello, %s!" % name.string ()
|
|
|
|
|
|
|
|
|
|
Greet ()
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The last line instantiates the class, and is necessary to trigger the
|
|
|
|
|
registration of the function with @value{GDBN}. Depending on how the
|
|
|
|
|
Python code is read into @value{GDBN}, you may need to import the
|
|
|
|
|
@code{gdb} module explicitly.
|
|
|
|
|
|
|
|
|
|
Now you can use the function in an expression:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(gdb) print $greet("Bob")
|
|
|
|
|
$1 = "Hello, Bob!"
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@node Progspaces In Python
|
|
|
|
|
@subsubsection Program Spaces In Python
|
|
|
|
|
|
|
|
|
|
@cindex progspaces in python
|
|
|
|
|
@tindex gdb.Progspace
|
|
|
|
|
@tindex Progspace
|
|
|
|
|
A program space, or @dfn{progspace}, represents a symbolic view
|
|
|
|
|
of an address space.
|
|
|
|
|
It consists of all of the objfiles of the program.
|
|
|
|
|
@xref{Objfiles In Python}.
|
2020-01-10 20:06:15 +00:00
|
|
|
@xref{Inferiors Connections and Programs, program spaces}, for more details
|
2014-02-17 10:35:03 -08:00
|
|
|
about program spaces.
|
|
|
|
|
|
|
|
|
|
The following progspace-related functions are available in the
|
|
|
|
|
@code{gdb} module:
|
|
|
|
|
|
|
|
|
|
@defun gdb.current_progspace ()
|
|
|
|
|
This function returns the program space of the currently selected inferior.
|
2020-01-10 20:06:15 +00:00
|
|
|
@xref{Inferiors Connections and Programs}. This is identical to
|
2018-09-13 15:39:26 -04:00
|
|
|
@code{gdb.selected_inferior().progspace} (@pxref{Inferiors In Python}) and is
|
|
|
|
|
included for historical compatibility.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.progspaces ()
|
|
|
|
|
Return a sequence of all the progspaces currently known to @value{GDBN}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
Each progspace is represented by an instance of the @code{gdb.Progspace}
|
|
|
|
|
class.
|
|
|
|
|
|
|
|
|
|
@defvar Progspace.filename
|
2023-08-28 16:58:12 +01:00
|
|
|
The file name, as a string, of the main symbol file (from which debug
|
|
|
|
|
symbols have been loaded) for the progspace, e.g.@: the argument to
|
|
|
|
|
the @kbd{symbol-file} or @kbd{file} commands.
|
|
|
|
|
|
|
|
|
|
If there is no main symbol table currently loaded, then this attribute
|
|
|
|
|
will be @code{None}.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
2023-09-07 11:18:16 +01:00
|
|
|
@defvar Progspace.symbol_file
|
|
|
|
|
The @code{gdb.Objfile} representing the main symbol file (from which
|
|
|
|
|
debug symbols have been loaded) for the @code{gdb.Progspace}. This is
|
|
|
|
|
the symbol file set by the @kbd{symbol-file} or @kbd{file} commands.
|
|
|
|
|
|
|
|
|
|
This will be the @code{gdb.Objfile} representing
|
|
|
|
|
@code{Progspace.filename} when @code{Progspace.filename} is not
|
|
|
|
|
@code{None}.
|
|
|
|
|
|
|
|
|
|
If there is no main symbol table currently loaded, then this attribute
|
|
|
|
|
will be @code{None}.
|
|
|
|
|
|
|
|
|
|
If the @code{Progspace} is invalid, i.e.@:, when
|
|
|
|
|
@code{Progspace.is_valid()} returns @code{False}, then attempting to
|
|
|
|
|
access this attribute will raise a @code{RuntimeError} exception.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2023-09-07 15:47:07 +01:00
|
|
|
@defvar Progspace.executable_filename
|
|
|
|
|
The file name, as a string, of the executable file in use by this
|
|
|
|
|
program space. The executable file is the file that @value{GDBN} will
|
|
|
|
|
invoke in order to start an inferior when using a native target. The
|
|
|
|
|
file name within this attribute is updated by the @kbd{exec-file} and
|
|
|
|
|
@kbd{file} commands.
|
|
|
|
|
|
|
|
|
|
If no executable is currently set within this @code{Progspace} then
|
|
|
|
|
this attribute contains @code{None}.
|
|
|
|
|
|
|
|
|
|
If the @code{Progspace} is invalid, i.e.@:, when
|
|
|
|
|
@code{Progspace.is_valid()} returns @code{False}, then attempting to
|
|
|
|
|
access this attribute will raise a @code{RuntimeError} exception.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar Progspace.pretty_printers
|
|
|
|
|
The @code{pretty_printers} attribute is a list of functions. It is
|
|
|
|
|
used to look up pretty-printers. A @code{Value} is passed to each
|
|
|
|
|
function in order; if the function returns @code{None}, then the
|
|
|
|
|
search continues. Otherwise, the return value should be an object
|
|
|
|
|
which is used to format the value. @xref{Pretty Printing API}, for more
|
|
|
|
|
information.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Progspace.type_printers
|
|
|
|
|
The @code{type_printers} attribute is a list of type printer objects.
|
|
|
|
|
@xref{Type Printing API}, for more information.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Progspace.frame_filters
|
|
|
|
|
The @code{frame_filters} attribute is a dictionary of frame filter
|
|
|
|
|
objects. @xref{Frame Filter API}, for more information.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/python: implement Python find_exec_by_build_id hook
Implement extension_language_ops::find_objfile_from_buildid within
GDB's Python API. Doing this allows users to write Python extensions
that can help locate missing objfiles when GDB opens a core file. A
handler might perform some project- or site-specific actions to find a
missing objfile. Or might provide some project- or site-specific
advice to the user on how they can obtain the missing objfile.
The implementation is very similar to the approach taken in:
commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416
Date: Sun Oct 15 22:48:42 2023 +0100
gdb: implement missing debug handler hook for Python
The following new commands are added as commands implemented in
Python, this is similar to how the Python missing debug and unwinder
commands are implemented:
info missing-objfile-handlers
enable missing-objfile-handler LOCUS HANDLER
disable missing-objfile-handler LOCUS HANDLER
To make use of this extension hook a user will create missing objfile
handler objects, and registers these handlers with GDB. When GDB
opens a core file and encounters a missing objfile each handler is
called in turn until one is able to help. Here is a minimal handler
that does nothing useful:
import gdb
import gdb.missing_objfile
class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, pspace, build_id, filename):
# This handler does nothing useful.
return None
gdb.missing_objfile.register_handler(None, MyFirstHandler())
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing objfile, and GDB should ask any other
registered handlers.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the objfile couldn't
be found. GDB will not call any other handlers, and will
continue without the objfile.
- True: The handler has installed the objfile into a location where
GDB would normally expect to find it. GDB should repeat its
normal lookup process and the objfile should now be found.
- A string: The handler can return a filename, which is the missing
objfile. GDB will load this file.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the missing objfile, at which point GDB continues.
The implementation of this feature is mostly straight forward. I have
reworked some of the missing debug file related code so that it can be
shared with this feature. E.g. gdb/python/lib/gdb/missing_files.py is
mostly content moved from gdb/python/lib/gdb/missing_debug.py, but
updated to be more generic. Now gdb/python/lib/gdb/missing_debug.py
and the new file gdb/python/lib/gdb/missing_objfile.py both call into
the missing_files.py file.
For gdb/python/lib/gdb/command/missing_files.py this is even more
extreme, gdb/python/lib/gdb/command/missing_debug.py is completely
gone now and gdb/python/lib/gdb/command/missing_files.py provides all
of the new commands in a generic way.
I have made one change to the existing Python API, I renamed the
attribute Progspace.missing_debug_handlers to
Progspace.missing_file_handlers. I don't see this as too
problematic. This attribute was only used to implement the missing
debug feature and was never documented beyond the fact that it
existed. There was no reason for users to be touching this attribute.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-07-31 15:55:57 +01:00
|
|
|
@defvar Progspace.missing_file_handlers
|
|
|
|
|
The @code{missing_file_handlers} attribute is a list of tuples. Each
|
|
|
|
|
tuple holds a missing-file handler object for this program space. For
|
|
|
|
|
more information, @pxref{Missing Debug Info In Python}, and
|
|
|
|
|
@ref{Missing Objfiles In Python}.
|
gdb: implement missing debug handler hook for Python
This commit builds on the previous commit, and implements the
extension_language_ops::handle_missing_debuginfo function for Python.
This hook will give user supplied Python code a chance to help find
missing debug information.
The implementation of the new hook is pretty minimal within GDB's C++
code; most of the work is out-sourced to a Python implementation which
is modelled heavily on how GDB's Python frame unwinders are
implemented.
The following new commands are added as commands implemented in
Python, this is similar to how the Python unwinder commands are
implemented:
info missing-debug-handlers
enable missing-debug-handler LOCUS HANDLER
disable missing-debug-handler LOCUS HANDLER
To make use of this extension hook a user will create missing debug
information handler objects, and registers these handlers with GDB.
When GDB encounters an objfile that is missing debug information, each
handler is called in turn until one is able to help. Here is a
minimal handler that does nothing useful:
import gdb
import gdb.missing_debug
class MyFirstHandler(gdb.missing_debug.MissingDebugHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, objfile):
# This handler does nothing useful.
return None
gdb.missing_debug.register_handler(None, MyFirstHandler())
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing debug information, and GDB should ask
any other registered handlers.
By extending the __call__ method it is possible for the Python
extension to locate the debug information for objfile and return a
value that tells GDB how to use the information that has been located.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the debug information
for the objfile still couldn't be found. GDB will not call
any other handlers, and will continue without the debug
information for objfile.
- True: The handler has installed the debug information into a
location where GDB would normally expect to find it. GDB
should look again for the debug information.
- A string: The handler can return a filename, which is the file
containing the missing debug information. GDB will load
this file.
When a handler returns True, GDB will look again for the debug
information, but only using the standard built-in build-id and
.gnu_debuglink based lookup strategies. It is not possible for an
extension to trigger another debuginfod lookup; the assumption is that
the debuginfod server is remote, and out of the control of extensions
running within GDB.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the objfile, at which point GDB continues.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
2023-10-15 22:48:42 +01:00
|
|
|
@end defvar
|
|
|
|
|
|
Add more methods to gdb.Progspace
There are a number of global functions in the gdb Python module which
really should be methods on Progspace. This patch adds new methods to
Progspace and then redefines these globals in terms of these new
methods.
This version has been rebased on the related changes that Simon
recently put in.
Built and regtested on x86-64 Fedora 28.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/lib/gdb/__init__.py (current_progspace, objfiles)
(solib_name, block_for_pc, find_pc_line): New functions.
(execute_unwinders): Update.
* python/py-block.c (gdbpy_block_for_pc): Remove.
* python/py-inferior.c (infpy_get_progspace): New function.
(inferior_object_getset) <progspace>: Add.
* python/py-progspace.c (pspy_objfiles): Rewrite.
(pspy_solib_name, pspy_block_for_pc)
(pspy_find_pc_line, pspy_is_valid): New functions.
(progspace_object_methods): Add entries for solib_name,
block_for_pc, find_pc_line, is_valid.
* python/python-internal.h (gdbpy_block_for_pc)
(build_objfiles_list): Don't declare.
* python/python.c: Don't include solib.h.
(gdbpy_solib_name, gdbpy_find_pc_line)
(gdbpy_get_current_progspace, build_objfiles_list)
(gdbpy_objfiles): Remove.
(GdbMethods) <current_progspace, objfiles, block_for_pc,
solib_name, find_pc_line>: Remove entries.
gdb/doc/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python.texi (Basic Python): Update docs for find_pc_line,
solib_name.
(Progspaces In Python): Update docs for current_progspace.
Document block_for_pc, find_pc_line, is_valid, nsolib_name.
Move method documentation before example.
2013-12-26 19:50:05 -07:00
|
|
|
A program space has the following methods:
|
|
|
|
|
|
|
|
|
|
@defun Progspace.block_for_pc (pc)
|
|
|
|
|
Return the innermost @code{gdb.Block} containing the given @var{pc}
|
|
|
|
|
value. If the block cannot be found for the @var{pc} value specified,
|
|
|
|
|
the function will return @code{None}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Progspace.find_pc_line (pc)
|
|
|
|
|
Return the @code{gdb.Symtab_and_line} object corresponding to the
|
|
|
|
|
@var{pc} value. @xref{Symbol Tables In Python}. If an invalid value
|
|
|
|
|
of @var{pc} is passed as an argument, then the @code{symtab} and
|
|
|
|
|
@code{line} attributes of the returned @code{gdb.Symtab_and_line}
|
|
|
|
|
object will be @code{None} and 0 respectively.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Progspace.is_valid ()
|
|
|
|
|
Returns @code{True} if the @code{gdb.Progspace} object is valid,
|
|
|
|
|
@code{False} if not. A @code{gdb.Progspace} object can become invalid
|
|
|
|
|
if the program space file it refers to is not referenced by any
|
|
|
|
|
inferior. All other @code{gdb.Progspace} methods will throw an
|
|
|
|
|
exception if it is invalid at the time the method is called.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Progspace.objfiles ()
|
|
|
|
|
Return a sequence of all the objfiles referenced by this program
|
|
|
|
|
space. @xref{Objfiles In Python}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Progspace.solib_name (address)
|
|
|
|
|
Return the name of the shared library holding the given @var{address}
|
|
|
|
|
as a string, or @code{None}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-05-22 11:40:10 -06:00
|
|
|
@defun Progspace.objfile_for_address (address)
|
|
|
|
|
Return the @code{gdb.Objfile} holding the given address, or
|
|
|
|
|
@code{None} if no objfile covers it.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-10-30 17:05:17 -07:00
|
|
|
One may add arbitrary attributes to @code{gdb.Progspace} objects
|
|
|
|
|
in the usual Python way.
|
|
|
|
|
This is useful if, for example, one needs to do some extra record keeping
|
|
|
|
|
associated with the program space.
|
|
|
|
|
|
2024-01-10 15:42:55 +00:00
|
|
|
@xref{choosing attribute names}, for guidance on selecting a suitable
|
|
|
|
|
name for new attributes.
|
|
|
|
|
|
2014-10-30 17:05:17 -07:00
|
|
|
In this contrived example, we want to perform some processing when
|
|
|
|
|
an objfile with a certain symbol is loaded, but we only want to do
|
|
|
|
|
this once because it is expensive. To achieve this we record the results
|
|
|
|
|
with the program space because we can't predict when the desired objfile
|
|
|
|
|
will be loaded.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
2024-01-10 15:43:06 +00:00
|
|
|
(@value{GDBP}) python
|
|
|
|
|
@group
|
2014-10-30 17:05:17 -07:00
|
|
|
def clear_objfiles_handler(event):
|
|
|
|
|
event.progspace.expensive_computation = None
|
|
|
|
|
def expensive(symbol):
|
|
|
|
|
"""A mock routine to perform an "expensive" computation on symbol."""
|
2021-01-25 10:28:53 -05:00
|
|
|
print ("Computing the answer to the ultimate question ...")
|
2014-10-30 17:05:17 -07:00
|
|
|
return 42
|
2024-01-10 15:43:06 +00:00
|
|
|
@end group
|
|
|
|
|
@group
|
2014-10-30 17:05:17 -07:00
|
|
|
def new_objfile_handler(event):
|
|
|
|
|
objfile = event.new_objfile
|
|
|
|
|
progspace = objfile.progspace
|
|
|
|
|
if not hasattr(progspace, 'expensive_computation') or \
|
|
|
|
|
progspace.expensive_computation is None:
|
|
|
|
|
# We use 'main' for the symbol to keep the example simple.
|
|
|
|
|
# Note: There's no current way to constrain the lookup
|
|
|
|
|
# to one objfile.
|
|
|
|
|
symbol = gdb.lookup_global_symbol('main')
|
|
|
|
|
if symbol is not None:
|
|
|
|
|
progspace.expensive_computation = expensive(symbol)
|
|
|
|
|
gdb.events.clear_objfiles.connect(clear_objfiles_handler)
|
|
|
|
|
gdb.events.new_objfile.connect(new_objfile_handler)
|
|
|
|
|
end
|
2024-01-10 15:43:06 +00:00
|
|
|
@end group
|
|
|
|
|
@group
|
|
|
|
|
(@value{GDBP}) file /tmp/hello
|
2020-03-04 16:27:56 +01:00
|
|
|
Reading symbols from /tmp/hello...
|
2014-10-30 17:05:17 -07:00
|
|
|
Computing the answer to the ultimate question ...
|
2024-01-10 15:43:06 +00:00
|
|
|
(@value{GDBP}) python print(gdb.current_progspace().expensive_computation)
|
2014-10-30 17:05:17 -07:00
|
|
|
42
|
2024-01-10 15:43:06 +00:00
|
|
|
(@value{GDBP}) run
|
2014-10-30 17:05:17 -07:00
|
|
|
Starting program: /tmp/hello
|
|
|
|
|
Hello.
|
|
|
|
|
[Inferior 1 (process 4242) exited normally]
|
2024-01-10 15:43:06 +00:00
|
|
|
@end group
|
2014-10-30 17:05:17 -07:00
|
|
|
@end smallexample
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Objfiles In Python
|
|
|
|
|
@subsubsection Objfiles In Python
|
|
|
|
|
|
|
|
|
|
@cindex objfiles in python
|
|
|
|
|
@tindex gdb.Objfile
|
|
|
|
|
@tindex Objfile
|
|
|
|
|
@value{GDBN} loads symbols for an inferior from various
|
|
|
|
|
symbol-containing files (@pxref{Files}). These include the primary
|
|
|
|
|
executable file, any shared libraries used by the inferior, and any
|
|
|
|
|
separate debug info files (@pxref{Separate Debug Files}).
|
|
|
|
|
@value{GDBN} calls these symbol-containing files @dfn{objfiles}.
|
|
|
|
|
|
|
|
|
|
The following objfile-related functions are available in the
|
|
|
|
|
@code{gdb} module:
|
|
|
|
|
|
|
|
|
|
@defun gdb.current_objfile ()
|
|
|
|
|
When auto-loading a Python script (@pxref{Python Auto-loading}), @value{GDBN}
|
|
|
|
|
sets the ``current objfile'' to the corresponding objfile. This
|
|
|
|
|
function returns the current objfile. If there is no current objfile,
|
|
|
|
|
this function returns @code{None}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.objfiles ()
|
2018-09-13 15:41:32 -04:00
|
|
|
Return a sequence of objfiles referenced by the current program space.
|
|
|
|
|
@xref{Objfiles In Python}, and @ref{Progspaces In Python}. This is identical
|
|
|
|
|
to @code{gdb.selected_inferior().progspace.objfiles()} and is included for
|
|
|
|
|
historical compatibility.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
2022-01-21 12:49:48 +00:00
|
|
|
@defun gdb.lookup_objfile (name @r{[}, by_build_id@r{]})
|
2014-12-12 09:48:13 -08:00
|
|
|
Look up @var{name}, a file name or build ID, in the list of objfiles
|
|
|
|
|
for the current program space (@pxref{Progspaces In Python}).
|
|
|
|
|
If the objfile is not found throw the Python @code{ValueError} exception.
|
|
|
|
|
|
|
|
|
|
If @var{name} is a relative file name, then it will match any
|
|
|
|
|
source file name with the same trailing components. For example, if
|
|
|
|
|
@var{name} is @samp{gcc/expr.c}, then it will match source file
|
|
|
|
|
name of @file{/build/trunk/gcc/expr.c}, but not
|
|
|
|
|
@file{/build/trunk/libcpp/expr.c} or @file{/build/trunk/gcc/x-expr.c}.
|
|
|
|
|
|
|
|
|
|
If @var{by_build_id} is provided and is @code{True} then @var{name}
|
|
|
|
|
is the build ID of the objfile. Otherwise, @var{name} is a file name.
|
|
|
|
|
This is supported only on some operating systems, notably those which use
|
|
|
|
|
the ELF format for binary files and the @sc{gnu} Binutils. For more details
|
|
|
|
|
about this feature, see the description of the @option{--build-id}
|
2018-09-08 09:29:18 -06:00
|
|
|
command-line option in @ref{Options, , Command Line Options, ld,
|
2014-12-12 09:48:13 -08:00
|
|
|
The GNU Linker}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
Each objfile is represented by an instance of the @code{gdb.Objfile}
|
|
|
|
|
class.
|
|
|
|
|
|
|
|
|
|
@defvar Objfile.filename
|
2015-01-27 10:03:15 -08:00
|
|
|
The file name of the objfile as a string, with symbolic links resolved.
|
|
|
|
|
|
|
|
|
|
The value is @code{None} if the objfile is no longer valid.
|
|
|
|
|
See the @code{gdb.Objfile.is_valid} method, described below.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
2015-01-27 10:13:52 -08:00
|
|
|
@defvar Objfile.username
|
|
|
|
|
The file name of the objfile as specified by the user as a string.
|
|
|
|
|
|
|
|
|
|
The value is @code{None} if the objfile is no longer valid.
|
|
|
|
|
See the @code{gdb.Objfile.is_valid} method, described below.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2022-06-20 12:32:52 -06:00
|
|
|
@defvar Objfile.is_file
|
|
|
|
|
An objfile often comes from an ordinary file, but in some cases it may
|
|
|
|
|
be constructed from the contents of memory. This attribute is
|
|
|
|
|
@code{True} for file-backed objfiles, and @code{False} for other
|
|
|
|
|
kinds.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-12-08 08:50:48 -08:00
|
|
|
@defvar Objfile.owner
|
|
|
|
|
For separate debug info objfiles this is the corresponding @code{gdb.Objfile}
|
|
|
|
|
object that debug info is being provided for.
|
|
|
|
|
Otherwise this is @code{None}.
|
|
|
|
|
Separate debug info objfiles are added with the
|
|
|
|
|
@code{gdb.Objfile.add_separate_debug_file} method, described below.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/python: implement Python find_exec_by_build_id hook
Implement extension_language_ops::find_objfile_from_buildid within
GDB's Python API. Doing this allows users to write Python extensions
that can help locate missing objfiles when GDB opens a core file. A
handler might perform some project- or site-specific actions to find a
missing objfile. Or might provide some project- or site-specific
advice to the user on how they can obtain the missing objfile.
The implementation is very similar to the approach taken in:
commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416
Date: Sun Oct 15 22:48:42 2023 +0100
gdb: implement missing debug handler hook for Python
The following new commands are added as commands implemented in
Python, this is similar to how the Python missing debug and unwinder
commands are implemented:
info missing-objfile-handlers
enable missing-objfile-handler LOCUS HANDLER
disable missing-objfile-handler LOCUS HANDLER
To make use of this extension hook a user will create missing objfile
handler objects, and registers these handlers with GDB. When GDB
opens a core file and encounters a missing objfile each handler is
called in turn until one is able to help. Here is a minimal handler
that does nothing useful:
import gdb
import gdb.missing_objfile
class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, pspace, build_id, filename):
# This handler does nothing useful.
return None
gdb.missing_objfile.register_handler(None, MyFirstHandler())
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing objfile, and GDB should ask any other
registered handlers.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the objfile couldn't
be found. GDB will not call any other handlers, and will
continue without the objfile.
- True: The handler has installed the objfile into a location where
GDB would normally expect to find it. GDB should repeat its
normal lookup process and the objfile should now be found.
- A string: The handler can return a filename, which is the missing
objfile. GDB will load this file.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the missing objfile, at which point GDB continues.
The implementation of this feature is mostly straight forward. I have
reworked some of the missing debug file related code so that it can be
shared with this feature. E.g. gdb/python/lib/gdb/missing_files.py is
mostly content moved from gdb/python/lib/gdb/missing_debug.py, but
updated to be more generic. Now gdb/python/lib/gdb/missing_debug.py
and the new file gdb/python/lib/gdb/missing_objfile.py both call into
the missing_files.py file.
For gdb/python/lib/gdb/command/missing_files.py this is even more
extreme, gdb/python/lib/gdb/command/missing_debug.py is completely
gone now and gdb/python/lib/gdb/command/missing_files.py provides all
of the new commands in a generic way.
I have made one change to the existing Python API, I renamed the
attribute Progspace.missing_debug_handlers to
Progspace.missing_file_handlers. I don't see this as too
problematic. This attribute was only used to implement the missing
debug feature and was never documented beyond the fact that it
existed. There was no reason for users to be touching this attribute.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-07-31 15:55:57 +01:00
|
|
|
@anchor{Objfile.build_id}
|
2014-12-04 11:32:24 -08:00
|
|
|
@defvar Objfile.build_id
|
|
|
|
|
The build ID of the objfile as a string.
|
|
|
|
|
If the objfile does not have a build ID then the value is @code{None}.
|
|
|
|
|
|
|
|
|
|
This is supported only on some operating systems, notably those which use
|
|
|
|
|
the ELF format for binary files and the @sc{gnu} Binutils. For more details
|
|
|
|
|
about this feature, see the description of the @option{--build-id}
|
2018-09-08 09:29:18 -06:00
|
|
|
command-line option in @ref{Options, , Command Line Options, ld,
|
2014-12-04 11:32:24 -08:00
|
|
|
The GNU Linker}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-10-17 10:57:26 -07:00
|
|
|
@defvar Objfile.progspace
|
|
|
|
|
The containing program space of the objfile as a @code{gdb.Progspace}
|
|
|
|
|
object. @xref{Progspaces In Python}.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar Objfile.pretty_printers
|
|
|
|
|
The @code{pretty_printers} attribute is a list of functions. It is
|
|
|
|
|
used to look up pretty-printers. A @code{Value} is passed to each
|
|
|
|
|
function in order; if the function returns @code{None}, then the
|
|
|
|
|
search continues. Otherwise, the return value should be an object
|
|
|
|
|
which is used to format the value. @xref{Pretty Printing API}, for more
|
|
|
|
|
information.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Objfile.type_printers
|
|
|
|
|
The @code{type_printers} attribute is a list of type printer objects.
|
|
|
|
|
@xref{Type Printing API}, for more information.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Objfile.frame_filters
|
|
|
|
|
The @code{frame_filters} attribute is a dictionary of frame filter
|
|
|
|
|
objects. @xref{Frame Filter API}, for more information.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-10-30 17:05:17 -07:00
|
|
|
One may add arbitrary attributes to @code{gdb.Objfile} objects
|
|
|
|
|
in the usual Python way.
|
|
|
|
|
This is useful if, for example, one needs to do some extra record keeping
|
|
|
|
|
associated with the objfile.
|
|
|
|
|
|
2024-01-10 15:42:55 +00:00
|
|
|
@xref{choosing attribute names}, for guidance on selecting a suitable
|
|
|
|
|
name for new attributes.
|
|
|
|
|
|
2014-10-30 17:05:17 -07:00
|
|
|
In this contrived example we record the time when @value{GDBN}
|
|
|
|
|
loaded the objfile.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
2024-01-10 15:43:06 +00:00
|
|
|
@group
|
|
|
|
|
(@value{GDBP}) python
|
2014-10-30 17:05:17 -07:00
|
|
|
import datetime
|
|
|
|
|
def new_objfile_handler(event):
|
|
|
|
|
# Set the time_loaded attribute of the new objfile.
|
|
|
|
|
event.new_objfile.time_loaded = datetime.datetime.today()
|
|
|
|
|
gdb.events.new_objfile.connect(new_objfile_handler)
|
|
|
|
|
end
|
2024-01-10 15:43:06 +00:00
|
|
|
@end group
|
|
|
|
|
@group
|
|
|
|
|
(@value{GDBP}) file ./hello
|
2020-03-04 16:27:56 +01:00
|
|
|
Reading symbols from ./hello...
|
2024-01-10 15:43:06 +00:00
|
|
|
(@value{GDBP}) python print(gdb.objfiles()[0].time_loaded)
|
2014-10-30 17:05:17 -07:00
|
|
|
2014-10-09 11:41:36.770345
|
2024-01-10 15:43:06 +00:00
|
|
|
@end group
|
2014-10-30 17:05:17 -07:00
|
|
|
@end smallexample
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
A @code{gdb.Objfile} object has the following methods:
|
|
|
|
|
|
|
|
|
|
@defun Objfile.is_valid ()
|
|
|
|
|
Returns @code{True} if the @code{gdb.Objfile} object is valid,
|
|
|
|
|
@code{False} if not. A @code{gdb.Objfile} object can become invalid
|
|
|
|
|
if the object file it refers to is not loaded in @value{GDBN} any
|
|
|
|
|
longer. All other @code{gdb.Objfile} methods will throw an exception
|
|
|
|
|
if it is invalid at the time the method is called.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-12-04 12:01:22 -08:00
|
|
|
@defun Objfile.add_separate_debug_file (file)
|
|
|
|
|
Add @var{file} to the list of files that @value{GDBN} will search for
|
|
|
|
|
debug information for the objfile.
|
|
|
|
|
This is useful when the debug info has been removed from the program
|
|
|
|
|
and stored in a separate file. @value{GDBN} has built-in support for
|
|
|
|
|
finding separate debug info files (@pxref{Separate Debug Files}), but if
|
|
|
|
|
the file doesn't live in one of the standard places that @value{GDBN}
|
|
|
|
|
searches then this function can be used to add a debug info file
|
|
|
|
|
from a different place.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2019-06-25 15:45:41 -05:00
|
|
|
@defun Objfile.lookup_global_symbol (name @r{[}, domain@r{]})
|
|
|
|
|
Search for a global symbol named @var{name} in this objfile. Optionally, the
|
|
|
|
|
search scope can be restricted with the @var{domain} argument.
|
|
|
|
|
The @var{domain} argument must be a domain constant defined in the @code{gdb}
|
|
|
|
|
module and described in @ref{Symbols In Python}. This function is similar to
|
|
|
|
|
@code{gdb.lookup_global_symbol}, except that the search is limited to this
|
|
|
|
|
objfile.
|
|
|
|
|
|
|
|
|
|
The result is a @code{gdb.Symbol} object or @code{None} if the symbol
|
|
|
|
|
is not found.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Objfile.lookup_static_symbol (name @r{[}, domain@r{]})
|
|
|
|
|
Like @code{Objfile.lookup_global_symbol}, but searches for a global
|
|
|
|
|
symbol with static linkage named @var{name} in this objfile.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Frames In Python
|
2018-09-08 14:00:48 -06:00
|
|
|
@subsubsection Accessing inferior stack frames from Python
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@cindex frames in python
|
|
|
|
|
When the debugged program stops, @value{GDBN} is able to analyze its call
|
|
|
|
|
stack (@pxref{Frames,,Stack frames}). The @code{gdb.Frame} class
|
|
|
|
|
represents a frame in the stack. A @code{gdb.Frame} object is only valid
|
|
|
|
|
while its corresponding frame exists in the inferior's stack. If you try
|
|
|
|
|
to use an invalid frame object, @value{GDBN} will throw a @code{gdb.error}
|
|
|
|
|
exception (@pxref{Exception Handling}).
|
|
|
|
|
|
|
|
|
|
Two @code{gdb.Frame} objects can be compared for equality with the @code{==}
|
|
|
|
|
operator, like:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(@value{GDBP}) python print gdb.newest_frame() == gdb.selected_frame ()
|
|
|
|
|
True
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The following frame-related functions are available in the @code{gdb} module:
|
|
|
|
|
|
|
|
|
|
@defun gdb.selected_frame ()
|
|
|
|
|
Return the selected frame object. (@pxref{Selection,,Selecting a Frame}).
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.newest_frame ()
|
|
|
|
|
Return the newest frame object for the selected thread.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.frame_stop_reason_string (reason)
|
|
|
|
|
Return a string explaining the reason why @value{GDBN} stopped unwinding
|
|
|
|
|
frames, as expressed by the given @var{reason} code (an integer, see the
|
|
|
|
|
@code{unwind_stop_reason} method further down in this section).
|
|
|
|
|
@end defun
|
|
|
|
|
|
2016-06-09 15:20:09 -06:00
|
|
|
@defun gdb.invalidate_cached_frames
|
|
|
|
|
@value{GDBN} internally keeps a cache of the frames that have been
|
|
|
|
|
unwound. This function invalidates this cache.
|
|
|
|
|
|
|
|
|
|
This function should not generally be called by ordinary Python code.
|
|
|
|
|
It is documented for the sake of completeness.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
A @code{gdb.Frame} object has the following methods:
|
|
|
|
|
|
|
|
|
|
@defun Frame.is_valid ()
|
|
|
|
|
Returns true if the @code{gdb.Frame} object is valid, false if not.
|
|
|
|
|
A frame object can become invalid if the frame it refers to doesn't
|
|
|
|
|
exist anymore in the inferior. All @code{gdb.Frame} methods will throw
|
|
|
|
|
an exception if it is invalid at the time the method is called.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Frame.name ()
|
|
|
|
|
Returns the function name of the frame, or @code{None} if it can't be
|
|
|
|
|
obtained.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Frame.architecture ()
|
|
|
|
|
Returns the @code{gdb.Architecture} object corresponding to the frame's
|
|
|
|
|
architecture. @xref{Architectures In Python}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Frame.type ()
|
|
|
|
|
Returns the type of the frame. The value can be one of:
|
|
|
|
|
@table @code
|
|
|
|
|
@item gdb.NORMAL_FRAME
|
|
|
|
|
An ordinary stack frame.
|
|
|
|
|
|
|
|
|
|
@item gdb.DUMMY_FRAME
|
|
|
|
|
A fake stack frame that was created by @value{GDBN} when performing an
|
|
|
|
|
inferior function call.
|
|
|
|
|
|
|
|
|
|
@item gdb.INLINE_FRAME
|
|
|
|
|
A frame representing an inlined function. The function was inlined
|
|
|
|
|
into a @code{gdb.NORMAL_FRAME} that is older than this one.
|
|
|
|
|
|
|
|
|
|
@item gdb.TAILCALL_FRAME
|
|
|
|
|
A frame representing a tail call. @xref{Tail Call Frames}.
|
|
|
|
|
|
|
|
|
|
@item gdb.SIGTRAMP_FRAME
|
|
|
|
|
A signal trampoline frame. This is the frame created by the OS when
|
|
|
|
|
it calls into a signal handler.
|
|
|
|
|
|
|
|
|
|
@item gdb.ARCH_FRAME
|
|
|
|
|
A fake stack frame representing a cross-architecture call.
|
|
|
|
|
|
|
|
|
|
@item gdb.SENTINEL_FRAME
|
|
|
|
|
This is like @code{gdb.NORMAL_FRAME}, but it is only used for the
|
|
|
|
|
newest frame.
|
|
|
|
|
@end table
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Frame.unwind_stop_reason ()
|
|
|
|
|
Return an integer representing the reason why it's not possible to find
|
|
|
|
|
more frames toward the outermost frame. Use
|
|
|
|
|
@code{gdb.frame_stop_reason_string} to convert the value returned by this
|
|
|
|
|
function to a string. The value can be one of:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@item gdb.FRAME_UNWIND_NO_REASON
|
|
|
|
|
No particular reason (older frames should be available).
|
|
|
|
|
|
|
|
|
|
@item gdb.FRAME_UNWIND_NULL_ID
|
|
|
|
|
The previous frame's analyzer returns an invalid result. This is no
|
|
|
|
|
longer used by @value{GDBN}, and is kept only for backward
|
|
|
|
|
compatibility.
|
|
|
|
|
|
|
|
|
|
@item gdb.FRAME_UNWIND_OUTERMOST
|
|
|
|
|
This frame is the outermost.
|
|
|
|
|
|
|
|
|
|
@item gdb.FRAME_UNWIND_UNAVAILABLE
|
|
|
|
|
Cannot unwind further, because that would require knowing the
|
|
|
|
|
values of registers or memory that have not been collected.
|
|
|
|
|
|
|
|
|
|
@item gdb.FRAME_UNWIND_INNER_ID
|
|
|
|
|
This frame ID looks like it ought to belong to a NEXT frame,
|
|
|
|
|
but we got it for a PREV frame. Normally, this is a sign of
|
|
|
|
|
unwinder failure. It could also indicate stack corruption.
|
|
|
|
|
|
|
|
|
|
@item gdb.FRAME_UNWIND_SAME_ID
|
|
|
|
|
This frame has the same ID as the previous one. That means
|
|
|
|
|
that unwinding further would almost certainly give us another
|
|
|
|
|
frame with exactly the same ID, so break the chain. Normally,
|
|
|
|
|
this is a sign of unwinder failure. It could also indicate
|
|
|
|
|
stack corruption.
|
|
|
|
|
|
|
|
|
|
@item gdb.FRAME_UNWIND_NO_SAVED_PC
|
|
|
|
|
The frame unwinder did not find any saved PC, but we needed
|
|
|
|
|
one to unwind further.
|
|
|
|
|
|
Add a TRY_CATCH to get_prev_frame_always to better manage errors during unwind.
https://sourceware.org/ml/gdb-patches/2014-05/msg00737.html
Currently a MEMORY_ERROR raised during unwinding a frame will cause the
unwind to stop with an error message, for example:
(gdb) bt
#0 breakpt () at amd64-invalid-stack-middle.c:27
#1 0x00000000004008f0 in func5 () at amd64-invalid-stack-middle.c:32
#2 0x0000000000400900 in func4 () at amd64-invalid-stack-middle.c:38
#3 0x0000000000400910 in func3 () at amd64-invalid-stack-middle.c:44
#4 0x0000000000400928 in func2 () at amd64-invalid-stack-middle.c:50
Cannot access memory at address 0x2aaaaaab0000
However, frame #4 is marked as being the end of the stack unwind, so a
subsequent request for the backtrace looses the error message, such as:
(gdb) bt
#0 breakpt () at amd64-invalid-stack-middle.c:27
#1 0x00000000004008f0 in func5 () at amd64-invalid-stack-middle.c:32
#2 0x0000000000400900 in func4 () at amd64-invalid-stack-middle.c:38
#3 0x0000000000400910 in func3 () at amd64-invalid-stack-middle.c:44
#4 0x0000000000400928 in func2 () at amd64-invalid-stack-middle.c:50
When fetching the backtrace, or requesting the stack depth using the MI
interface the situation is even worse, the first time a request is made
we encounter the memory error and so the MI returns an error instead of
the correct result, for example:
(gdb) -stack-info-depth
^error,msg="Cannot access memory at address 0x2aaaaaab0000"
Or,
(gdb) -stack-list-frames
^error,msg="Cannot access memory at address 0x2aaaaaab0000"
However, once one of these commands has been used gdb has, internally,
walked the stack and figured that out that frame #4 is the bottom of the
stack, so the second time an MI command is tried you'll get the "expected"
result:
(gdb) -stack-info-depth
^done,depth="5"
Or,
(gdb) -stack-list-frames
^done,stack=[frame={level="0", .. snip lots .. }]
After this patch the MEMORY_ERROR encountered during the frame unwind is
attached to frame #4 as the stop reason, and is displayed in the CLI each
time the backtrace is requested. In the MI, catching the error means that
the "expected" result is returned the first time the MI command is issued.
So, from the CLI the results of the backtrace will be:
(gdb) bt
#0 breakpt () at amd64-invalid-stack-middle.c:27
#1 0x00000000004008f0 in func5 () at amd64-invalid-stack-middle.c:32
#2 0x0000000000400900 in func4 () at amd64-invalid-stack-middle.c:38
#3 0x0000000000400910 in func3 () at amd64-invalid-stack-middle.c:44
#4 0x0000000000400928 in func2 () at amd64-invalid-stack-middle.c:50
Backtrace stopped: Cannot access memory at address 0x2aaaaaab0000
Each and every time that the backtrace is requested, while the MI output
will similarly be consistently:
(gdb) -stack-info-depth
^done,depth="5"
Or,
(gdb) -stack-list-frames
^done,stack=[frame={level="0", .. snip lots .. }]
gdb/ChangeLog:
* frame.c (struct frame_info): Add stop_string field.
(get_prev_frame_always_1): Renamed from get_prev_frame_always.
(get_prev_frame_always): Old content moved into
get_prev_frame_always_1. Call get_prev_frame_always_1 inside
TRY_CATCH, handle MEMORY_ERROR exceptions.
(frame_stop_reason_string): New function definition.
* frame.h (unwind_stop_reason_to_string): Extend comment to
mention frame_stop_reason_string.
(frame_stop_reason_string): New function declaration.
* stack.c (frame_info): Switch to frame_stop_reason_string.
(backtrace_command_1): Switch to frame_stop_reason_string.
* unwind_stop_reason.def: Add UNWIND_MEMORY_ERROR.
(LAST_ENTRY): Changed to UNWIND_MEMORY_ERROR.
* guile/lib/gdb.scm: Add FRAME_UNWIND_MEMORY_ERROR to export list.
gdb/doc/ChangeLog:
* guile.texi (Frames In Guile): Mention FRAME_UNWIND_MEMORY_ERROR.
* python.texi (Frames In Python): Mention
gdb.FRAME_UNWIND_MEMORY_ERROR.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-invalid-stack-middle.exp: Update expected results.
* gdb.arch/amd64-invalid-stack-top.exp: Likewise.
2014-05-28 23:34:43 +01:00
|
|
|
@item gdb.FRAME_UNWIND_MEMORY_ERROR
|
|
|
|
|
The frame unwinder caused an error while trying to access memory.
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.FRAME_UNWIND_FIRST_ERROR
|
|
|
|
|
Any stop reason greater or equal to this value indicates some kind
|
|
|
|
|
of error. This special value facilitates writing code that tests
|
|
|
|
|
for errors in unwinding in a way that will work correctly even if
|
|
|
|
|
the list of the other values is modified in future @value{GDBN}
|
|
|
|
|
versions. Using it, you could write:
|
|
|
|
|
@smallexample
|
|
|
|
|
reason = gdb.selected_frame().unwind_stop_reason ()
|
|
|
|
|
reason_str = gdb.frame_stop_reason_string (reason)
|
|
|
|
|
if reason >= gdb.FRAME_UNWIND_FIRST_ERROR:
|
2023-06-03 22:43:57 +02:00
|
|
|
print ("An error occurred: %s" % reason_str)
|
2014-02-17 10:35:03 -08:00
|
|
|
@end smallexample
|
|
|
|
|
@end table
|
|
|
|
|
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Frame.pc ()
|
|
|
|
|
Returns the frame's resume address.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Frame.block ()
|
2018-09-08 09:08:56 -06:00
|
|
|
Return the frame's code block. @xref{Blocks In Python}. If the frame
|
|
|
|
|
does not have a block -- for example, if there is no debugging
|
|
|
|
|
information for the code in question -- then this will throw an
|
|
|
|
|
exception.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Frame.function ()
|
|
|
|
|
Return the symbol for the function corresponding to this frame.
|
|
|
|
|
@xref{Symbols In Python}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Frame.older ()
|
2023-05-19 09:40:35 -06:00
|
|
|
Return the frame that called this frame. If this is the oldest frame,
|
|
|
|
|
return @code{None}.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Frame.newer ()
|
2023-05-19 09:40:35 -06:00
|
|
|
Return the frame called by this frame. If this is the newest frame,
|
|
|
|
|
return @code{None}.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Frame.find_sal ()
|
|
|
|
|
Return the frame's symtab and line object.
|
|
|
|
|
@xref{Symbol Tables In Python}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
gdb/python: Add gdb.Architecture.registers method
This commit adds a new method gdb.Architecture.registers that returns
an object of the new type gdb.RegisterDescriptorIterator. This
iterator returns objects of the new type gdb.RegisterDescriptor.
A RegisterDescriptor is not a way to read the value of a register,
this is already covered by Frame.read_register, a RegisterDescriptor
is simply a way to discover from Python, which registers are
available for a given architecture.
I did consider just returning a string, the name of each register,
instead of a RegisterDescriptor, however, I'm aware that it we don't
want to break the existing Python API in any way, so if I return just
a string now, but in the future we want more information about a
register then we would have to add a second API to get that
information. By going straight to a descriptor object now, it is easy
to add additional properties in the future should we wish to.
Right now the only property of a register that a user can access is
the name of the register.
In future we might want to be able to ask the register about is
register groups, or its type.
gdb/ChangeLog:
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c
* python/py-arch.c (archpy_registers): New function.
(arch_object_methods): Add 'registers' method.
* python/py-registers.c: New file.
* python/python-internal.h
(gdbpy_new_register_descriptor_iterator): Declare.
(gdbpy_initialize_registers): Declare.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_registers.
* NEWS: Mention additions to the Python API.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: New file.
gdb/doc/ChangeLog:
* python.texi (Python API): Add new section the menu.
(Frames In Python): Add new @anchor.
(Architectures In Python): Document new registers method.
(Registers In Python): New section.
2020-06-05 17:52:10 +01:00
|
|
|
@anchor{gdbpy_frame_read_register}
|
2014-09-03 16:34:47 -07:00
|
|
|
@defun Frame.read_register (register)
|
gdb/python: make more use of RegisterDescriptors
This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.
Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number. I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind. However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.
Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.
This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.
The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly. However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.
As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.
After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.
gdb/ChangeLog:
* python/py-frame.c: Remove 'user-regs.h' include.
(frapy_read_register): Rewrite to make use of
gdbpy_parse_register_id.
* python/py-registers.c (gdbpy_parse_register_id): New function,
moved here from python/py-unwind.c. Updated the return type, and
also accepts register descriptor objects.
* python/py-unwind.c: Remove 'user-regs.h' include.
(pyuw_parse_register_id): Moved to python/py-registers.c.
(unwind_infopy_add_saved_register): Update to use
gdbpy_parse_register_id.
(pending_framepy_read_register): Likewise.
* python/python-internal.h (gdbpy_parse_register_id): Declare.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py: Update to make use of a register
descriptor.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Update descriptions
for PendingFrame.read_register and
gdb.UnwindInfo.add_saved_register.
(Frames In Python): Update description of Frame.read_register.
2020-07-22 12:13:11 +01:00
|
|
|
Return the value of @var{register} in this frame. Returns a
|
|
|
|
|
@code{Gdb.Value} object. Throws an exception if @var{register} does
|
|
|
|
|
not exist. The @var{register} argument must be one of the following:
|
|
|
|
|
@enumerate
|
|
|
|
|
@item
|
|
|
|
|
A string that is the name of a valid register (e.g., @code{'sp'} or
|
|
|
|
|
@code{'rax'}).
|
|
|
|
|
@item
|
|
|
|
|
A @code{gdb.RegisterDescriptor} object (@pxref{Registers In Python}).
|
|
|
|
|
@item
|
|
|
|
|
A @value{GDBN} internal, platform specific number. Using these
|
|
|
|
|
numbers is supported for historic reasons, but is not recommended as
|
|
|
|
|
future changes to @value{GDBN} could change the mapping between
|
|
|
|
|
numbers and the registers they represent, breaking any Python code
|
|
|
|
|
that uses the platform-specific numbers. The numbers are usually
|
|
|
|
|
found in the corresponding @file{@var{platform}-tdep.h} file in the
|
|
|
|
|
@value{GDBN} source tree.
|
|
|
|
|
@end enumerate
|
|
|
|
|
Using a string to access registers will be slightly slower than the
|
|
|
|
|
other two methods as @value{GDBN} must look up the mapping between
|
|
|
|
|
name and internal register number. If performance is critical
|
|
|
|
|
consider looking up and caching a @code{gdb.RegisterDescriptor}
|
|
|
|
|
object.
|
2014-09-03 16:34:47 -07:00
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun Frame.read_var (variable @r{[}, block@r{]})
|
|
|
|
|
Return the value of @var{variable} in this frame. If the optional
|
|
|
|
|
argument @var{block} is provided, search for the variable from that
|
|
|
|
|
block; otherwise start at the frame's current block (which is
|
Don't use @var at the beginning of a sentence in GDB documentation.
gdb/doc/guile.texi (Types In Guile, Basic Guile, Frames In Guile)
(Breakpoints In Guile, Guile Printing Module)
(Guile Exception Handling, Values From Inferior In Guile)
(Objfiles In Guile, Breakpoints In Guile, Memory Ports in Guile):
Don't use @var at the beginning of a sentence.
gdb/doc/gdb.texinfo (Frame Filter Management, Trace Files)
(C Operators, Ada Tasks, Calling, Bootstrapping, ARM)
(PowerPC Embedded, Define, Annotations for Running)
(IPA Protocol Commands, Packets, General Query Packets)
(Tracepoint Packets, Notification Packets, Environment)
(Inferiors and Programs, Set Breaks, Set Catchpoints)
(Continuing and Stepping, Signals, Thread-Specific Breakpoints)
(Frames, Backtrace, Selection, Expressions, Registers)
(Trace State Variables, Built-In Func/Proc, Signaling, Files)
(Numbers, GDB/MI Async Records, GDB/MI Data Manipulation)
(Source Annotations, Using JIT Debug Info Readers, Packets)
(Stop Reply Packets, Host I/O Packets)
(Target Description Format): Don't use @var at the beginning of a
sentence.
gdb/doc/python.texi (Basic Python, Types In Python)
(Commands In Python, Frames In Python, Line Tables In Python)
(Breakpoints In Python, gdb.printing, gdb.types)
(Type Printing API): Don't use @var at the beginning of a
sentence.
2014-05-24 13:02:42 +03:00
|
|
|
determined by the frame's current program counter). The @var{variable}
|
|
|
|
|
argument must be a string or a @code{gdb.Symbol} object; @var{block} must be a
|
2014-02-17 10:35:03 -08:00
|
|
|
@code{gdb.Block} object.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Frame.select ()
|
|
|
|
|
Set this frame to be the selected frame. @xref{Stack, ,Examining the
|
|
|
|
|
Stack}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-10-24 08:05:06 -06:00
|
|
|
@defun Frame.static_link ()
|
|
|
|
|
In some languages (e.g., Ada, but also a GNU C extension), a nested
|
|
|
|
|
function can access the variables in the outer scope. This is done
|
|
|
|
|
via a ``static link'', which is a reference from the nested frame to
|
|
|
|
|
the appropriate outer frame.
|
|
|
|
|
|
|
|
|
|
This method returns this frame's static link frame, if one exists. If
|
|
|
|
|
there is no static link, this method returns @code{None}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2021-05-26 22:01:59 +01:00
|
|
|
@defun Frame.level ()
|
|
|
|
|
Return an integer, the stack frame level for this frame. @xref{Frames, ,Stack Frames}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2022-05-24 10:15:17 -06:00
|
|
|
@defun Frame.language ()
|
|
|
|
|
Return a string, the source language for this frame.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Blocks In Python
|
2018-09-08 14:00:48 -06:00
|
|
|
@subsubsection Accessing blocks from Python
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@cindex blocks in python
|
|
|
|
|
@tindex gdb.Block
|
|
|
|
|
|
|
|
|
|
In @value{GDBN}, symbols are stored in blocks. A block corresponds
|
|
|
|
|
roughly to a scope in the source code. Blocks are organized
|
|
|
|
|
hierarchically, and are represented individually in Python as a
|
|
|
|
|
@code{gdb.Block}. Blocks rely on debugging information being
|
|
|
|
|
available.
|
|
|
|
|
|
|
|
|
|
A frame has a block. Please see @ref{Frames In Python}, for a more
|
|
|
|
|
in-depth discussion of frames.
|
|
|
|
|
|
|
|
|
|
The outermost block is known as the @dfn{global block}. The global
|
|
|
|
|
block typically holds public global variables and functions.
|
|
|
|
|
|
|
|
|
|
The block nested just inside the global block is the @dfn{static
|
|
|
|
|
block}. The static block typically holds file-scoped variables and
|
|
|
|
|
functions.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} provides a method to get a block's superblock, but there
|
|
|
|
|
is currently no way to examine the sub-blocks of a block, or to
|
|
|
|
|
iterate over all the blocks in a symbol table (@pxref{Symbol Tables In
|
|
|
|
|
Python}).
|
|
|
|
|
|
|
|
|
|
Here is a short example that should help explain blocks:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
/* This is in the global block. */
|
|
|
|
|
int global;
|
|
|
|
|
|
|
|
|
|
/* This is in the static block. */
|
|
|
|
|
static int file_scope;
|
|
|
|
|
|
|
|
|
|
/* 'function' is in the global block, and 'argument' is
|
|
|
|
|
in a block nested inside of 'function'. */
|
|
|
|
|
int function (int argument)
|
|
|
|
|
@{
|
|
|
|
|
/* 'local' is in a block inside 'function'. It may or may
|
|
|
|
|
not be in the same block as 'argument'. */
|
|
|
|
|
int local;
|
|
|
|
|
|
|
|
|
|
@{
|
|
|
|
|
/* 'inner' is in a block whose superblock is the one holding
|
|
|
|
|
'local'. */
|
|
|
|
|
int inner;
|
|
|
|
|
|
|
|
|
|
/* If this call is expanded by the compiler, you may see
|
|
|
|
|
a nested block here whose function is 'inline_function'
|
|
|
|
|
and whose superblock is the one holding 'inner'. */
|
|
|
|
|
inline_function ();
|
|
|
|
|
@}
|
|
|
|
|
@}
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
A @code{gdb.Block} is iterable. The iterator returns the symbols
|
|
|
|
|
(@pxref{Symbols In Python}) local to the block. Python programs
|
|
|
|
|
should not assume that a specific block object will always contain a
|
|
|
|
|
given symbol, since changes in @value{GDBN} features and
|
|
|
|
|
infrastructure may cause symbols move across blocks in a symbol
|
2019-08-01 17:22:28 -05:00
|
|
|
table. You can also use Python's @dfn{dictionary syntax} to access
|
|
|
|
|
variables in this block, e.g.:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
symbol = some_block['variable'] # symbol is of type gdb.Symbol
|
|
|
|
|
@end smallexample
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
The following block-related functions are available in the @code{gdb}
|
|
|
|
|
module:
|
|
|
|
|
|
|
|
|
|
@defun gdb.block_for_pc (pc)
|
|
|
|
|
Return the innermost @code{gdb.Block} containing the given @var{pc}
|
|
|
|
|
value. If the block cannot be found for the @var{pc} value specified,
|
Add more methods to gdb.Progspace
There are a number of global functions in the gdb Python module which
really should be methods on Progspace. This patch adds new methods to
Progspace and then redefines these globals in terms of these new
methods.
This version has been rebased on the related changes that Simon
recently put in.
Built and regtested on x86-64 Fedora 28.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/lib/gdb/__init__.py (current_progspace, objfiles)
(solib_name, block_for_pc, find_pc_line): New functions.
(execute_unwinders): Update.
* python/py-block.c (gdbpy_block_for_pc): Remove.
* python/py-inferior.c (infpy_get_progspace): New function.
(inferior_object_getset) <progspace>: Add.
* python/py-progspace.c (pspy_objfiles): Rewrite.
(pspy_solib_name, pspy_block_for_pc)
(pspy_find_pc_line, pspy_is_valid): New functions.
(progspace_object_methods): Add entries for solib_name,
block_for_pc, find_pc_line, is_valid.
* python/python-internal.h (gdbpy_block_for_pc)
(build_objfiles_list): Don't declare.
* python/python.c: Don't include solib.h.
(gdbpy_solib_name, gdbpy_find_pc_line)
(gdbpy_get_current_progspace, build_objfiles_list)
(gdbpy_objfiles): Remove.
(GdbMethods) <current_progspace, objfiles, block_for_pc,
solib_name, find_pc_line>: Remove entries.
gdb/doc/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python.texi (Basic Python): Update docs for find_pc_line,
solib_name.
(Progspaces In Python): Update docs for current_progspace.
Document block_for_pc, find_pc_line, is_valid, nsolib_name.
Move method documentation before example.
2013-12-26 19:50:05 -07:00
|
|
|
the function will return @code{None}. This is identical to
|
|
|
|
|
@code{gdb.current_progspace().block_for_pc(pc)} and is included for
|
|
|
|
|
historical compatibility.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
A @code{gdb.Block} object has the following methods:
|
|
|
|
|
|
|
|
|
|
@defun Block.is_valid ()
|
|
|
|
|
Returns @code{True} if the @code{gdb.Block} object is valid,
|
|
|
|
|
@code{False} if not. A block object can become invalid if the block it
|
|
|
|
|
refers to doesn't exist anymore in the inferior. All other
|
|
|
|
|
@code{gdb.Block} methods will throw an exception if it is invalid at
|
|
|
|
|
the time the method is called. The block's validity is also checked
|
|
|
|
|
during iteration over symbols of the block.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
A @code{gdb.Block} object has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar Block.start
|
|
|
|
|
The start address of the block. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Block.end
|
2018-09-08 08:59:00 -06:00
|
|
|
One past the last address that appears in the block. This attribute
|
|
|
|
|
is not writable.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Block.function
|
|
|
|
|
The name of the block represented as a @code{gdb.Symbol}. If the
|
|
|
|
|
block is not named, then this attribute holds @code{None}. This
|
|
|
|
|
attribute is not writable.
|
|
|
|
|
|
|
|
|
|
For ordinary function blocks, the superblock is the static block.
|
|
|
|
|
However, you should note that it is possible for a function block to
|
|
|
|
|
have a superblock that is not the static block -- for instance this
|
|
|
|
|
happens for an inlined function.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Block.superblock
|
|
|
|
|
The block containing this block. If this parent block does not exist,
|
|
|
|
|
this attribute holds @code{None}. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2025-02-04 13:56:49 +00:00
|
|
|
@defvar Block.subblocks
|
|
|
|
|
A list of blocks nested in this block. If there are no blocks nested,
|
|
|
|
|
this attribute holds an empty list. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar Block.global_block
|
|
|
|
|
The global block associated with this block. This attribute is not
|
|
|
|
|
writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Block.static_block
|
|
|
|
|
The static block associated with this block. This attribute is not
|
|
|
|
|
writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Block.is_global
|
|
|
|
|
@code{True} if the @code{gdb.Block} object is a global block,
|
|
|
|
|
@code{False} if not. This attribute is not
|
|
|
|
|
writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Block.is_static
|
|
|
|
|
@code{True} if the @code{gdb.Block} object is a static block,
|
|
|
|
|
@code{False} if not. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@node Symbols In Python
|
2018-09-08 14:00:48 -06:00
|
|
|
@subsubsection Python representation of Symbols
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@cindex symbols in python
|
|
|
|
|
@tindex gdb.Symbol
|
|
|
|
|
|
|
|
|
|
@value{GDBN} represents every variable, function and type as an
|
|
|
|
|
entry in a symbol table. @xref{Symbols, ,Examining the Symbol Table}.
|
|
|
|
|
Similarly, Python represents these symbols in @value{GDBN} with the
|
|
|
|
|
@code{gdb.Symbol} object.
|
|
|
|
|
|
|
|
|
|
The following symbol-related functions are available in the @code{gdb}
|
|
|
|
|
module:
|
|
|
|
|
|
|
|
|
|
@defun gdb.lookup_symbol (name @r{[}, block @r{[}, domain@r{]]})
|
|
|
|
|
This function searches for a symbol by name. The search scope can be
|
|
|
|
|
restricted to the parameters defined in the optional domain and block
|
|
|
|
|
arguments.
|
|
|
|
|
|
|
|
|
|
@var{name} is the name of the symbol. It must be a string. The
|
|
|
|
|
optional @var{block} argument restricts the search to symbols visible
|
|
|
|
|
in that @var{block}. The @var{block} argument must be a
|
|
|
|
|
@code{gdb.Block} object. If omitted, the block for the current frame
|
|
|
|
|
is used. The optional @var{domain} argument restricts
|
|
|
|
|
the search to the domain type. The @var{domain} argument must be a
|
|
|
|
|
domain constant defined in the @code{gdb} module and described later
|
|
|
|
|
in this chapter.
|
|
|
|
|
|
|
|
|
|
The result is a tuple of two elements.
|
|
|
|
|
The first element is a @code{gdb.Symbol} object or @code{None} if the symbol
|
|
|
|
|
is not found.
|
|
|
|
|
If the symbol is found, the second element is @code{True} if the symbol
|
|
|
|
|
is a field of a method's object (e.g., @code{this} in C@t{++}),
|
|
|
|
|
otherwise it is @code{False}.
|
|
|
|
|
If the symbol is not found, the second element is @code{False}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun gdb.lookup_global_symbol (name @r{[}, domain@r{]})
|
|
|
|
|
This function searches for a global symbol by name.
|
|
|
|
|
The search scope can be restricted to by the domain argument.
|
|
|
|
|
|
|
|
|
|
@var{name} is the name of the symbol. It must be a string.
|
|
|
|
|
The optional @var{domain} argument restricts the search to the domain type.
|
|
|
|
|
The @var{domain} argument must be a domain constant defined in the @code{gdb}
|
|
|
|
|
module and described later in this chapter.
|
|
|
|
|
|
|
|
|
|
The result is a @code{gdb.Symbol} object or @code{None} if the symbol
|
|
|
|
|
is not found.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2019-07-30 11:04:37 -05:00
|
|
|
@defun gdb.lookup_static_symbol (name @r{[}, domain@r{]})
|
|
|
|
|
This function searches for a global symbol with static linkage by name.
|
|
|
|
|
The search scope can be restricted to by the domain argument.
|
|
|
|
|
|
|
|
|
|
@var{name} is the name of the symbol. It must be a string.
|
|
|
|
|
The optional @var{domain} argument restricts the search to the domain type.
|
|
|
|
|
The @var{domain} argument must be a domain constant defined in the @code{gdb}
|
|
|
|
|
module and described later in this chapter.
|
|
|
|
|
|
|
|
|
|
The result is a @code{gdb.Symbol} object or @code{None} if the symbol
|
|
|
|
|
is not found.
|
|
|
|
|
|
|
|
|
|
Note that this function will not find function-scoped static variables. To look
|
|
|
|
|
up such variables, iterate over the variables of the function's
|
|
|
|
|
@code{gdb.Block} and check that @code{block.addr_class} is
|
|
|
|
|
@code{gdb.SYMBOL_LOC_STATIC}.
|
2019-09-23 16:59:08 +01:00
|
|
|
|
|
|
|
|
There can be multiple global symbols with static linkage with the same
|
|
|
|
|
name. This function will only return the first matching symbol that
|
|
|
|
|
it finds. Which symbol is found depends on where @value{GDBN} is
|
|
|
|
|
currently stopped, as @value{GDBN} will first search for matching
|
|
|
|
|
symbols in the current object file, and then search all other object
|
|
|
|
|
files. If the application is not yet running then @value{GDBN} will
|
|
|
|
|
search all object files in the order they appear in the debug
|
|
|
|
|
information.
|
2019-07-30 11:04:37 -05:00
|
|
|
@end defun
|
|
|
|
|
|
2019-10-15 16:18:26 +01:00
|
|
|
@defun gdb.lookup_static_symbols (name @r{[}, domain@r{]})
|
|
|
|
|
Similar to @code{gdb.lookup_static_symbol}, this function searches for
|
|
|
|
|
global symbols with static linkage by name, and optionally restricted
|
|
|
|
|
by the domain argument. However, this function returns a list of all
|
|
|
|
|
matching symbols found, not just the first one.
|
|
|
|
|
|
|
|
|
|
@var{name} is the name of the symbol. It must be a string.
|
|
|
|
|
The optional @var{domain} argument restricts the search to the domain type.
|
|
|
|
|
The @var{domain} argument must be a domain constant defined in the @code{gdb}
|
|
|
|
|
module and described later in this chapter.
|
|
|
|
|
|
|
|
|
|
The result is a list of @code{gdb.Symbol} objects which could be empty
|
|
|
|
|
if no matching symbols were found.
|
|
|
|
|
|
|
|
|
|
Note that this function will not find function-scoped static variables. To look
|
|
|
|
|
up such variables, iterate over the variables of the function's
|
|
|
|
|
@code{gdb.Block} and check that @code{block.addr_class} is
|
|
|
|
|
@code{gdb.SYMBOL_LOC_STATIC}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
A @code{gdb.Symbol} object has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar Symbol.type
|
|
|
|
|
The type of the symbol or @code{None} if no type is recorded.
|
|
|
|
|
This attribute is represented as a @code{gdb.Type} object.
|
|
|
|
|
@xref{Types In Python}. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symbol.symtab
|
|
|
|
|
The symbol table in which the symbol appears. This attribute is
|
|
|
|
|
represented as a @code{gdb.Symtab} object. @xref{Symbol Tables In
|
|
|
|
|
Python}. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symbol.line
|
|
|
|
|
The line number in the source code at which the symbol was defined.
|
|
|
|
|
This is an integer.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symbol.name
|
|
|
|
|
The name of the symbol as a string. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symbol.linkage_name
|
|
|
|
|
The name of the symbol, as used by the linker (i.e., may be mangled).
|
|
|
|
|
This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symbol.print_name
|
|
|
|
|
The name of the symbol in a form suitable for output. This is either
|
|
|
|
|
@code{name} or @code{linkage_name}, depending on whether the user
|
|
|
|
|
asked @value{GDBN} to display demangled or mangled names.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symbol.addr_class
|
|
|
|
|
The address class of the symbol. This classifies how to find the value
|
|
|
|
|
of a symbol. Each address class is a constant defined in the
|
|
|
|
|
@code{gdb} module and described later in this chapter.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2025-02-04 13:56:49 +00:00
|
|
|
@defvar Symbol.domain
|
|
|
|
|
The domain of the symbol. Each domain is a constant defined in the
|
|
|
|
|
@code{gdb} module and described later in this chapter.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar Symbol.needs_frame
|
|
|
|
|
This is @code{True} if evaluating this symbol's value requires a frame
|
|
|
|
|
(@pxref{Frames In Python}) and @code{False} otherwise. Typically,
|
|
|
|
|
local variables will require a frame, but other symbols will not.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symbol.is_argument
|
|
|
|
|
@code{True} if the symbol is an argument of a function.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2024-11-12 13:07:46 -07:00
|
|
|
@defvar Symbol.is_artificial
|
|
|
|
|
@code{True} if the symbol is artificial. An artificial symbol is one
|
|
|
|
|
that is introduced by the compiler.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar Symbol.is_constant
|
|
|
|
|
@code{True} if the symbol is a constant.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symbol.is_function
|
|
|
|
|
@code{True} if the symbol is a function or a method.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symbol.is_variable
|
2023-10-31 09:16:08 -06:00
|
|
|
@code{True} if the symbol is a variable, as opposed to something like
|
|
|
|
|
a function or type. Note that this also returns @code{False} for
|
|
|
|
|
arguments.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
A @code{gdb.Symbol} object has the following methods:
|
|
|
|
|
|
|
|
|
|
@defun Symbol.is_valid ()
|
|
|
|
|
Returns @code{True} if the @code{gdb.Symbol} object is valid,
|
|
|
|
|
@code{False} if not. A @code{gdb.Symbol} object can become invalid if
|
|
|
|
|
the symbol it refers to does not exist in @value{GDBN} any longer.
|
|
|
|
|
All other @code{gdb.Symbol} methods will throw an exception if it is
|
|
|
|
|
invalid at the time the method is called.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Symbol.value (@r{[}frame@r{]})
|
|
|
|
|
Compute the value of the symbol, as a @code{gdb.Value}. For
|
|
|
|
|
functions, this computes the address of the function, cast to the
|
|
|
|
|
appropriate type. If the symbol requires a frame in order to compute
|
|
|
|
|
its value, then @var{frame} must be given. If @var{frame} is not
|
|
|
|
|
given, or if @var{frame} is invalid, then this method will throw an
|
|
|
|
|
exception.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
The available domain categories in @code{gdb.Symbol} are represented
|
|
|
|
|
as constants in the @code{gdb} module:
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vtable @code
|
|
|
|
|
@vindex SYMBOL_UNDEF_DOMAIN
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_UNDEF_DOMAIN
|
|
|
|
|
This is used when a domain has not been discovered or none of the
|
|
|
|
|
following domains apply. This usually indicates an error either
|
|
|
|
|
in the symbol information or in @value{GDBN}'s handling of symbols.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_VAR_DOMAIN
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_VAR_DOMAIN
|
2023-11-18 10:00:12 -07:00
|
|
|
This domain contains variables.
|
|
|
|
|
|
|
|
|
|
@vindex SYMBOL_FUNCTION_DOMAIN
|
|
|
|
|
@item gdb.SYMBOL_FUNCTION_DOMAIN
|
|
|
|
|
This domain contains functions.
|
|
|
|
|
|
|
|
|
|
@vindex SYMBOL_TYPE_DOMAIN
|
|
|
|
|
@item gdb.SYMBOL_TYPE_DOMAIN
|
|
|
|
|
This domain contains types. In a C-like language, types using a tag
|
|
|
|
|
(the name appearing after a @code{struct}, @code{union}, or
|
|
|
|
|
@code{enum} keyword) will not appear here; in other languages, all
|
|
|
|
|
types are in this domain.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_STRUCT_DOMAIN
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_STRUCT_DOMAIN
|
2023-11-18 10:00:12 -07:00
|
|
|
This domain holds struct, union and enum tag names. This domain is
|
|
|
|
|
only used for C-like languages. For example, in this code:
|
|
|
|
|
@smallexample
|
|
|
|
|
struct type_one @{ int x; @};
|
|
|
|
|
typedef struct type_one type_two;
|
|
|
|
|
@end smallexample
|
|
|
|
|
Here @code{type_one} will be in @code{SYMBOL_STRUCT_DOMAIN}, but
|
|
|
|
|
@code{type_two} will be in @code{SYMBOL_TYPE_DOMAIN}.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LABEL_DOMAIN
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LABEL_DOMAIN
|
|
|
|
|
This domain contains names of labels (for gotos).
|
2014-05-17 09:13:00 -07:00
|
|
|
|
Update symbol domain and location values for Python
In the distant past, there was no distinction between domain_enum and
search_domain. At that point, there were two sets of enumerators in a
single enum -- which is why these were eventually split. This
confusion leaked out to the Python API as well, as noted in
PR python/21765.
This patch deprecates the constants that aren't useful to the Python
API. They are left in place for now, but removed from the
documentation. Also, their values are changed so that, if used, they
might work. Finally, missing domains and location constants are
added.
gdb/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR python/21765:
* python/py-symbol.c (gdbpy_initialize_symbols): Redefine
SYMBOL_VARIABLES_DOMAIN, SYMBOL_FUNCTIONS_DOMAIN,
SYMBOL_TYPES_DOMAIN. Define SYMBOL_MODULE_DOMAIN,
SYMBOL_COMMON_BLOCK_DOMAIN, SYMBOL_LOC_COMMON_BLOCK.
gdb/doc/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR python/21765:
* python.texi (Symbols In Python): Document the module and
common-block domains. Remove documentation for incorrect
domains.
2018-10-06 22:55:19 -06:00
|
|
|
@vindex SYMBOL_MODULE_DOMAIN
|
|
|
|
|
@item gdb.SYMBOL_MODULE_DOMAIN
|
|
|
|
|
This domain contains names of Fortran module types.
|
|
|
|
|
|
|
|
|
|
@vindex SYMBOL_COMMON_BLOCK_DOMAIN
|
|
|
|
|
@item gdb.SYMBOL_COMMON_BLOCK_DOMAIN
|
|
|
|
|
This domain contains names of Fortran common blocks.
|
2014-05-17 09:13:00 -07:00
|
|
|
@end vtable
|
2014-02-17 10:35:03 -08:00
|
|
|
|
2023-11-18 10:00:12 -07:00
|
|
|
When searching for a symbol, the desired domain constant can be passed
|
|
|
|
|
verbatim to the lookup function. For example:
|
|
|
|
|
@smallexample
|
|
|
|
|
symbol = gdb.lookup_symbol ("name", domain=gdb.SYMBOL_VAR_DOMAIN)
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
For more complex searches, there is a corresponding set of constants,
|
|
|
|
|
each named after one of the preceding constants, but with the
|
|
|
|
|
@samp{SEARCH} prefix replacing the @samp{SYMBOL} prefix; for example,
|
|
|
|
|
@code{SEARCH_LABEL_DOMAIN}. These may be or'd together to form a
|
|
|
|
|
search constant, e.g.:
|
|
|
|
|
@smallexample
|
|
|
|
|
symbol = gdb.lookup_symbol ("name",
|
|
|
|
|
domain=gdb.SEARCH_VAR_DOMAIN | gdb.SEARCH_TYPE_DOMAIN)
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
The available address class categories in @code{gdb.Symbol} are represented
|
|
|
|
|
as constants in the @code{gdb} module:
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vtable @code
|
|
|
|
|
@vindex SYMBOL_LOC_UNDEF
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_UNDEF
|
|
|
|
|
If this is returned by address class, it indicates an error either in
|
|
|
|
|
the symbol information or in @value{GDBN}'s handling of symbols.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_CONST
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_CONST
|
|
|
|
|
Value is constant int.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_STATIC
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_STATIC
|
|
|
|
|
Value is at a fixed address.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_REGISTER
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_REGISTER
|
|
|
|
|
Value is in a register.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_ARG
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_ARG
|
|
|
|
|
Value is an argument. This value is at the offset stored within the
|
|
|
|
|
symbol inside the frame's argument list.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_REF_ARG
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_REF_ARG
|
|
|
|
|
Value address is stored in the frame's argument list. Just like
|
|
|
|
|
@code{LOC_ARG} except that the value's address is stored at the
|
|
|
|
|
offset, not the value itself.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_REGPARM_ADDR
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_REGPARM_ADDR
|
|
|
|
|
Value is a specified register. Just like @code{LOC_REGISTER} except
|
|
|
|
|
the register holds the address of the argument instead of the argument
|
|
|
|
|
itself.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_LOCAL
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_LOCAL
|
|
|
|
|
Value is a local variable.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_TYPEDEF
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_TYPEDEF
|
|
|
|
|
Value not used. Symbols in the domain @code{SYMBOL_STRUCT_DOMAIN} all
|
|
|
|
|
have this class.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
2021-05-26 18:22:36 +02:00
|
|
|
@vindex SYMBOL_LOC_LABEL
|
|
|
|
|
@item gdb.SYMBOL_LOC_LABEL
|
|
|
|
|
Value is a label.
|
|
|
|
|
|
2014-05-17 09:13:00 -07:00
|
|
|
@vindex SYMBOL_LOC_BLOCK
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_BLOCK
|
|
|
|
|
Value is a block.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_CONST_BYTES
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_CONST_BYTES
|
|
|
|
|
Value is a byte-sequence.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_UNRESOLVED
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_UNRESOLVED
|
|
|
|
|
Value is at a fixed address, but the address of the variable has to be
|
|
|
|
|
determined from the minimal symbol table whenever the variable is
|
|
|
|
|
referenced.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_OPTIMIZED_OUT
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_OPTIMIZED_OUT
|
|
|
|
|
The value does not actually exist in the program.
|
2014-05-17 09:13:00 -07:00
|
|
|
|
|
|
|
|
@vindex SYMBOL_LOC_COMPUTED
|
2014-02-17 10:35:03 -08:00
|
|
|
@item gdb.SYMBOL_LOC_COMPUTED
|
|
|
|
|
The value's address is a computed location.
|
Update symbol domain and location values for Python
In the distant past, there was no distinction between domain_enum and
search_domain. At that point, there were two sets of enumerators in a
single enum -- which is why these were eventually split. This
confusion leaked out to the Python API as well, as noted in
PR python/21765.
This patch deprecates the constants that aren't useful to the Python
API. They are left in place for now, but removed from the
documentation. Also, their values are changed so that, if used, they
might work. Finally, missing domains and location constants are
added.
gdb/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR python/21765:
* python/py-symbol.c (gdbpy_initialize_symbols): Redefine
SYMBOL_VARIABLES_DOMAIN, SYMBOL_FUNCTIONS_DOMAIN,
SYMBOL_TYPES_DOMAIN. Define SYMBOL_MODULE_DOMAIN,
SYMBOL_COMMON_BLOCK_DOMAIN, SYMBOL_LOC_COMMON_BLOCK.
gdb/doc/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR python/21765:
* python.texi (Symbols In Python): Document the module and
common-block domains. Remove documentation for incorrect
domains.
2018-10-06 22:55:19 -06:00
|
|
|
|
2021-05-25 17:27:23 +02:00
|
|
|
@vindex SYMBOL_LOC_COMMON_BLOCK
|
|
|
|
|
@item gdb.SYMBOL_LOC_COMMON_BLOCK
|
Update symbol domain and location values for Python
In the distant past, there was no distinction between domain_enum and
search_domain. At that point, there were two sets of enumerators in a
single enum -- which is why these were eventually split. This
confusion leaked out to the Python API as well, as noted in
PR python/21765.
This patch deprecates the constants that aren't useful to the Python
API. They are left in place for now, but removed from the
documentation. Also, their values are changed so that, if used, they
might work. Finally, missing domains and location constants are
added.
gdb/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR python/21765:
* python/py-symbol.c (gdbpy_initialize_symbols): Redefine
SYMBOL_VARIABLES_DOMAIN, SYMBOL_FUNCTIONS_DOMAIN,
SYMBOL_TYPES_DOMAIN. Define SYMBOL_MODULE_DOMAIN,
SYMBOL_COMMON_BLOCK_DOMAIN, SYMBOL_LOC_COMMON_BLOCK.
gdb/doc/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR python/21765:
* python.texi (Symbols In Python): Document the module and
common-block domains. Remove documentation for incorrect
domains.
2018-10-06 22:55:19 -06:00
|
|
|
The value's address is a symbol. This is only used for Fortran common
|
|
|
|
|
blocks.
|
2014-05-17 09:13:00 -07:00
|
|
|
@end vtable
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@node Symbol Tables In Python
|
2018-09-08 14:00:48 -06:00
|
|
|
@subsubsection Symbol table representation in Python
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@cindex symbol tables in python
|
|
|
|
|
@tindex gdb.Symtab
|
|
|
|
|
@tindex gdb.Symtab_and_line
|
|
|
|
|
|
|
|
|
|
Access to symbol table data maintained by @value{GDBN} on the inferior
|
|
|
|
|
is exposed to Python via two objects: @code{gdb.Symtab_and_line} and
|
|
|
|
|
@code{gdb.Symtab}. Symbol table and line data for a frame is returned
|
|
|
|
|
from the @code{find_sal} method in @code{gdb.Frame} object.
|
|
|
|
|
@xref{Frames In Python}.
|
|
|
|
|
|
|
|
|
|
For more information on @value{GDBN}'s symbol table management, see
|
|
|
|
|
@ref{Symbols, ,Examining the Symbol Table}, for more information.
|
|
|
|
|
|
|
|
|
|
A @code{gdb.Symtab_and_line} object has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar Symtab_and_line.symtab
|
|
|
|
|
The symbol table object (@code{gdb.Symtab}) for this frame.
|
|
|
|
|
This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symtab_and_line.pc
|
|
|
|
|
Indicates the start of the address range occupied by code for the
|
|
|
|
|
current source line. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symtab_and_line.last
|
|
|
|
|
Indicates the end of the address range occupied by code for the current
|
|
|
|
|
source line. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symtab_and_line.line
|
|
|
|
|
Indicates the current line number for this object. This
|
|
|
|
|
attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
A @code{gdb.Symtab_and_line} object has the following methods:
|
|
|
|
|
|
|
|
|
|
@defun Symtab_and_line.is_valid ()
|
|
|
|
|
Returns @code{True} if the @code{gdb.Symtab_and_line} object is valid,
|
|
|
|
|
@code{False} if not. A @code{gdb.Symtab_and_line} object can become
|
|
|
|
|
invalid if the Symbol table and line object it refers to does not
|
|
|
|
|
exist in @value{GDBN} any longer. All other
|
|
|
|
|
@code{gdb.Symtab_and_line} methods will throw an exception if it is
|
|
|
|
|
invalid at the time the method is called.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
A @code{gdb.Symtab} object has the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar Symtab.filename
|
|
|
|
|
The symbol table's source filename. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Symtab.objfile
|
|
|
|
|
The symbol table's backing object file. @xref{Objfiles In Python}.
|
|
|
|
|
This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-09-18 10:09:12 -07:00
|
|
|
@defvar Symtab.producer
|
|
|
|
|
The name and possibly version number of the program that
|
|
|
|
|
compiled the code in the symbol table.
|
|
|
|
|
The contents of this string is up to the compiler.
|
|
|
|
|
If no producer information is available then @code{None} is returned.
|
|
|
|
|
This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
A @code{gdb.Symtab} object has the following methods:
|
|
|
|
|
|
|
|
|
|
@defun Symtab.is_valid ()
|
|
|
|
|
Returns @code{True} if the @code{gdb.Symtab} object is valid,
|
|
|
|
|
@code{False} if not. A @code{gdb.Symtab} object can become invalid if
|
|
|
|
|
the symbol table it refers to does not exist in @value{GDBN} any
|
|
|
|
|
longer. All other @code{gdb.Symtab} methods will throw an exception
|
|
|
|
|
if it is invalid at the time the method is called.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Symtab.fullname ()
|
|
|
|
|
Return the symbol table's source absolute file name.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Symtab.global_block ()
|
|
|
|
|
Return the global block of the underlying symbol table.
|
|
|
|
|
@xref{Blocks In Python}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Symtab.static_block ()
|
|
|
|
|
Return the static block of the underlying symbol table.
|
|
|
|
|
@xref{Blocks In Python}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Symtab.linetable ()
|
|
|
|
|
Return the line table associated with the symbol table.
|
|
|
|
|
@xref{Line Tables In Python}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@node Line Tables In Python
|
|
|
|
|
@subsubsection Manipulating line tables using Python
|
|
|
|
|
|
|
|
|
|
@cindex line tables in python
|
|
|
|
|
@tindex gdb.LineTable
|
|
|
|
|
|
|
|
|
|
Python code can request and inspect line table information from a
|
|
|
|
|
symbol table that is loaded in @value{GDBN}. A line table is a
|
|
|
|
|
mapping of source lines to their executable locations in memory. To
|
|
|
|
|
acquire the line table information for a particular symbol table, use
|
|
|
|
|
the @code{linetable} function (@pxref{Symbol Tables In Python}).
|
|
|
|
|
|
|
|
|
|
A @code{gdb.LineTable} is iterable. The iterator returns
|
|
|
|
|
@code{LineTableEntry} objects that correspond to the source line and
|
|
|
|
|
address for each line table entry. @code{LineTableEntry} objects have
|
|
|
|
|
the following attributes:
|
|
|
|
|
|
|
|
|
|
@defvar LineTableEntry.line
|
|
|
|
|
The source line number for this line table entry. This number
|
|
|
|
|
corresponds to the actual line of source. This attribute is not
|
|
|
|
|
writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar LineTableEntry.pc
|
|
|
|
|
The address that is associated with the line table entry where the
|
|
|
|
|
executable code for that source line resides in memory. This
|
|
|
|
|
attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
As there can be multiple addresses for a single source line, you may
|
|
|
|
|
receive multiple @code{LineTableEntry} objects with matching
|
|
|
|
|
@code{line} attributes, but with different @code{pc} attributes. The
|
|
|
|
|
iterator is sorted in ascending @code{pc} order. Here is a small
|
|
|
|
|
example illustrating iterating over a line table.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
symtab = gdb.selected_frame().find_sal().symtab
|
|
|
|
|
linetable = symtab.linetable()
|
|
|
|
|
for line in linetable:
|
2021-01-25 10:28:53 -05:00
|
|
|
print ("Line: "+str(line.line)+" Address: "+hex(line.pc))
|
2014-02-17 10:35:03 -08:00
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
This will have the following output:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
Line: 33 Address: 0x4005c8L
|
|
|
|
|
Line: 37 Address: 0x4005caL
|
|
|
|
|
Line: 39 Address: 0x4005d2L
|
|
|
|
|
Line: 40 Address: 0x4005f8L
|
|
|
|
|
Line: 42 Address: 0x4005ffL
|
|
|
|
|
Line: 44 Address: 0x400608L
|
|
|
|
|
Line: 42 Address: 0x40060cL
|
|
|
|
|
Line: 45 Address: 0x400615L
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
In addition to being able to iterate over a @code{LineTable}, it also
|
|
|
|
|
has the following direct access methods:
|
|
|
|
|
|
|
|
|
|
@defun LineTable.line (line)
|
|
|
|
|
Return a Python @code{Tuple} of @code{LineTableEntry} objects for any
|
Don't use @var at the beginning of a sentence in GDB documentation.
gdb/doc/guile.texi (Types In Guile, Basic Guile, Frames In Guile)
(Breakpoints In Guile, Guile Printing Module)
(Guile Exception Handling, Values From Inferior In Guile)
(Objfiles In Guile, Breakpoints In Guile, Memory Ports in Guile):
Don't use @var at the beginning of a sentence.
gdb/doc/gdb.texinfo (Frame Filter Management, Trace Files)
(C Operators, Ada Tasks, Calling, Bootstrapping, ARM)
(PowerPC Embedded, Define, Annotations for Running)
(IPA Protocol Commands, Packets, General Query Packets)
(Tracepoint Packets, Notification Packets, Environment)
(Inferiors and Programs, Set Breaks, Set Catchpoints)
(Continuing and Stepping, Signals, Thread-Specific Breakpoints)
(Frames, Backtrace, Selection, Expressions, Registers)
(Trace State Variables, Built-In Func/Proc, Signaling, Files)
(Numbers, GDB/MI Async Records, GDB/MI Data Manipulation)
(Source Annotations, Using JIT Debug Info Readers, Packets)
(Stop Reply Packets, Host I/O Packets)
(Target Description Format): Don't use @var at the beginning of a
sentence.
gdb/doc/python.texi (Basic Python, Types In Python)
(Commands In Python, Frames In Python, Line Tables In Python)
(Breakpoints In Python, gdb.printing, gdb.types)
(Type Printing API): Don't use @var at the beginning of a
sentence.
2014-05-24 13:02:42 +03:00
|
|
|
entries in the line table for the given @var{line}, which specifies
|
|
|
|
|
the source code line. If there are no entries for that source code
|
2014-02-17 10:35:03 -08:00
|
|
|
@var{line}, the Python @code{None} is returned.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun LineTable.has_line (line)
|
|
|
|
|
Return a Python @code{Boolean} indicating whether there is an entry in
|
|
|
|
|
the line table for this source line. Return @code{True} if an entry
|
|
|
|
|
is found, or @code{False} if not.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun LineTable.source_lines ()
|
|
|
|
|
Return a Python @code{List} of the source line numbers in the symbol
|
|
|
|
|
table. Only lines with executable code locations are returned. The
|
|
|
|
|
contents of the @code{List} will just be the source line entries
|
|
|
|
|
represented as Python @code{Long} values.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@node Breakpoints In Python
|
|
|
|
|
@subsubsection Manipulating breakpoints using Python
|
|
|
|
|
|
|
|
|
|
@cindex breakpoints in python
|
|
|
|
|
@tindex gdb.Breakpoint
|
|
|
|
|
|
|
|
|
|
Python code can manipulate breakpoints via the @code{gdb.Breakpoint}
|
|
|
|
|
class.
|
|
|
|
|
|
2017-12-13 11:26:51 -05:00
|
|
|
A breakpoint can be created using one of the two forms of the
|
|
|
|
|
@code{gdb.Breakpoint} constructor. The first one accepts a string
|
|
|
|
|
like one would pass to the @code{break}
|
|
|
|
|
(@pxref{Set Breaks,,Setting Breakpoints}) and @code{watch}
|
|
|
|
|
(@pxref{Set Watchpoints, , Setting Watchpoints}) commands, and can be used to
|
|
|
|
|
create both breakpoints and watchpoints. The second accepts separate Python
|
|
|
|
|
arguments similar to @ref{Explicit Locations}, and can only be used to create
|
|
|
|
|
breakpoints.
|
|
|
|
|
|
2017-12-13 11:37:09 -05:00
|
|
|
@defun Breakpoint.__init__ (spec @r{[}, type @r{][}, wp_class @r{][}, internal @r{][}, temporary @r{][}, qualified @r{]})
|
2017-12-13 11:26:51 -05:00
|
|
|
Create a new breakpoint according to @var{spec}, which is a string naming the
|
|
|
|
|
location of a breakpoint, or an expression that defines a watchpoint. The
|
|
|
|
|
string should describe a location in a format recognized by the @code{break}
|
|
|
|
|
command (@pxref{Set Breaks,,Setting Breakpoints}) or, in the case of a
|
|
|
|
|
watchpoint, by the @code{watch} command
|
|
|
|
|
(@pxref{Set Watchpoints, , Setting Watchpoints}).
|
|
|
|
|
|
|
|
|
|
The optional @var{type} argument specifies the type of the breakpoint to create,
|
|
|
|
|
as defined below.
|
|
|
|
|
|
|
|
|
|
The optional @var{wp_class} argument defines the class of watchpoint to create,
|
|
|
|
|
if @var{type} is @code{gdb.BP_WATCHPOINT}. If @var{wp_class} is omitted, it
|
|
|
|
|
defaults to @code{gdb.WP_WRITE}.
|
|
|
|
|
|
|
|
|
|
The optional @var{internal} argument allows the breakpoint to become invisible
|
|
|
|
|
to the user. The breakpoint will neither be reported when created, nor will it
|
|
|
|
|
be listed in the output from @code{info breakpoints} (but will be listed with
|
|
|
|
|
the @code{maint info breakpoints} command).
|
|
|
|
|
|
|
|
|
|
The optional @var{temporary} argument makes the breakpoint a temporary
|
|
|
|
|
breakpoint. Temporary breakpoints are deleted after they have been hit. Any
|
|
|
|
|
further access to the Python breakpoint after it has been hit will result in a
|
|
|
|
|
runtime error (as that breakpoint has now been automatically deleted).
|
2017-12-13 11:37:09 -05:00
|
|
|
|
|
|
|
|
The optional @var{qualified} argument is a boolean that allows interpreting
|
|
|
|
|
the function passed in @code{spec} as a fully-qualified name. It is equivalent
|
|
|
|
|
to @code{break}'s @code{-qualified} flag (@pxref{Linespec Locations} and
|
|
|
|
|
@ref{Explicit Locations}).
|
|
|
|
|
|
2017-12-13 11:26:51 -05:00
|
|
|
@end defun
|
|
|
|
|
|
2017-12-13 11:37:09 -05:00
|
|
|
@defun Breakpoint.__init__ (@r{[} source @r{][}, function @r{][}, label @r{][}, line @r{]}, @r{][} internal @r{][}, temporary @r{][}, qualified @r{]})
|
2017-12-13 11:26:51 -05:00
|
|
|
This second form of creating a new breakpoint specifies the explicit
|
|
|
|
|
location (@pxref{Explicit Locations}) using keywords. The new breakpoint will
|
|
|
|
|
be created in the specified source file @var{source}, at the specified
|
|
|
|
|
@var{function}, @var{label} and @var{line}.
|
|
|
|
|
|
2017-12-13 11:37:09 -05:00
|
|
|
@var{internal}, @var{temporary} and @var{qualified} have the same usage as
|
|
|
|
|
explained previously.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defun
|
|
|
|
|
|
2016-05-19 15:40:54 -06:00
|
|
|
The available types are represented by constants defined in the @code{gdb}
|
|
|
|
|
module:
|
|
|
|
|
|
|
|
|
|
@vtable @code
|
|
|
|
|
@vindex BP_BREAKPOINT
|
|
|
|
|
@item gdb.BP_BREAKPOINT
|
|
|
|
|
Normal code breakpoint.
|
|
|
|
|
|
2021-01-02 13:51:27 +01:00
|
|
|
@vindex BP_HARDWARE_BREAKPOINT
|
|
|
|
|
@item gdb.BP_HARDWARE_BREAKPOINT
|
|
|
|
|
Hardware assisted code breakpoint.
|
|
|
|
|
|
2016-05-19 15:40:54 -06:00
|
|
|
@vindex BP_WATCHPOINT
|
|
|
|
|
@item gdb.BP_WATCHPOINT
|
|
|
|
|
Watchpoint breakpoint.
|
|
|
|
|
|
|
|
|
|
@vindex BP_HARDWARE_WATCHPOINT
|
|
|
|
|
@item gdb.BP_HARDWARE_WATCHPOINT
|
|
|
|
|
Hardware assisted watchpoint.
|
|
|
|
|
|
|
|
|
|
@vindex BP_READ_WATCHPOINT
|
|
|
|
|
@item gdb.BP_READ_WATCHPOINT
|
|
|
|
|
Hardware assisted read watchpoint.
|
|
|
|
|
|
|
|
|
|
@vindex BP_ACCESS_WATCHPOINT
|
|
|
|
|
@item gdb.BP_ACCESS_WATCHPOINT
|
|
|
|
|
Hardware assisted access watchpoint.
|
2021-05-05 15:26:28 +01:00
|
|
|
|
|
|
|
|
@vindex BP_CATCHPOINT
|
|
|
|
|
@item gdb.BP_CATCHPOINT
|
|
|
|
|
Catchpoint. Currently, this type can't be used when creating
|
|
|
|
|
@code{gdb.Breakpoint} objects, but will be present in
|
|
|
|
|
@code{gdb.Breakpoint} objects reported from
|
|
|
|
|
@code{gdb.BreakpointEvent}s (@pxref{Events In Python}).
|
2016-05-19 15:40:54 -06:00
|
|
|
@end vtable
|
|
|
|
|
|
2021-05-09 17:26:53 +01:00
|
|
|
The available watchpoint types are represented by constants defined in the
|
2016-05-19 15:40:54 -06:00
|
|
|
@code{gdb} module:
|
|
|
|
|
|
|
|
|
|
@vtable @code
|
|
|
|
|
@vindex WP_READ
|
|
|
|
|
@item gdb.WP_READ
|
|
|
|
|
Read only watchpoint.
|
|
|
|
|
|
|
|
|
|
@vindex WP_WRITE
|
|
|
|
|
@item gdb.WP_WRITE
|
|
|
|
|
Write only watchpoint.
|
|
|
|
|
|
|
|
|
|
@vindex WP_ACCESS
|
|
|
|
|
@item gdb.WP_ACCESS
|
|
|
|
|
Read/Write watchpoint.
|
|
|
|
|
@end vtable
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun Breakpoint.stop (self)
|
|
|
|
|
The @code{gdb.Breakpoint} class can be sub-classed and, in
|
|
|
|
|
particular, you may choose to implement the @code{stop} method.
|
|
|
|
|
If this method is defined in a sub-class of @code{gdb.Breakpoint},
|
|
|
|
|
it will be called when the inferior reaches any location of a
|
|
|
|
|
breakpoint which instantiates that sub-class. If the method returns
|
|
|
|
|
@code{True}, the inferior will be stopped at the location of the
|
|
|
|
|
breakpoint, otherwise the inferior will continue.
|
|
|
|
|
|
|
|
|
|
If there are multiple breakpoints at the same location with a
|
|
|
|
|
@code{stop} method, each one will be called regardless of the
|
|
|
|
|
return status of the previous. This ensures that all @code{stop}
|
|
|
|
|
methods have a chance to execute at that location. In this scenario
|
|
|
|
|
if one of the methods returns @code{True} but the others return
|
|
|
|
|
@code{False}, the inferior will still be stopped.
|
|
|
|
|
|
|
|
|
|
You should not alter the execution state of the inferior (i.e.@:, step,
|
|
|
|
|
next, etc.), alter the current frame context (i.e.@:, change the current
|
|
|
|
|
active frame), or alter, add or delete any breakpoint. As a general
|
|
|
|
|
rule, you should not alter any data within @value{GDBN} or the inferior
|
|
|
|
|
at this time.
|
|
|
|
|
|
|
|
|
|
Example @code{stop} implementation:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class MyBreakpoint (gdb.Breakpoint):
|
|
|
|
|
def stop (self):
|
|
|
|
|
inf_val = gdb.parse_and_eval("foo")
|
|
|
|
|
if inf_val == 3:
|
|
|
|
|
return True
|
|
|
|
|
return False
|
|
|
|
|
@end smallexample
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Breakpoint.is_valid ()
|
|
|
|
|
Return @code{True} if this @code{Breakpoint} object is valid,
|
|
|
|
|
@code{False} otherwise. A @code{Breakpoint} object can become invalid
|
|
|
|
|
if the user deletes the breakpoint. In this case, the object still
|
|
|
|
|
exists, but the underlying breakpoint does not. In the cases of
|
|
|
|
|
watchpoint scope, the watchpoint remains valid even if execution of the
|
|
|
|
|
inferior leaves the scope of that watchpoint.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2014-10-20 13:29:36 -04:00
|
|
|
@defun Breakpoint.delete ()
|
2014-02-17 10:35:03 -08:00
|
|
|
Permanently deletes the @value{GDBN} breakpoint. This also
|
|
|
|
|
invalidates the Python @code{Breakpoint} object. Any further access
|
|
|
|
|
to this object's attributes or methods will raise an error.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.enabled
|
|
|
|
|
This attribute is @code{True} if the breakpoint is enabled, and
|
2014-10-20 13:29:36 -04:00
|
|
|
@code{False} otherwise. This attribute is writable. You can use it to enable
|
|
|
|
|
or disable the breakpoint.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.silent
|
|
|
|
|
This attribute is @code{True} if the breakpoint is silent, and
|
|
|
|
|
@code{False} otherwise. This attribute is writable.
|
|
|
|
|
|
|
|
|
|
Note that a breakpoint can also be silent if it has commands and the
|
|
|
|
|
first command is @code{silent}. This is not reported by the
|
|
|
|
|
@code{silent} attribute.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2016-05-19 15:51:00 -06:00
|
|
|
@defvar Breakpoint.pending
|
|
|
|
|
This attribute is @code{True} if the breakpoint is pending, and
|
|
|
|
|
@code{False} otherwise. @xref{Set Breaks}. This attribute is
|
|
|
|
|
read-only.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2016-01-13 10:56:08 +00:00
|
|
|
@anchor{python_breakpoint_thread}
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar Breakpoint.thread
|
gdb: add inferior-specific breakpoints
This commit extends the breakpoint mechanism to allow for inferior
specific breakpoints (but not watchpoints in this commit).
As GDB gains better support for multiple connections, and so for
running multiple (possibly unrelated) inferiors, then it is not hard
to imagine that a user might wish to create breakpoints that apply to
any thread in a single inferior. To achieve this currently, the user
would need to create a condition possibly making use of the $_inferior
convenience variable, which, though functional, isn't the most user
friendly.
This commit adds a new 'inferior' keyword that allows for the creation
of inferior specific breakpoints.
Inferior specific breakpoints are automatically deleted when the
associated inferior is removed from GDB, this is similar to how
thread-specific breakpoints are deleted when the associated thread is
deleted.
Watchpoints are already per-program-space, which in most cases mean
watchpoints are already inferior specific. There is a small window
where inferior-specific watchpoints might make sense, which is after a
vfork, when two processes are sharing the same address space.
However, I'm leaving that as an exercise for another day. For now,
attempting to use the inferior keyword with a watchpoint will give an
error, like this:
(gdb) watch a8 inferior 1
Cannot use 'inferior' keyword with watchpoints
A final note on the implementation: currently, inferior specific
breakpoints, like thread-specific breakpoints, are inserted into every
inferior, GDB then checks once the inferior stops if we are in the
correct thread or inferior, and resumes automatically if we stopped in
the wrong thread/inferior.
An obvious optimisation here is to only insert breakpoint locations
into the specific program space (which mostly means inferior) that
contains either the inferior or thread we are interested in. This
would reduce the number times GDB has to stop and then resume again in
a multi-inferior setup.
I have a series on the mailing list[1] that implements this
optimisation for thread-specific breakpoints. Once this series has
landed I'll update that series to also handle inferior specific
breakpoints in the same way. For now, inferior specific breakpoints
are just slightly less optimal, but this is no different to
thread-specific breakpoints in a multi-inferior debug session, so I
don't see this as a huge problem.
[1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/
2022-11-08 12:32:51 +00:00
|
|
|
If the breakpoint is thread-specific (@pxref{Thread-Specific
|
|
|
|
|
Breakpoints}), this attribute holds the thread's global id. If the
|
|
|
|
|
breakpoint is not thread-specific, this attribute is @code{None}.
|
|
|
|
|
This attribute is writable.
|
|
|
|
|
|
|
|
|
|
Only one of @code{Breakpoint.thread} or @code{Breakpoint.inferior} can
|
|
|
|
|
be set to a valid id at any time, that is, a breakpoint can be thread
|
|
|
|
|
specific, or inferior specific, but not both.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@anchor{python_breakpoint_inferior}
|
|
|
|
|
@defvar Breakpoint.inferior
|
|
|
|
|
If the breakpoint is inferior-specific (@pxref{Inferior-Specific
|
|
|
|
|
Breakpoints}), this attribute holds the inferior's id. If the
|
|
|
|
|
breakpoint is not inferior-specific, this attribute is @code{None}.
|
|
|
|
|
|
|
|
|
|
This attribute can be written for breakpoints of type
|
|
|
|
|
@code{gdb.BP_BREAKPOINT} and @code{gdb.BP_HARDWARE_BREAKPOINT}.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.task
|
|
|
|
|
If the breakpoint is Ada task-specific, this attribute holds the Ada task
|
|
|
|
|
id. If the breakpoint is not task-specific (or the underlying
|
|
|
|
|
language is not Ada), this attribute is @code{None}. This attribute
|
|
|
|
|
is writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.ignore_count
|
|
|
|
|
This attribute holds the ignore count for the breakpoint, an integer.
|
|
|
|
|
This attribute is writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.number
|
|
|
|
|
This attribute holds the breakpoint's number --- the identifier used by
|
|
|
|
|
the user to manipulate the breakpoint. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.type
|
|
|
|
|
This attribute holds the breakpoint's type --- the identifier used to
|
|
|
|
|
determine the actual breakpoint type or use-case. This attribute is not
|
|
|
|
|
writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.visible
|
|
|
|
|
This attribute tells whether the breakpoint is visible to the user
|
|
|
|
|
when set, or when the @samp{info breakpoints} command is run. This
|
|
|
|
|
attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.temporary
|
|
|
|
|
This attribute indicates whether the breakpoint was created as a
|
|
|
|
|
temporary breakpoint. Temporary breakpoints are automatically deleted
|
|
|
|
|
after that breakpoint has been hit. Access to this attribute, and all
|
|
|
|
|
other attributes and functions other than the @code{is_valid}
|
|
|
|
|
function, will result in an error after the breakpoint has been hit
|
|
|
|
|
(as it has been automatically deleted). This attribute is not
|
|
|
|
|
writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.hit_count
|
|
|
|
|
This attribute holds the hit count for the breakpoint, an integer.
|
|
|
|
|
This attribute is writable, but currently it can only be set to zero.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.location
|
|
|
|
|
This attribute holds the location of the breakpoint, as specified by
|
|
|
|
|
the user. It is a string. If the breakpoint does not have a location
|
|
|
|
|
(that is, it is a watchpoint) the attribute's value is @code{None}. This
|
|
|
|
|
attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/python: Add BreakpointLocation type
PR python/18385
v7:
This version addresses the issues pointed out by Tom.
Added nullchecks for Python object creations.
Changed from using PyLong_FromLong to the gdb_py-versions.
Re-factored some code to make it look more cohesive.
Also added the more safe Python reference count decrement PY_XDECREF,
even though the BreakpointLocation type is never instantiated by the
user (explicitly documented in the docs) decrementing < 0 is made
impossible with the safe call.
Tom pointed out that using the policy class explicitly to decrement a
reference counted object was not the way to go, so this has instead been
wrapped in a ref_ptr that handles that for us in blocpy_dealloc.
Moved macro from py-internal to py-breakpoint.c.
Renamed section at the bottom of commit message "Patch Description".
v6:
This version addresses the points Pedro gave in review to this patch.
Added the attributes `function`, `fullname` and `thread_groups`
as per request by Pedro with the argument that it more resembles the
output of the MI-command "-break-list". Added documentation for these attributes.
Cleaned up left overs from copy+paste in test suite, removed hard coding
of line numbers where possible.
Refactored some code to use more c++-y style range for loops
wrt to breakpoint locations.
Changed terminology, naming was very inconsistent. Used a variety of "parent",
"owner". Now "owner" is the only term used, and the field in the
gdb_breakpoint_location_object now also called "owner".
v5:
Changes in response to review by Tom Tromey:
- Replaced manual INCREF/DECREF calls with
gdbpy_ref ptrs in places where possible.
- Fixed non-gdb style conforming formatting
- Get parent of bploc increases ref count of parent.
- moved bploc Python definition to py-breakpoint.c
The INCREF of self in bppy_get_locations is due
to the individual locations holding a reference to
it's owner. This is decremented at de-alloc time.
The reason why this needs to be here is, if the user writes
for instance;
py loc = gdb.breakpoints()[X].locations[Y]
The breakpoint owner object is immediately going
out of scope (GC'd/dealloced), and the location
object requires it to be alive for as long as it is alive.
Thanks for your review, Tom!
v4:
Fixed remaining doc issues as per request
by Eli.
v3:
Rewritten commit message, shortened + reworded,
added tests.
Patch Description
Currently, the Python API lacks the ability to
query breakpoints for their installed locations,
and subsequently, can't query any information about them, or
enable/disable individual locations.
This patch solves this by adding Python type gdb.BreakpointLocation.
The type is never instantiated by the user of the Python API directly,
but is produced by the gdb.Breakpoint.locations attribute returning
a list of gdb.BreakpointLocation.
gdb.Breakpoint.locations:
The attribute for retrieving the currently installed breakpoint
locations for gdb.Breakpoint. Matches behavior of
the "info breakpoints" command in that it only
returns the last known or currently inserted breakpoint locations.
BreakpointLocation contains 7 attributes
6 read-only attributes:
owner: location owner's Python companion object
source: file path and line number tuple: (string, long) / None
address: installed address of the location
function: function name where location was set
fullname: fullname where location was set
thread_groups: thread groups (inferiors) where location was set.
1 writeable attribute:
enabled: get/set enable/disable this location (bool)
Access/calls to these, can all throw Python exceptions (documented in
the online documentation), and that's due to the nature
of how breakpoint locations can be invalidated
"behind the scenes", either by them being removed
from the original breakpoint or changed,
like for instance when a new symbol file is loaded, at
which point all breakpoint locations are re-created by GDB.
Therefore this patch has chosen to be non-intrusive:
it's up to the Python user to re-request the locations if
they become invalid.
Also there's event handlers that handle new object files etc, if a Python
user is storing breakpoint locations in some larger state they've
built up, refreshing the locations is easy and it only comes
with runtime overhead when the Python user wants to use them.
gdb.BreakpointLocation Python type
struct "gdbpy_breakpoint_location_object" is found in python-internal.h
Its definition, layout, methods and functions
are found in the same file as gdb.Breakpoint (py-breakpoint.c)
1 change was also made to breakpoint.h/c to make it possible
to enable and disable a bp_location* specifically,
without having its LOC_NUM, as this number
also can change arbitrarily behind the scenes.
Updated docs & news file as per request.
Testsuite: tests the .source attribute and the disabling of
individual locations.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385
Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0
2022-06-07 13:57:48 +02:00
|
|
|
@defvar Breakpoint.locations
|
|
|
|
|
Get the most current list of breakpoint locations that are inserted for this
|
|
|
|
|
breakpoint, with elements of type @code{gdb.BreakpointLocation}
|
|
|
|
|
(described below). This functionality matches that of the
|
|
|
|
|
@code{info breakpoint} command (@pxref{Set Breaks}), in that it only retrieves
|
|
|
|
|
the most current list of locations, thus the list itself when returned is
|
|
|
|
|
not updated behind the scenes. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@defvar Breakpoint.expression
|
|
|
|
|
This attribute holds a breakpoint expression, as specified by
|
|
|
|
|
the user. It is a string. If the breakpoint does not have an
|
|
|
|
|
expression (the breakpoint is not a watchpoint) the attribute's value
|
|
|
|
|
is @code{None}. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.condition
|
|
|
|
|
This attribute holds the condition of the breakpoint, as specified by
|
|
|
|
|
the user. It is a string. If there is no condition, this attribute's
|
|
|
|
|
value is @code{None}. This attribute is writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Breakpoint.commands
|
|
|
|
|
This attribute holds the commands attached to the breakpoint. If
|
|
|
|
|
there are commands, this attribute's value is a string holding all the
|
|
|
|
|
commands, separated by newlines. If there are no commands, this
|
2018-04-18 17:37:56 -06:00
|
|
|
attribute is @code{None}. This attribute is writable.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end defvar
|
|
|
|
|
|
gdb/python: Add BreakpointLocation type
PR python/18385
v7:
This version addresses the issues pointed out by Tom.
Added nullchecks for Python object creations.
Changed from using PyLong_FromLong to the gdb_py-versions.
Re-factored some code to make it look more cohesive.
Also added the more safe Python reference count decrement PY_XDECREF,
even though the BreakpointLocation type is never instantiated by the
user (explicitly documented in the docs) decrementing < 0 is made
impossible with the safe call.
Tom pointed out that using the policy class explicitly to decrement a
reference counted object was not the way to go, so this has instead been
wrapped in a ref_ptr that handles that for us in blocpy_dealloc.
Moved macro from py-internal to py-breakpoint.c.
Renamed section at the bottom of commit message "Patch Description".
v6:
This version addresses the points Pedro gave in review to this patch.
Added the attributes `function`, `fullname` and `thread_groups`
as per request by Pedro with the argument that it more resembles the
output of the MI-command "-break-list". Added documentation for these attributes.
Cleaned up left overs from copy+paste in test suite, removed hard coding
of line numbers where possible.
Refactored some code to use more c++-y style range for loops
wrt to breakpoint locations.
Changed terminology, naming was very inconsistent. Used a variety of "parent",
"owner". Now "owner" is the only term used, and the field in the
gdb_breakpoint_location_object now also called "owner".
v5:
Changes in response to review by Tom Tromey:
- Replaced manual INCREF/DECREF calls with
gdbpy_ref ptrs in places where possible.
- Fixed non-gdb style conforming formatting
- Get parent of bploc increases ref count of parent.
- moved bploc Python definition to py-breakpoint.c
The INCREF of self in bppy_get_locations is due
to the individual locations holding a reference to
it's owner. This is decremented at de-alloc time.
The reason why this needs to be here is, if the user writes
for instance;
py loc = gdb.breakpoints()[X].locations[Y]
The breakpoint owner object is immediately going
out of scope (GC'd/dealloced), and the location
object requires it to be alive for as long as it is alive.
Thanks for your review, Tom!
v4:
Fixed remaining doc issues as per request
by Eli.
v3:
Rewritten commit message, shortened + reworded,
added tests.
Patch Description
Currently, the Python API lacks the ability to
query breakpoints for their installed locations,
and subsequently, can't query any information about them, or
enable/disable individual locations.
This patch solves this by adding Python type gdb.BreakpointLocation.
The type is never instantiated by the user of the Python API directly,
but is produced by the gdb.Breakpoint.locations attribute returning
a list of gdb.BreakpointLocation.
gdb.Breakpoint.locations:
The attribute for retrieving the currently installed breakpoint
locations for gdb.Breakpoint. Matches behavior of
the "info breakpoints" command in that it only
returns the last known or currently inserted breakpoint locations.
BreakpointLocation contains 7 attributes
6 read-only attributes:
owner: location owner's Python companion object
source: file path and line number tuple: (string, long) / None
address: installed address of the location
function: function name where location was set
fullname: fullname where location was set
thread_groups: thread groups (inferiors) where location was set.
1 writeable attribute:
enabled: get/set enable/disable this location (bool)
Access/calls to these, can all throw Python exceptions (documented in
the online documentation), and that's due to the nature
of how breakpoint locations can be invalidated
"behind the scenes", either by them being removed
from the original breakpoint or changed,
like for instance when a new symbol file is loaded, at
which point all breakpoint locations are re-created by GDB.
Therefore this patch has chosen to be non-intrusive:
it's up to the Python user to re-request the locations if
they become invalid.
Also there's event handlers that handle new object files etc, if a Python
user is storing breakpoint locations in some larger state they've
built up, refreshing the locations is easy and it only comes
with runtime overhead when the Python user wants to use them.
gdb.BreakpointLocation Python type
struct "gdbpy_breakpoint_location_object" is found in python-internal.h
Its definition, layout, methods and functions
are found in the same file as gdb.Breakpoint (py-breakpoint.c)
1 change was also made to breakpoint.h/c to make it possible
to enable and disable a bp_location* specifically,
without having its LOC_NUM, as this number
also can change arbitrarily behind the scenes.
Updated docs & news file as per request.
Testsuite: tests the .source attribute and the disabling of
individual locations.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385
Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0
2022-06-07 13:57:48 +02:00
|
|
|
@subheading Breakpoint Locations
|
|
|
|
|
|
|
|
|
|
A breakpoint location is one of the actual places where a breakpoint has been
|
|
|
|
|
set, represented in the Python API by the @code{gdb.BreakpointLocation}
|
|
|
|
|
type. This type is never instantiated by the user directly, but is retrieved
|
|
|
|
|
from @code{Breakpoint.locations} which returns a list of breakpoint
|
|
|
|
|
locations where it is currently set. Breakpoint locations can become
|
|
|
|
|
invalid if new symbol files are loaded or dynamically loaded libraries are
|
|
|
|
|
closed. Accessing the attributes of an invalidated breakpoint location will
|
|
|
|
|
throw a @code{RuntimeError} exception. Access the @code{Breakpoint.locations}
|
|
|
|
|
attribute again to retrieve the new and valid breakpoints location list.
|
|
|
|
|
|
|
|
|
|
@defvar BreakpointLocation.source
|
|
|
|
|
This attribute returns the source file path and line number where this location
|
|
|
|
|
was set. The type of the attribute is a tuple of @var{string} and
|
|
|
|
|
@var{long}. If the breakpoint location doesn't have a source location,
|
|
|
|
|
it returns None, which is the case for watchpoints and catchpoints.
|
|
|
|
|
This will throw a @code{RuntimeError} exception if the location
|
|
|
|
|
has been invalidated. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar BreakpointLocation.address
|
|
|
|
|
This attribute returns the address where this location was set.
|
|
|
|
|
This attribute is of type long. This will throw a @code{RuntimeError}
|
|
|
|
|
exception if the location has been invalidated. This attribute is
|
|
|
|
|
not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar BreakpointLocation.enabled
|
|
|
|
|
This attribute holds the value for whether or not this location is enabled.
|
|
|
|
|
This attribute is writable (boolean). This will throw a @code{RuntimeError}
|
|
|
|
|
exception if the location has been invalidated.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar BreakpointLocation.owner
|
|
|
|
|
This attribute holds a reference to the @code{gdb.Breakpoint} owner object,
|
|
|
|
|
from which this @code{gdb.BreakpointLocation} was retrieved from.
|
|
|
|
|
This will throw a @code{RuntimeError} exception if the location has been
|
|
|
|
|
invalidated. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar BreakpointLocation.function
|
|
|
|
|
This attribute gets the name of the function where this location was set.
|
|
|
|
|
If no function could be found this attribute returns @code{None}.
|
|
|
|
|
This will throw a @code{RuntimeError} exception if the location has
|
|
|
|
|
been invalidated. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar BreakpointLocation.fullname
|
|
|
|
|
This attribute gets the full name of where this location was set. If no
|
|
|
|
|
full name could be found, this attribute returns @code{None}.
|
|
|
|
|
This will throw a @code{RuntimeError} exception if the location has
|
|
|
|
|
been invalidated. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar BreakpointLocation.thread_groups
|
|
|
|
|
This attribute gets the thread groups it was set in. It returns a @code{List}
|
|
|
|
|
of the thread group ID's. This will throw a @code{RuntimeError}
|
|
|
|
|
exception if the location has been invalidated. This attribute
|
|
|
|
|
is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Finish Breakpoints in Python
|
|
|
|
|
@subsubsection Finish Breakpoints
|
|
|
|
|
|
|
|
|
|
@cindex python finish breakpoints
|
|
|
|
|
@tindex gdb.FinishBreakpoint
|
|
|
|
|
|
|
|
|
|
A finish breakpoint is a temporary breakpoint set at the return address of
|
|
|
|
|
a frame, based on the @code{finish} command. @code{gdb.FinishBreakpoint}
|
|
|
|
|
extends @code{gdb.Breakpoint}. The underlying breakpoint will be disabled
|
|
|
|
|
and deleted when the execution will run out of the breakpoint scope (i.e.@:
|
|
|
|
|
@code{Breakpoint.stop} or @code{FinishBreakpoint.out_of_scope} triggered).
|
|
|
|
|
Finish breakpoints are thread specific and must be create with the right
|
|
|
|
|
thread selected.
|
|
|
|
|
|
|
|
|
|
@defun FinishBreakpoint.__init__ (@r{[}frame@r{]} @r{[}, internal@r{]})
|
|
|
|
|
Create a finish breakpoint at the return address of the @code{gdb.Frame}
|
|
|
|
|
object @var{frame}. If @var{frame} is not provided, this defaults to the
|
|
|
|
|
newest frame. The optional @var{internal} argument allows the breakpoint to
|
|
|
|
|
become invisible to the user. @xref{Breakpoints In Python}, for further
|
|
|
|
|
details about this argument.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun FinishBreakpoint.out_of_scope (self)
|
|
|
|
|
In some circumstances (e.g.@: @code{longjmp}, C@t{++} exceptions, @value{GDBN}
|
|
|
|
|
@code{return} command, @dots{}), a function may not properly terminate, and
|
|
|
|
|
thus never hit the finish breakpoint. When @value{GDBN} notices such a
|
|
|
|
|
situation, the @code{out_of_scope} callback will be triggered.
|
|
|
|
|
|
|
|
|
|
You may want to sub-class @code{gdb.FinishBreakpoint} and override this
|
|
|
|
|
method:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class MyFinishBreakpoint (gdb.FinishBreakpoint)
|
|
|
|
|
def stop (self):
|
2021-01-25 10:28:53 -05:00
|
|
|
print ("normal finish")
|
2014-02-17 10:35:03 -08:00
|
|
|
return True
|
|
|
|
|
|
|
|
|
|
def out_of_scope ():
|
2021-01-25 10:28:53 -05:00
|
|
|
print ("abnormal finish")
|
2014-02-17 10:35:03 -08:00
|
|
|
@end smallexample
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defvar FinishBreakpoint.return_value
|
|
|
|
|
When @value{GDBN} is stopped at a finish breakpoint and the frame
|
|
|
|
|
used to build the @code{gdb.FinishBreakpoint} object had debug symbols, this
|
|
|
|
|
attribute will contain a @code{gdb.Value} object corresponding to the return
|
|
|
|
|
value of the function. The value will be @code{None} if the function return
|
|
|
|
|
type is @code{void} or if the return value was not computable. This attribute
|
|
|
|
|
is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@node Lazy Strings In Python
|
2018-09-08 14:00:48 -06:00
|
|
|
@subsubsection Python representation of lazy strings
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@cindex lazy strings in python
|
|
|
|
|
@tindex gdb.LazyString
|
|
|
|
|
|
|
|
|
|
A @dfn{lazy string} is a string whose contents is not retrieved or
|
|
|
|
|
encoded until it is needed.
|
|
|
|
|
|
|
|
|
|
A @code{gdb.LazyString} is represented in @value{GDBN} as an
|
|
|
|
|
@code{address} that points to a region of memory, an @code{encoding}
|
|
|
|
|
that will be used to encode that region of memory, and a @code{length}
|
|
|
|
|
to delimit the region of memory that represents the string. The
|
|
|
|
|
difference between a @code{gdb.LazyString} and a string wrapped within
|
2024-11-15 08:02:25 -07:00
|
|
|
a @code{gdb.Value} is that a @code{gdb.LazyString} will only be
|
2014-02-17 10:35:03 -08:00
|
|
|
retrieved and encoded during printing, while a @code{gdb.Value}
|
|
|
|
|
wrapping a string is immediately retrieved and encoded on creation.
|
|
|
|
|
|
2024-11-15 08:02:25 -07:00
|
|
|
A @code{gdb.LazyString} can be created using the
|
|
|
|
|
@code{gdb.Value.lazy_string} method (@pxref{Values From Inferior}).
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
A @code{gdb.LazyString} object has the following functions:
|
|
|
|
|
|
|
|
|
|
@defun LazyString.value ()
|
|
|
|
|
Convert the @code{gdb.LazyString} to a @code{gdb.Value}. This value
|
|
|
|
|
will point to the string in memory, but will lose all the delayed
|
|
|
|
|
retrieval, encoding and handling that @value{GDBN} applies to a
|
|
|
|
|
@code{gdb.LazyString}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defvar LazyString.address
|
|
|
|
|
This attribute holds the address of the string. This attribute is not
|
|
|
|
|
writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar LazyString.length
|
|
|
|
|
This attribute holds the length of the string in characters. If the
|
|
|
|
|
length is -1, then the string will be fetched and encoded up to the
|
|
|
|
|
first null of appropriate width. This attribute is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar LazyString.encoding
|
|
|
|
|
This attribute holds the encoding that will be applied to the string
|
|
|
|
|
when the string is printed by @value{GDBN}. If the encoding is not
|
|
|
|
|
set, or contains an empty string, then @value{GDBN} will select the
|
|
|
|
|
most appropriate encoding when the string is printed. This attribute
|
|
|
|
|
is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar LazyString.type
|
|
|
|
|
This attribute holds the type that is represented by the lazy string's
|
2016-11-06 16:03:56 -08:00
|
|
|
type. For a lazy string this is a pointer or array type. To
|
2014-02-17 10:35:03 -08:00
|
|
|
resolve this to the lazy string's character type, use the type's
|
|
|
|
|
@code{target} method. @xref{Types In Python}. This attribute is not
|
|
|
|
|
writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2024-10-05 22:27:44 +03:00
|
|
|
@node Colors In Python
|
|
|
|
|
@subsubsection Python representation of colors
|
|
|
|
|
|
|
|
|
|
@cindex colors in python
|
|
|
|
|
@tindex gdb.Color
|
gdb/doc: tweaks to documentation for gdb.Color
While reading through the documentation for the new gdb.Color class I
spotted a couple of things which I thought could be improved:
* I replaced @code{Color} with @code{gdb.Color}. Most of the other
classes are referenced with the 'gdb.' prefix, so this makes
gdb.Color consistent. Including the 'gdb.' prefix makes it far
easier to search the documentation to find relevant content. And
finally, my understanding is that usually in Python code, the
class would be written as 'gdb.Color' unless the user specifically
pulls 'Color' into the current scope using 'from gdb import
Color'.
* Replace 'colorspace' with 'color space'. There was already a use
of the two word form in the documentation (for gdb.Color), so this
just makes things consistent.
* Removed use of @var on two @defun lines. No other @defun lines
use @var, so the use of @var here was making the output
inconsistent, e.g. in the 'info' output, @var causes the string to
be capitalised.
* Rename the 'color-space' argument to 'color_space' for
Color.__init__. In the next commit I plan to add Python keyword
argument support to this function, which means the argument name
needs to be a valid keyword (i.e. must not contain the '-'
character).
* Added a pointer to where the @samp{COLORSPACE_} constants can be
found. These constants are referenced before they are defined in
the documentation, which is fine, but I think it is a good idea to
let the user know where the constants can be found when we first
reference them.
* Remove use of 'self' for the Color.escape_sequence documentation.
There are a few functions that do include 'self' as an argument (I
think this is a mistake) but the vast majority don't. I think not
including 'self' is the better approach; a user wouldn't be
expected to explicitly pass 'self', this is done automatically by
Python as a result of calling the method on an object. So I've
removed the reference to 'self' from this method.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
2025-04-23 09:48:11 +01:00
|
|
|
You can assign instance of @code{gdb.Color} to the @code{value} of
|
2024-10-05 22:27:44 +03:00
|
|
|
a @code{Parameter} instance created with @code{PARAM_COLOR}.
|
|
|
|
|
|
gdb/doc: tweaks to documentation for gdb.Color
While reading through the documentation for the new gdb.Color class I
spotted a couple of things which I thought could be improved:
* I replaced @code{Color} with @code{gdb.Color}. Most of the other
classes are referenced with the 'gdb.' prefix, so this makes
gdb.Color consistent. Including the 'gdb.' prefix makes it far
easier to search the documentation to find relevant content. And
finally, my understanding is that usually in Python code, the
class would be written as 'gdb.Color' unless the user specifically
pulls 'Color' into the current scope using 'from gdb import
Color'.
* Replace 'colorspace' with 'color space'. There was already a use
of the two word form in the documentation (for gdb.Color), so this
just makes things consistent.
* Removed use of @var on two @defun lines. No other @defun lines
use @var, so the use of @var here was making the output
inconsistent, e.g. in the 'info' output, @var causes the string to
be capitalised.
* Rename the 'color-space' argument to 'color_space' for
Color.__init__. In the next commit I plan to add Python keyword
argument support to this function, which means the argument name
needs to be a valid keyword (i.e. must not contain the '-'
character).
* Added a pointer to where the @samp{COLORSPACE_} constants can be
found. These constants are referenced before they are defined in
the documentation, which is fine, but I think it is a good idea to
let the user know where the constants can be found when we first
reference them.
* Remove use of 'self' for the Color.escape_sequence documentation.
There are a few functions that do include 'self' as an argument (I
think this is a mistake) but the vast majority don't. I think not
including 'self' is the better approach; a user wouldn't be
expected to explicitly pass 'self', this is done automatically by
Python as a result of calling the method on an object. So I've
removed the reference to 'self' from this method.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
2025-04-23 09:48:11 +01:00
|
|
|
@code{gdb.Color} may refer to an index from a color palette or contain
|
|
|
|
|
components of a color from some color space.
|
2024-10-05 22:27:44 +03:00
|
|
|
|
gdb/doc: tweaks to documentation for gdb.Color
While reading through the documentation for the new gdb.Color class I
spotted a couple of things which I thought could be improved:
* I replaced @code{Color} with @code{gdb.Color}. Most of the other
classes are referenced with the 'gdb.' prefix, so this makes
gdb.Color consistent. Including the 'gdb.' prefix makes it far
easier to search the documentation to find relevant content. And
finally, my understanding is that usually in Python code, the
class would be written as 'gdb.Color' unless the user specifically
pulls 'Color' into the current scope using 'from gdb import
Color'.
* Replace 'colorspace' with 'color space'. There was already a use
of the two word form in the documentation (for gdb.Color), so this
just makes things consistent.
* Removed use of @var on two @defun lines. No other @defun lines
use @var, so the use of @var here was making the output
inconsistent, e.g. in the 'info' output, @var causes the string to
be capitalised.
* Rename the 'color-space' argument to 'color_space' for
Color.__init__. In the next commit I plan to add Python keyword
argument support to this function, which means the argument name
needs to be a valid keyword (i.e. must not contain the '-'
character).
* Added a pointer to where the @samp{COLORSPACE_} constants can be
found. These constants are referenced before they are defined in
the documentation, which is fine, but I think it is a good idea to
let the user know where the constants can be found when we first
reference them.
* Remove use of 'self' for the Color.escape_sequence documentation.
There are a few functions that do include 'self' as an argument (I
think this is a mistake) but the vast majority don't. I think not
including 'self' is the better approach; a user wouldn't be
expected to explicitly pass 'self', this is done automatically by
Python as a result of calling the method on an object. So I've
removed the reference to 'self' from this method.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
2025-04-23 09:48:11 +01:00
|
|
|
@defun Color.__init__ (@r{[}value @r{[}, color_space@r{]}@r{]})
|
2024-10-05 22:27:44 +03:00
|
|
|
|
|
|
|
|
@var{value} is @code{None} (meaning the terminal's default color),
|
|
|
|
|
an integer index of a color in palette, tuple with color components
|
|
|
|
|
or a string. String can be a hex RGB triplet in @samp{#RRGGBB} format
|
|
|
|
|
or one of the following color names:
|
|
|
|
|
@samp{none} (meaning the terminal's default color), @samp{black}, @samp{red},
|
|
|
|
|
@samp{green}, @samp{yellow}, @samp{blue}, @samp{magenta}, @samp{cyan},
|
|
|
|
|
or @samp{white}.
|
|
|
|
|
|
gdb/doc: tweaks to documentation for gdb.Color
While reading through the documentation for the new gdb.Color class I
spotted a couple of things which I thought could be improved:
* I replaced @code{Color} with @code{gdb.Color}. Most of the other
classes are referenced with the 'gdb.' prefix, so this makes
gdb.Color consistent. Including the 'gdb.' prefix makes it far
easier to search the documentation to find relevant content. And
finally, my understanding is that usually in Python code, the
class would be written as 'gdb.Color' unless the user specifically
pulls 'Color' into the current scope using 'from gdb import
Color'.
* Replace 'colorspace' with 'color space'. There was already a use
of the two word form in the documentation (for gdb.Color), so this
just makes things consistent.
* Removed use of @var on two @defun lines. No other @defun lines
use @var, so the use of @var here was making the output
inconsistent, e.g. in the 'info' output, @var causes the string to
be capitalised.
* Rename the 'color-space' argument to 'color_space' for
Color.__init__. In the next commit I plan to add Python keyword
argument support to this function, which means the argument name
needs to be a valid keyword (i.e. must not contain the '-'
character).
* Added a pointer to where the @samp{COLORSPACE_} constants can be
found. These constants are referenced before they are defined in
the documentation, which is fine, but I think it is a good idea to
let the user know where the constants can be found when we first
reference them.
* Remove use of 'self' for the Color.escape_sequence documentation.
There are a few functions that do include 'self' as an argument (I
think this is a mistake) but the vast majority don't. I think not
including 'self' is the better approach; a user wouldn't be
expected to explicitly pass 'self', this is done automatically by
Python as a result of calling the method on an object. So I've
removed the reference to 'self' from this method.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
2025-04-23 09:48:11 +01:00
|
|
|
@var{color_space} should be one of the @samp{COLORSPACE_} constants
|
|
|
|
|
listed below. This argument tells @value{GDBN} which color space
|
|
|
|
|
@var{value} belongs.
|
2024-10-05 22:27:44 +03:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defvar Color.is_none
|
2025-03-06 22:41:32 +01:00
|
|
|
This attribute is boolean. If its value is @code{True} then color is terminal's
|
2024-10-05 22:27:44 +03:00
|
|
|
default.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Color.is_indexed
|
2025-03-06 22:41:32 +01:00
|
|
|
This attribute is boolean. If its value is @code{True} then color is indexed,
|
2024-10-05 22:27:44 +03:00
|
|
|
i.e. belongs to some palette.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Color.is_direct
|
2025-03-06 22:41:32 +01:00
|
|
|
This attribute is boolean. If its value is @code{True} then this object
|
2024-10-05 22:27:44 +03:00
|
|
|
describes direct colour in the sense of ISO/IEC 8613-6.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Color.index
|
|
|
|
|
This attribute exist if @code{is_indexed} is @code{True}. Its integer value is
|
|
|
|
|
index of a color in a palette.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar Color.components
|
|
|
|
|
This attribute exist if @code{is_direct} is @code{True}. Its value is tuple
|
|
|
|
|
with integer components of a color.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/doc: tweaks to documentation for gdb.Color
While reading through the documentation for the new gdb.Color class I
spotted a couple of things which I thought could be improved:
* I replaced @code{Color} with @code{gdb.Color}. Most of the other
classes are referenced with the 'gdb.' prefix, so this makes
gdb.Color consistent. Including the 'gdb.' prefix makes it far
easier to search the documentation to find relevant content. And
finally, my understanding is that usually in Python code, the
class would be written as 'gdb.Color' unless the user specifically
pulls 'Color' into the current scope using 'from gdb import
Color'.
* Replace 'colorspace' with 'color space'. There was already a use
of the two word form in the documentation (for gdb.Color), so this
just makes things consistent.
* Removed use of @var on two @defun lines. No other @defun lines
use @var, so the use of @var here was making the output
inconsistent, e.g. in the 'info' output, @var causes the string to
be capitalised.
* Rename the 'color-space' argument to 'color_space' for
Color.__init__. In the next commit I plan to add Python keyword
argument support to this function, which means the argument name
needs to be a valid keyword (i.e. must not contain the '-'
character).
* Added a pointer to where the @samp{COLORSPACE_} constants can be
found. These constants are referenced before they are defined in
the documentation, which is fine, but I think it is a good idea to
let the user know where the constants can be found when we first
reference them.
* Remove use of 'self' for the Color.escape_sequence documentation.
There are a few functions that do include 'self' as an argument (I
think this is a mistake) but the vast majority don't. I think not
including 'self' is the better approach; a user wouldn't be
expected to explicitly pass 'self', this is done automatically by
Python as a result of calling the method on an object. So I've
removed the reference to 'self' from this method.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
2025-04-23 09:48:11 +01:00
|
|
|
@defun Color.escape_sequence (is_foreground)
|
2024-10-05 22:27:44 +03:00
|
|
|
Returns string to change terminal's color to this.
|
|
|
|
|
|
|
|
|
|
If @var{is_foreground} is @code{True}, then the returned sequence will change
|
|
|
|
|
foreground color. Otherwise, the returned sequence will change background
|
|
|
|
|
color.
|
2025-04-29 17:57:06 +01:00
|
|
|
|
|
|
|
|
If styling is currently disabled (@pxref{Output Styling,,@kbd{set style
|
|
|
|
|
enabled}}), then this method will return an empty string.
|
2024-10-05 22:27:44 +03:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
When color is initialized, its color space must be specified. The
|
|
|
|
|
available color spaces are represented by constants defined in the @code{gdb}
|
|
|
|
|
module:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@findex COLORSPACE_MONOCHROME
|
|
|
|
|
@findex gdb.COLORSPACE_MONOCHROME
|
|
|
|
|
@item gdb.COLORSPACE_MONOCHROME
|
|
|
|
|
Palette with only terminal's default color.
|
|
|
|
|
|
|
|
|
|
@findex COLORSPACE_ANSI_8COLOR
|
|
|
|
|
@findex gdb.COLORSPACE_ANSI_8COLOR
|
|
|
|
|
@item gdb.COLORSPACE_ANSI_8COLOR
|
|
|
|
|
Palette with eight standard colors of ISO/IEC 6429 "black", "red", "green", etc.
|
|
|
|
|
|
|
|
|
|
@findex COLORSPACE_AIXTERM_16COLOR
|
|
|
|
|
@findex gdb.COLORSPACE_AIXTERM_16COLOR
|
|
|
|
|
@item gdb.COLORSPACE_AIXTERM_16COLOR
|
|
|
|
|
Palette with 16 colors. First eight are standard colors of ISO/IEC 6429
|
|
|
|
|
"black", "red", "green", etc. Next eight are their bright version.
|
|
|
|
|
|
|
|
|
|
@findex COLORSPACE_XTERM_256COLOR
|
|
|
|
|
@findex gdb.COLORSPACE_XTERM_256COLOR
|
|
|
|
|
@item gdb.COLORSPACE_XTERM_256COLOR
|
|
|
|
|
Palette with 256 colors. First 16 are from COLORSPACE_AIXTERM_16COLOR. Next
|
|
|
|
|
216 colors are 6x6x6 RGB cube. And last 24 colors form grayscale ramp.
|
|
|
|
|
|
|
|
|
|
@findex COLORSPACE_RGB_24BIT
|
|
|
|
|
@findex gdb.COLORSPACE_RGB_24BIT
|
|
|
|
|
@item gdb.COLORSPACE_RGB_24BIT
|
|
|
|
|
Direct 24-bit RGB colors.
|
|
|
|
|
|
|
|
|
|
@end table
|
|
|
|
|
|
2025-04-22 18:01:07 +01:00
|
|
|
It is not possible to sub-class the @code{Color} class.
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Architectures In Python
|
|
|
|
|
@subsubsection Python representation of architectures
|
|
|
|
|
@cindex Python architectures
|
|
|
|
|
|
|
|
|
|
@value{GDBN} uses architecture specific parameters and artifacts in a
|
|
|
|
|
number of its various computations. An architecture is represented
|
|
|
|
|
by an instance of the @code{gdb.Architecture} class.
|
|
|
|
|
|
|
|
|
|
A @code{gdb.Architecture} class has the following methods:
|
|
|
|
|
|
2021-09-15 13:34:14 +01:00
|
|
|
@anchor{gdbpy_architecture_name}
|
2014-02-17 10:35:03 -08:00
|
|
|
@defun Architecture.name ()
|
|
|
|
|
Return the name (string value) of the architecture.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Architecture.disassemble (start_pc @r{[}, end_pc @r{[}, count@r{]]})
|
2014-02-17 10:35:03 -08:00
|
|
|
Return a list of disassembled instructions starting from the memory
|
|
|
|
|
address @var{start_pc}. The optional arguments @var{end_pc} and
|
|
|
|
|
@var{count} determine the number of instructions in the returned list.
|
|
|
|
|
If both the optional arguments @var{end_pc} and @var{count} are
|
|
|
|
|
specified, then a list of at most @var{count} disassembled instructions
|
|
|
|
|
whose start address falls in the closed memory address interval from
|
|
|
|
|
@var{start_pc} to @var{end_pc} are returned. If @var{end_pc} is not
|
|
|
|
|
specified, but @var{count} is specified, then @var{count} number of
|
|
|
|
|
instructions starting from the address @var{start_pc} are returned. If
|
|
|
|
|
@var{count} is not specified but @var{end_pc} is specified, then all
|
|
|
|
|
instructions whose start address falls in the closed memory address
|
|
|
|
|
interval from @var{start_pc} to @var{end_pc} are returned. If neither
|
|
|
|
|
@var{end_pc} nor @var{count} are specified, then a single instruction at
|
|
|
|
|
@var{start_pc} is returned. For all of these cases, each element of the
|
|
|
|
|
returned list is a Python @code{dict} with the following string keys:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
|
|
|
|
|
@item addr
|
|
|
|
|
The value corresponding to this key is a Python long integer capturing
|
|
|
|
|
the memory address of the instruction.
|
|
|
|
|
|
|
|
|
|
@item asm
|
|
|
|
|
The value corresponding to this key is a string value which represents
|
|
|
|
|
the instruction with assembly language mnemonics. The assembly
|
|
|
|
|
language flavor used is the same as that specified by the current CLI
|
|
|
|
|
variable @code{disassembly-flavor}. @xref{Machine Code}.
|
|
|
|
|
|
|
|
|
|
@item length
|
|
|
|
|
The value corresponding to this key is the length (integer value) of the
|
|
|
|
|
instruction in bytes.
|
|
|
|
|
|
|
|
|
|
@end table
|
|
|
|
|
@end defun
|
|
|
|
|
|
2021-10-22 10:49:19 -06:00
|
|
|
@defun Architecture.integer_type (size @r{[}, signed@r{]})
|
|
|
|
|
This function looks up an integer type by its @var{size}, and
|
|
|
|
|
optionally whether or not it is signed.
|
|
|
|
|
|
|
|
|
|
@var{size} is the size, in bits, of the desired integer type. Only
|
|
|
|
|
certain sizes are currently supported: 0, 8, 16, 24, 32, 64, and 128.
|
|
|
|
|
|
|
|
|
|
If @var{signed} is not specified, it defaults to @code{True}. If
|
|
|
|
|
@var{signed} is @code{False}, the returned type will be unsigned.
|
|
|
|
|
|
|
|
|
|
If the indicated type cannot be found, this function will throw a
|
|
|
|
|
@code{ValueError} exception.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2025-02-04 13:56:49 +00:00
|
|
|
@defun Architecture.void_type ()
|
|
|
|
|
This function returns a void type.
|
|
|
|
|
@end defun
|
|
|
|
|
|
gdb/python: Add gdb.Architecture.registers method
This commit adds a new method gdb.Architecture.registers that returns
an object of the new type gdb.RegisterDescriptorIterator. This
iterator returns objects of the new type gdb.RegisterDescriptor.
A RegisterDescriptor is not a way to read the value of a register,
this is already covered by Frame.read_register, a RegisterDescriptor
is simply a way to discover from Python, which registers are
available for a given architecture.
I did consider just returning a string, the name of each register,
instead of a RegisterDescriptor, however, I'm aware that it we don't
want to break the existing Python API in any way, so if I return just
a string now, but in the future we want more information about a
register then we would have to add a second API to get that
information. By going straight to a descriptor object now, it is easy
to add additional properties in the future should we wish to.
Right now the only property of a register that a user can access is
the name of the register.
In future we might want to be able to ask the register about is
register groups, or its type.
gdb/ChangeLog:
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c
* python/py-arch.c (archpy_registers): New function.
(arch_object_methods): Add 'registers' method.
* python/py-registers.c: New file.
* python/python-internal.h
(gdbpy_new_register_descriptor_iterator): Declare.
(gdbpy_initialize_registers): Declare.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_registers.
* NEWS: Mention additions to the Python API.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: New file.
gdb/doc/ChangeLog:
* python.texi (Python API): Add new section the menu.
(Frames In Python): Add new @anchor.
(Architectures In Python): Document new registers method.
(Registers In Python): New section.
2020-06-05 17:52:10 +01:00
|
|
|
@anchor{gdbpy_architecture_registers}
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Architecture.registers (@r{[} reggroup @r{]})
|
gdb/python: Add gdb.Architecture.registers method
This commit adds a new method gdb.Architecture.registers that returns
an object of the new type gdb.RegisterDescriptorIterator. This
iterator returns objects of the new type gdb.RegisterDescriptor.
A RegisterDescriptor is not a way to read the value of a register,
this is already covered by Frame.read_register, a RegisterDescriptor
is simply a way to discover from Python, which registers are
available for a given architecture.
I did consider just returning a string, the name of each register,
instead of a RegisterDescriptor, however, I'm aware that it we don't
want to break the existing Python API in any way, so if I return just
a string now, but in the future we want more information about a
register then we would have to add a second API to get that
information. By going straight to a descriptor object now, it is easy
to add additional properties in the future should we wish to.
Right now the only property of a register that a user can access is
the name of the register.
In future we might want to be able to ask the register about is
register groups, or its type.
gdb/ChangeLog:
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c
* python/py-arch.c (archpy_registers): New function.
(arch_object_methods): Add 'registers' method.
* python/py-registers.c: New file.
* python/python-internal.h
(gdbpy_new_register_descriptor_iterator): Declare.
(gdbpy_initialize_registers): Declare.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_registers.
* NEWS: Mention additions to the Python API.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: New file.
gdb/doc/ChangeLog:
* python.texi (Python API): Add new section the menu.
(Frames In Python): Add new @anchor.
(Architectures In Python): Document new registers method.
(Registers In Python): New section.
2020-06-05 17:52:10 +01:00
|
|
|
Return a @code{gdb.RegisterDescriptorIterator} (@pxref{Registers In
|
|
|
|
|
Python}) for all of the registers in @var{reggroup}, a string that is
|
|
|
|
|
the name of a register group. If @var{reggroup} is omitted, or is the
|
|
|
|
|
empty string, then the register group @samp{all} is assumed.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2020-06-07 10:08:01 +01:00
|
|
|
@anchor{gdbpy_architecture_reggroups}
|
|
|
|
|
@defun Architecture.register_groups ()
|
|
|
|
|
Return a @code{gdb.RegisterGroupsIterator} (@pxref{Registers In
|
|
|
|
|
Python}) for all of the register groups available for the
|
|
|
|
|
@code{gdb.Architecture}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
gdb/python: Add gdb.Architecture.registers method
This commit adds a new method gdb.Architecture.registers that returns
an object of the new type gdb.RegisterDescriptorIterator. This
iterator returns objects of the new type gdb.RegisterDescriptor.
A RegisterDescriptor is not a way to read the value of a register,
this is already covered by Frame.read_register, a RegisterDescriptor
is simply a way to discover from Python, which registers are
available for a given architecture.
I did consider just returning a string, the name of each register,
instead of a RegisterDescriptor, however, I'm aware that it we don't
want to break the existing Python API in any way, so if I return just
a string now, but in the future we want more information about a
register then we would have to add a second API to get that
information. By going straight to a descriptor object now, it is easy
to add additional properties in the future should we wish to.
Right now the only property of a register that a user can access is
the name of the register.
In future we might want to be able to ask the register about is
register groups, or its type.
gdb/ChangeLog:
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c
* python/py-arch.c (archpy_registers): New function.
(arch_object_methods): Add 'registers' method.
* python/py-registers.c: New file.
* python/python-internal.h
(gdbpy_new_register_descriptor_iterator): Declare.
(gdbpy_initialize_registers): Declare.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_registers.
* NEWS: Mention additions to the Python API.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: New file.
gdb/doc/ChangeLog:
* python.texi (Python API): Add new section the menu.
(Frames In Python): Add new @anchor.
(Architectures In Python): Document new registers method.
(Registers In Python): New section.
2020-06-05 17:52:10 +01:00
|
|
|
@node Registers In Python
|
|
|
|
|
@subsubsection Registers In Python
|
|
|
|
|
@cindex Registers In Python
|
|
|
|
|
|
|
|
|
|
Python code can request from a @code{gdb.Architecture} information
|
|
|
|
|
about the set of registers available
|
|
|
|
|
(@pxref{gdbpy_architecture_registers,,@code{Architecture.registers}}).
|
|
|
|
|
The register information is returned as a
|
|
|
|
|
@code{gdb.RegisterDescriptorIterator}, which is an iterator that in
|
|
|
|
|
turn returns @code{gdb.RegisterDescriptor} objects.
|
|
|
|
|
|
|
|
|
|
A @code{gdb.RegisterDescriptor} does not provide the value of a
|
|
|
|
|
register (@pxref{gdbpy_frame_read_register,,@code{Frame.read_register}}
|
|
|
|
|
for reading a register's value), instead the @code{RegisterDescriptor}
|
|
|
|
|
is a way to discover which registers are available for a particular
|
|
|
|
|
architecture.
|
|
|
|
|
|
|
|
|
|
A @code{gdb.RegisterDescriptor} has the following read-only properties:
|
|
|
|
|
|
|
|
|
|
@defvar RegisterDescriptor.name
|
|
|
|
|
The name of this register.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2020-07-22 14:02:30 +01:00
|
|
|
It is also possible to lookup a register descriptor based on its name
|
|
|
|
|
using the following @code{gdb.RegisterDescriptorIterator} function:
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun RegisterDescriptorIterator.find (name)
|
2020-07-22 14:02:30 +01:00
|
|
|
Takes @var{name} as an argument, which must be a string, and returns a
|
|
|
|
|
@code{gdb.RegisterDescriptor} for the register with that name, or
|
|
|
|
|
@code{None} if there is no register with that name.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2020-06-07 10:08:01 +01:00
|
|
|
Python code can also request from a @code{gdb.Architecture}
|
|
|
|
|
information about the set of register groups available on a given
|
|
|
|
|
architecture
|
|
|
|
|
(@pxref{gdbpy_architecture_reggroups,,@code{Architecture.register_groups}}).
|
|
|
|
|
|
|
|
|
|
Every register can be a member of zero or more register groups. Some
|
|
|
|
|
register groups are used internally within @value{GDBN} to control
|
|
|
|
|
things like which registers must be saved when calling into the
|
|
|
|
|
program being debugged (@pxref{Calling,,Calling Program Functions}).
|
|
|
|
|
Other register groups exist to allow users to easily see related sets
|
|
|
|
|
of registers in commands like @code{info registers}
|
|
|
|
|
(@pxref{info_registers_reggroup,,@code{info registers
|
|
|
|
|
@var{reggroup}}}).
|
|
|
|
|
|
|
|
|
|
The register groups information is returned as a
|
|
|
|
|
@code{gdb.RegisterGroupsIterator}, which is an iterator that in turn
|
|
|
|
|
returns @code{gdb.RegisterGroup} objects.
|
|
|
|
|
|
|
|
|
|
A @code{gdb.RegisterGroup} object has the following read-only
|
|
|
|
|
properties:
|
|
|
|
|
|
|
|
|
|
@defvar RegisterGroup.name
|
|
|
|
|
A string that is the name of this register group.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
gdb/python: introduce gdb.TargetConnection object type
This commit adds a new object type gdb.TargetConnection. This new
type represents a connection within GDB (a connection as displayed by
'info connections').
There's three ways to find a gdb.TargetConnection, there's a new
'gdb.connections()' function, which returns a list of all currently
active connections.
Or you can read the new 'connection' property on the gdb.Inferior
object type, this contains the connection for that inferior (or None
if the inferior has no connection, for example, it is exited).
Finally, there's a new gdb.events.connection_removed event registry,
this emits a new gdb.ConnectionEvent whenever a connection is removed
from GDB (this can happen when all inferiors using a connection exit,
though this is not always the case, depending on the connection type).
The gdb.ConnectionEvent has a 'connection' property, which is the
gdb.TargetConnection being removed from GDB.
The gdb.TargetConnection has an 'is_valid()' method. A connection
object becomes invalid when the underlying connection is removed from
GDB (as discussed above, this might be when all inferiors using a
connection exit, or it might be when the user explicitly replaces a
connection in GDB by issuing another 'target' command).
The gdb.TargetConnection has the following read-only properties:
'num': The number for this connection,
'type': e.g. 'native', 'remote', 'sim', etc
'description': The longer description as seen in the 'info
connections' command output.
'details': A string or None. Extra details for the connection, for
example, a remote connection's details might be
'hostname:port'.
2021-09-01 15:33:19 +01:00
|
|
|
@node Connections In Python
|
|
|
|
|
@subsubsection Connections In Python
|
|
|
|
|
@cindex connections in python
|
|
|
|
|
@value{GDBN} lets you run and debug multiple programs in a single
|
|
|
|
|
session. Each program being debugged has a connection, the connection
|
|
|
|
|
describes how @value{GDBN} controls the program being debugged.
|
|
|
|
|
Examples of different connection types are @samp{native} and
|
|
|
|
|
@samp{remote}. @xref{Inferiors Connections and Programs}.
|
|
|
|
|
|
2021-08-31 14:04:36 +01:00
|
|
|
Connections in @value{GDBN} are represented as instances of
|
|
|
|
|
@code{gdb.TargetConnection}, or as one of its sub-classes. To get a
|
|
|
|
|
list of all connections use @code{gdb.connections}
|
gdb/python: introduce gdb.TargetConnection object type
This commit adds a new object type gdb.TargetConnection. This new
type represents a connection within GDB (a connection as displayed by
'info connections').
There's three ways to find a gdb.TargetConnection, there's a new
'gdb.connections()' function, which returns a list of all currently
active connections.
Or you can read the new 'connection' property on the gdb.Inferior
object type, this contains the connection for that inferior (or None
if the inferior has no connection, for example, it is exited).
Finally, there's a new gdb.events.connection_removed event registry,
this emits a new gdb.ConnectionEvent whenever a connection is removed
from GDB (this can happen when all inferiors using a connection exit,
though this is not always the case, depending on the connection type).
The gdb.ConnectionEvent has a 'connection' property, which is the
gdb.TargetConnection being removed from GDB.
The gdb.TargetConnection has an 'is_valid()' method. A connection
object becomes invalid when the underlying connection is removed from
GDB (as discussed above, this might be when all inferiors using a
connection exit, or it might be when the user explicitly replaces a
connection in GDB by issuing another 'target' command).
The gdb.TargetConnection has the following read-only properties:
'num': The number for this connection,
'type': e.g. 'native', 'remote', 'sim', etc
'description': The longer description as seen in the 'info
connections' command output.
'details': A string or None. Extra details for the connection, for
example, a remote connection's details might be
'hostname:port'.
2021-09-01 15:33:19 +01:00
|
|
|
(@pxref{gdbpy_connections,,gdb.connections}).
|
|
|
|
|
|
|
|
|
|
To get the connection for a single @code{gdb.Inferior} read its
|
|
|
|
|
@code{gdb.Inferior.connection} attribute
|
|
|
|
|
(@pxref{gdbpy_inferior_connection,,gdb.Inferior.connection}).
|
|
|
|
|
|
2021-08-31 14:04:36 +01:00
|
|
|
Currently there is only a single sub-class of
|
|
|
|
|
@code{gdb.TargetConnection}, @code{gdb.RemoteTargetConnection},
|
|
|
|
|
however, additional sub-classes may be added in future releases of
|
|
|
|
|
@value{GDBN}. As a result you should avoid writing code like:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
conn = gdb.selected_inferior().connection
|
|
|
|
|
if type(conn) is gdb.RemoteTargetConnection:
|
|
|
|
|
print("This is a remote target connection")
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
as this may fail when more connection types are added. Instead, you
|
|
|
|
|
should write:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
conn = gdb.selected_inferior().connection
|
|
|
|
|
if isinstance(conn, gdb.RemoteTargetConnection):
|
|
|
|
|
print("This is a remote target connection")
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
gdb/python: introduce gdb.TargetConnection object type
This commit adds a new object type gdb.TargetConnection. This new
type represents a connection within GDB (a connection as displayed by
'info connections').
There's three ways to find a gdb.TargetConnection, there's a new
'gdb.connections()' function, which returns a list of all currently
active connections.
Or you can read the new 'connection' property on the gdb.Inferior
object type, this contains the connection for that inferior (or None
if the inferior has no connection, for example, it is exited).
Finally, there's a new gdb.events.connection_removed event registry,
this emits a new gdb.ConnectionEvent whenever a connection is removed
from GDB (this can happen when all inferiors using a connection exit,
though this is not always the case, depending on the connection type).
The gdb.ConnectionEvent has a 'connection' property, which is the
gdb.TargetConnection being removed from GDB.
The gdb.TargetConnection has an 'is_valid()' method. A connection
object becomes invalid when the underlying connection is removed from
GDB (as discussed above, this might be when all inferiors using a
connection exit, or it might be when the user explicitly replaces a
connection in GDB by issuing another 'target' command).
The gdb.TargetConnection has the following read-only properties:
'num': The number for this connection,
'type': e.g. 'native', 'remote', 'sim', etc
'description': The longer description as seen in the 'info
connections' command output.
'details': A string or None. Extra details for the connection, for
example, a remote connection's details might be
'hostname:port'.
2021-09-01 15:33:19 +01:00
|
|
|
A @code{gdb.TargetConnection} has the following method:
|
|
|
|
|
|
|
|
|
|
@defun TargetConnection.is_valid ()
|
|
|
|
|
Return @code{True} if the @code{gdb.TargetConnection} object is valid,
|
|
|
|
|
@code{False} if not. A @code{gdb.TargetConnection} will become
|
|
|
|
|
invalid if the connection no longer exists within @value{GDBN}, this
|
|
|
|
|
might happen when no inferiors are using the connection, but could be
|
|
|
|
|
delayed until the user replaces the current target.
|
|
|
|
|
|
|
|
|
|
Reading any of the @code{gdb.TargetConnection} properties will throw
|
|
|
|
|
an exception if the connection is invalid.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
A @code{gdb.TargetConnection} has the following read-only properties:
|
|
|
|
|
|
|
|
|
|
@defvar TargetConnection.num
|
|
|
|
|
An integer assigned by @value{GDBN} to uniquely identify this
|
|
|
|
|
connection. This is the same value as displayed in the @samp{Num}
|
|
|
|
|
column of the @code{info connections} command output (@pxref{Inferiors
|
|
|
|
|
Connections and Programs,,info connections}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar TargetConnection.type
|
|
|
|
|
A string that describes what type of connection this is. This string
|
|
|
|
|
will be one of the valid names that can be passed to the @code{target}
|
|
|
|
|
command (@pxref{Target Commands,,target command}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar TargetConnection.description
|
|
|
|
|
A string that gives a short description of this target type. This is
|
|
|
|
|
the same string that is displayed in the @samp{Description} column of
|
|
|
|
|
the @code{info connection} command output (@pxref{Inferiors
|
|
|
|
|
Connections and Programs,,info connections}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar TargetConnection.details
|
|
|
|
|
An optional string that gives additional information about this
|
|
|
|
|
connection. This attribute can be @code{None} if there are no
|
|
|
|
|
additional details for this connection.
|
|
|
|
|
|
|
|
|
|
An example of a connection type that might have additional details is
|
|
|
|
|
the @samp{remote} connection, in this case the details string can
|
|
|
|
|
contain the @samp{@var{hostname}:@var{port}} that was used to connect
|
|
|
|
|
to the remote target.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
2021-08-31 14:04:36 +01:00
|
|
|
The @code{gdb.RemoteTargetConnection} class is a sub-class of
|
|
|
|
|
@code{gdb.TargetConnection}, and is used to represent @samp{remote}
|
|
|
|
|
and @samp{extended-remote} connections. In addition to the attributes
|
|
|
|
|
and methods available from the @code{gdb.TargetConnection} base class,
|
|
|
|
|
a @code{gdb.RemoteTargetConnection} has the following method:
|
|
|
|
|
|
|
|
|
|
@kindex maint packet
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun RemoteTargetConnection.send_packet (packet)
|
2021-08-31 14:04:36 +01:00
|
|
|
This method sends @var{packet} to the remote target and returns the
|
|
|
|
|
response. The @var{packet} should either be a @code{bytes} object, or
|
|
|
|
|
a @code{Unicode} string.
|
|
|
|
|
|
|
|
|
|
If @var{packet} is a @code{Unicode} string, then the string is encoded
|
|
|
|
|
to a @code{bytes} object using the @sc{ascii} codec. If the string
|
|
|
|
|
can't be encoded then an @code{UnicodeError} is raised.
|
|
|
|
|
|
|
|
|
|
If @var{packet} is not a @code{bytes} object, or a @code{Unicode}
|
|
|
|
|
string, then a @code{TypeError} is raised. If @var{packet} is empty
|
|
|
|
|
then a @code{ValueError} is raised.
|
|
|
|
|
|
2023-06-28 09:39:37 -06:00
|
|
|
The response is returned as a @code{bytes} object. If it is known
|
|
|
|
|
that the response can be represented as a string then this can be
|
|
|
|
|
decoded from the buffer. For example, if it is known that the
|
2021-08-31 14:04:36 +01:00
|
|
|
response is an @sc{ascii} string:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
remote_connection.send_packet("some_packet").decode("ascii")
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The prefix, suffix, and checksum (as required by the remote serial
|
|
|
|
|
protocol) are automatically added to the outgoing packet, and removed
|
|
|
|
|
from the incoming packet before the contents of the reply are
|
|
|
|
|
returned.
|
|
|
|
|
|
|
|
|
|
This is equivalent to the @code{maintenance packet} command
|
|
|
|
|
(@pxref{maint packet}).
|
|
|
|
|
@end defun
|
|
|
|
|
|
2020-02-22 11:48:26 -07:00
|
|
|
@node TUI Windows In Python
|
|
|
|
|
@subsubsection Implementing new TUI windows
|
|
|
|
|
@cindex Python TUI Windows
|
|
|
|
|
|
|
|
|
|
New TUI (@pxref{TUI}) windows can be implemented in Python.
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun gdb.register_window_type (name, factory)
|
2020-02-22 11:48:26 -07:00
|
|
|
Because TUI windows are created and destroyed depending on the layout
|
|
|
|
|
the user chooses, new window types are implemented by registering a
|
|
|
|
|
factory function with @value{GDBN}.
|
|
|
|
|
|
|
|
|
|
@var{name} is the name of the new window. It's an error to try to
|
|
|
|
|
replace one of the built-in windows, but other window types can be
|
gdb/python: restrict the names accepted by gdb.register_window_type
I noticed that, from Python, I could register a new TUI window that
had whitespace in its name, like this:
gdb.register_window_type('my window', MyWindowType)
however, it is not possible to then use this window in a new TUI
layout, e.g.:
(gdb) tui new-layout foo my window 1 cmd 1
Unknown window "my"
(gdb) tui new-layout foo "my window" 1 cmd 1
Unknown window ""my"
(gdb) tui new-layout foo my\ window 1 cmd 1
Unknown window "my\"
GDB clearly uses the whitespace to split the incoming command line.
I could fix this by trying to add a mechanism by which we can use
whitespace within a window name, but it seems like an easier solution
if we just forbid whitespace within a window name. Not only is this
easier, but I think this is probably the better solution, identifier
names with spaces in would mean we'd need to audit all the places a
window name could be printed and ensure that the use of a space didn't
make the output ambiguous.
So, having decided to disallow whitespace, I then thought about other
special characters. We currently accept anything as a window name,
and I wondered if this was a good idea.
My concerns were about how special characters used in a window name
might cause confusion, for example, we allow '$' in window names,
which is maybe fine now, but what if one day we wanted to allow
variable expansion when creating new layouts? Or what about starting
a window name with '-'? We already support a '-horizontal' option,
what if we want to add more in the future? Or use of the special
character '{' which has special meaning within a new layout?
In the end I figured it might make sense to place some restrictive
rules in place, and then relax the rules later if/when users complain,
we can consider each relaxation as its requested.
So, I propose that window names should match this regular expression:
[a-zA-Z][-_.a-zA-Z0-9]*
There is a chance that there is user code in the wild which will break
with the addition of this change, but hopefully adapting to the new
restrictions shouldn't be too difficult.
2022-09-14 13:51:28 +01:00
|
|
|
replaced. The @var{name} should match the regular expression
|
|
|
|
|
@code{[a-zA-Z][-_.a-zA-Z0-9]*}, it is an error to try and create a
|
|
|
|
|
window with an invalid name.
|
2020-02-22 11:48:26 -07:00
|
|
|
|
|
|
|
|
@var{function} is a factory function that is called to create the TUI
|
|
|
|
|
window. This is called with a single argument of type
|
|
|
|
|
@code{gdb.TuiWindow}, described below. It should return an object
|
|
|
|
|
that implements the TUI window protocol, also described below.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2020-12-18 18:31:52 +01:00
|
|
|
As mentioned above, when a factory function is called, it is passed
|
2020-02-22 11:48:26 -07:00
|
|
|
an object of type @code{gdb.TuiWindow}. This object has these
|
|
|
|
|
methods and attributes:
|
|
|
|
|
|
|
|
|
|
@defun TuiWindow.is_valid ()
|
|
|
|
|
This method returns @code{True} when this window is valid. When the
|
|
|
|
|
user changes the TUI layout, windows no longer visible in the new
|
|
|
|
|
layout will be destroyed. At this point, the @code{gdb.TuiWindow}
|
|
|
|
|
will no longer be valid, and methods (and attributes) other than
|
|
|
|
|
@code{is_valid} will throw an exception.
|
gdb: return true in TuiWindow.is_valid only if TUI is enabled
If the user implements a TUI window in Python, and this window
responds to GDB events and then redraws its window contents then there
is currently an edge case which can lead to problems.
The Python API documentation suggests that calling methods like erase
or write on a TUI window (from Python code) will raise an exception if
the window is not valid.
And the description for is_valid says:
This method returns True when this window is valid. When the user
changes the TUI layout, windows no longer visible in the new layout
will be destroyed. At this point, the gdb.TuiWindow will no longer
be valid, and methods (and attributes) other than is_valid will
throw an exception.
From this I, as a user, would expect that if I did 'tui disable' to
switch back to CLI mode, then the window would no longer be valid.
However, this is not the case.
When the TUI is disabled the windows in the TUI are not deleted, they
are simply hidden. As such, currently, the is_valid method continues
to return true.
This means that if the users Python code does something like:
def event_handler (e):
global tui_window_object
if tui_window_object->is_valid ():
tui_window_object->erase ()
tui_window_object->write ("Hello World")
gdb.events.stop.connect (event_handler)
Then when a stop event arrives GDB will try to draw the TUI window,
even when the TUI is disabled.
This exposes two bugs. First, is_valid should be returning false in
this case, second, if the user forgot to add the is_valid call, then I
believe the erase and write calls should be throwing an
exception (when the TUI is disabled).
The solution to both of these issues is I think bound together, as it
depends on having a working 'is_valid' check.
There's a rogue assert added into tui-layout.c as part of this
commit. While working on this commit I managed to break GDB such that
TUI_CMD_WIN was nullptr, this was causing GDB to abort. I'm leaving
the assert in as it might help people catch issues in the future.
This patch is inspired by the work done here:
https://sourceware.org/pipermail/gdb-patches/2020-December/174338.html
gdb/ChangeLog:
* python/py-tui.c (gdbpy_tui_window) <is_valid>: New member
function.
(REQUIRE_WINDOW): Call is_valid member function.
(REQUIRE_WINDOW_FOR_SETTER): New define.
(gdbpy_tui_is_valid): Call is_valid member function.
(gdbpy_tui_set_title): Call REQUIRE_WINDOW_FOR_SETTER instead.
* tui/tui-data.h (struct tui_win_info) <is_visible>: Check
tui_active too.
* tui/tui-layout.c (tui_apply_current_layout): Add an assert.
* tui/tui.c (tui_enable): Move setting of tui_active earlier in
the function.
gdb/doc/ChangeLog:
* python.texinfo (TUI Windows In Python): Extend description of
TuiWindow.is_valid.
gdb/testsuite/ChangeLog:
* gdb.python/tui-window-disabled.c: New file.
* gdb.python/tui-window-disabled.exp: New file.
* gdb.python/tui-window-disabled.py: New file.
2021-01-15 10:31:19 +00:00
|
|
|
|
|
|
|
|
When the TUI is disabled using @code{tui disable} (@pxref{TUI
|
|
|
|
|
Commands,,tui disable}) the window is hidden rather than destroyed,
|
|
|
|
|
but @code{is_valid} will still return @code{False} and other methods
|
|
|
|
|
(and attributes) will still throw an exception.
|
2020-02-22 11:48:26 -07:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defvar TuiWindow.width
|
|
|
|
|
This attribute holds the width of the window. It is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar TuiWindow.height
|
|
|
|
|
This attribute holds the height of the window. It is not writable.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar TuiWindow.title
|
|
|
|
|
This attribute holds the window's title, a string. This is normally
|
|
|
|
|
displayed above the window. This attribute can be modified.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defun TuiWindow.erase ()
|
|
|
|
|
Remove all the contents of the window.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun TuiWindow.write (string @r{[}, full_window@r{]})
|
2020-02-22 11:48:26 -07:00
|
|
|
Write @var{string} to the window. @var{string} can contain ANSI
|
|
|
|
|
terminal escape styling sequences; @value{GDBN} will translate these
|
|
|
|
|
as appropriate for the terminal.
|
2020-11-22 16:51:30 +01:00
|
|
|
|
|
|
|
|
If the @var{full_window} parameter is @code{True}, then @var{string}
|
|
|
|
|
contains the full contents of the window. This is similar to calling
|
|
|
|
|
@code{erase} before @code{write}, but avoids the flickering.
|
2020-02-22 11:48:26 -07:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
The factory function that you supply should return an object
|
2024-09-11 08:18:06 -06:00
|
|
|
conforming to the TUI window protocol. These are the methods that can
|
2020-02-22 11:48:26 -07:00
|
|
|
be called on this object, which is referred to below as the ``window
|
|
|
|
|
object''. The methods documented below are optional; if the object
|
|
|
|
|
does not implement one of these methods, @value{GDBN} will not attempt
|
|
|
|
|
to call it. Additional new methods may be added to the window
|
|
|
|
|
protocol in the future. @value{GDBN} guarantees that they will begin
|
|
|
|
|
with a lower-case letter, so you can start implementation methods with
|
|
|
|
|
upper-case letters or underscore to avoid any future conflicts.
|
|
|
|
|
|
|
|
|
|
@defun Window.close ()
|
|
|
|
|
When the TUI window is closed, the @code{gdb.TuiWindow} object will be
|
|
|
|
|
put into an invalid state. At this time, @value{GDBN} will call
|
|
|
|
|
@code{close} method on the window object.
|
|
|
|
|
|
|
|
|
|
After this method is called, @value{GDBN} will discard any references
|
|
|
|
|
it holds on this window object, and will no longer call methods on
|
|
|
|
|
this object.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Window.render ()
|
|
|
|
|
In some situations, a TUI window can change size. For example, this
|
|
|
|
|
can happen if the user resizes the terminal, or changes the layout.
|
|
|
|
|
When this happens, @value{GDBN} will call the @code{render} method on
|
|
|
|
|
the window object.
|
|
|
|
|
|
|
|
|
|
If your window is intended to update in response to changes in the
|
|
|
|
|
inferior, you will probably also want to register event listeners and
|
|
|
|
|
send output to the @code{gdb.TuiWindow}.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Window.hscroll (num)
|
2020-02-22 11:48:26 -07:00
|
|
|
This is a request to scroll the window horizontally. @var{num} is the
|
|
|
|
|
amount by which to scroll, with negative numbers meaning to scroll
|
|
|
|
|
right. In the TUI model, it is the viewport that moves, not the
|
|
|
|
|
contents. A positive argument should cause the viewport to move
|
|
|
|
|
right, and so the content should appear to move to the left.
|
|
|
|
|
@end defun
|
|
|
|
|
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Window.vscroll (num)
|
2020-02-22 11:48:26 -07:00
|
|
|
This is a request to scroll the window vertically. @var{num} is the
|
|
|
|
|
amount by which to scroll, with negative numbers meaning to scroll
|
|
|
|
|
backward. In the TUI model, it is the viewport that moves, not the
|
|
|
|
|
contents. A positive argument should cause the viewport to move down,
|
|
|
|
|
and so the content should appear to move up.
|
|
|
|
|
@end defun
|
|
|
|
|
|
gdb/tui: add 'set tui mouse-events off' to restore mouse selection
Rationale:
I use the mouse with my terminal to select and copy text. In gdb, I use
the mouse to select a function name to set a breakpoint, or a variable
name to print, for example.
When gdb is compiled with ncurses mouse support, gdb's TUI mode
intercepts mouse events. Left-clicking and dragging, which would
normally select text, seems to do nothing. This means I cannot select
text using my mouse anymore. This makes it harder to set breakpoints,
print variables, etc.
Solution:
I tried to fix this issue by editing the 'mousemask' call to only enable
buttons 4 and 5. However, this still caused my terminal (gnome-terminal)
to not allow text to be selected. The only way I could make it work is
by calling 'mousemask (0, NULL);'. But doing so disables the mouse code
entirely, which other people might want.
I therefore decided to make a setting in gdb called 'tui mouse-events'.
If enabled (the default), the behavior is as it is now: terminal mouse
events are given to gdb, disabling the terminal's default behavior.
If disabled (opt-in), the behavior is as it was before the year 2020:
terminal mouse events are not given to gdb, therefore the mouse can be
used to select and copy text.
Notes:
I am not attached to the setting name or its description. Feel free to
suggest better wording.
Testing:
I tested this change in gnome-terminal by performing the following steps
manually:
1. Run: gdb --args ./myprogram
2. Enable TUI: press ctrl-x ctrl-a
3. Click and drag text with the mouse. Observe no selection.
4. Input: set tui mouse-events off
5. Click and drag text with the mouse. Observe that selection works now.
6. Input: set tui mouse-events on.
7. Click and drag text with the mouse. Observe no selection.
2023-01-27 16:19:45 -08:00
|
|
|
@anchor{python-window-click}
|
2023-04-06 08:24:06 -06:00
|
|
|
@defun Window.click (x, y, button)
|
2020-12-20 17:25:09 +01:00
|
|
|
This is called on a mouse click in this window. @var{x} and @var{y} are
|
2022-01-24 10:33:23 +00:00
|
|
|
the mouse coordinates inside the window (0-based, from the top left
|
|
|
|
|
corner), and @var{button} specifies which mouse button was used, whose
|
|
|
|
|
values can be 1 (left), 2 (middle), or 3 (right).
|
gdb/tui: add 'set tui mouse-events off' to restore mouse selection
Rationale:
I use the mouse with my terminal to select and copy text. In gdb, I use
the mouse to select a function name to set a breakpoint, or a variable
name to print, for example.
When gdb is compiled with ncurses mouse support, gdb's TUI mode
intercepts mouse events. Left-clicking and dragging, which would
normally select text, seems to do nothing. This means I cannot select
text using my mouse anymore. This makes it harder to set breakpoints,
print variables, etc.
Solution:
I tried to fix this issue by editing the 'mousemask' call to only enable
buttons 4 and 5. However, this still caused my terminal (gnome-terminal)
to not allow text to be selected. The only way I could make it work is
by calling 'mousemask (0, NULL);'. But doing so disables the mouse code
entirely, which other people might want.
I therefore decided to make a setting in gdb called 'tui mouse-events'.
If enabled (the default), the behavior is as it is now: terminal mouse
events are given to gdb, disabling the terminal's default behavior.
If disabled (opt-in), the behavior is as it was before the year 2020:
terminal mouse events are not given to gdb, therefore the mouse can be
used to select and copy text.
Notes:
I am not attached to the setting name or its description. Feel free to
suggest better wording.
Testing:
I tested this change in gnome-terminal by performing the following steps
manually:
1. Run: gdb --args ./myprogram
2. Enable TUI: press ctrl-x ctrl-a
3. Click and drag text with the mouse. Observe no selection.
4. Input: set tui mouse-events off
5. Click and drag text with the mouse. Observe that selection works now.
6. Input: set tui mouse-events on.
7. Click and drag text with the mouse. Observe no selection.
2023-01-27 16:19:45 -08:00
|
|
|
|
|
|
|
|
When TUI mouse events are disabled by turning off the @code{tui mouse-events}
|
|
|
|
|
setting (@pxref{tui-mouse-events,,set tui mouse-events}), then @code{click} will
|
|
|
|
|
not be called.
|
2020-12-20 17:25:09 +01:00
|
|
|
@end defun
|
|
|
|
|
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
@node Disassembly In Python
|
|
|
|
|
@subsubsection Instruction Disassembly In Python
|
|
|
|
|
@cindex python instruction disassembly
|
|
|
|
|
|
|
|
|
|
@value{GDBN}'s builtin disassembler can be extended, or even replaced,
|
|
|
|
|
using the Python API. The disassembler related features are contained
|
|
|
|
|
within the @code{gdb.disassembler} module:
|
|
|
|
|
|
gdb/python: extend the Python Disassembler API to allow for styling
This commit extends the Python Disassembler API to allow for styling
of the instructions.
Before this commit the Python Disassembler API allowed the user to do
two things:
- They could intercept instruction disassembly requests and return a
string of their choosing, this string then became the disassembled
instruction, or
- They could call builtin_disassemble, which would call back into
libopcode to perform the disassembly. As libopcode printed the
instruction GDB would collect these print requests and build a
string. This string was then returned from the builtin_disassemble
call, and the user could modify or extend this string as needed.
Neither of these approaches allowed for, or preserved, disassembler
styling, which is now available within libopcodes for many of the more
popular architectures GDB supports.
This commit aims to fill this gap. After this commit a user will be
able to do the following things:
- Implement a custom instruction disassembler entirely in Python
without calling back into libopcodes, the custom disassembler will
be able to return styling information such that GDB will display
the instruction fully styled. All of GDB's existing style
settings will affect how instructions coming from the Python
disassembler are displayed in the expected manner.
- Call builtin_disassemble and receive a result that represents how
libopcode would like the instruction styled. The user can then
adjust or extend the disassembled instruction before returning the
result to GDB. Again, the instruction will be styled as expected.
To achieve this I will add two new classes to GDB,
DisassemblerTextPart and DisassemblerAddressPart.
Within builtin_disassemble, instead of capturing the print calls from
libopcodes and building a single string, we will now create either a
text part or address part and store these parts in a vector.
The DisassemblerTextPart will capture a small piece of text along with
the associated style that should be used to display the text. This
corresponds to the disassembler calling
disassemble_info::fprintf_styled_func, or for disassemblers that don't
support styling disassemble_info::fprintf_func.
The DisassemblerAddressPart is used when libopcodes requests that an
address be printed, and takes care of printing the address and
associated symbol, this corresponds to the disassembler calling
disassemble_info::print_address_func.
These parts are then placed within the DisassemblerResult when
builtin_disassemble returns.
Alternatively, the user can directly create parts by calling two new
methods on the DisassembleInfo class: DisassembleInfo.text_part and
DisassembleInfo.address_part.
Having created these parts the user can then pass these parts when
initializing a new DisassemblerResult object.
Finally, when we return from Python to gdbpy_print_insn, one way or
another, the result being returned will have a list of parts. Back in
GDB's C++ code we walk the list of parts and call back into GDB's core
to display the disassembled instruction with the correct styling.
The new API lives in parallel with the old API. Any existing code
that creates a DisassemblerResult using a single string immediately
creates a single DisassemblerTextPart containing the entire
instruction and gives this part the default text style. This is also
what happens if the user calls builtin_disassemble for an architecture
that doesn't (yet) support libopcode styling.
This matches up with what happens when the Python API is not involved,
an architecture without disassembler styling support uses the old
libopcodes printing API (the API that doesn't pass style info), and
GDB just prints everything using the default text style.
The reason that parts are created by calling methods on
DisassembleInfo, rather than calling the class constructor directly,
is DisassemblerAddressPart. Ideally this part would only hold the
address which the part represents, but in order to support backwards
compatibility we need to be able to convert the
DisassemblerAddressPart into a string. To do that we need to call
GDB's internal print_address function, and to do that we need an
gdbarch.
What this means is that the DisassemblerAddressPart needs to take a
gdb.Architecture object at creation time. The only valid place a user
can pull this from is from the DisassembleInfo object, so having the
DisassembleInfo act as a factory ensures that the correct gdbarch is
passed over each time. I implemented both solutions (the one
presented here, and an alternative where parts could be constructed
directly), and this felt like the cleanest solution.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-01-24 15:35:45 +00:00
|
|
|
@anchor{DisassembleInfo Class}
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
@deftp {class} gdb.disassembler.DisassembleInfo
|
|
|
|
|
Disassembly is driven by instances of this class. Each time
|
|
|
|
|
@value{GDBN} needs to disassemble an instruction, an instance of this
|
|
|
|
|
class is created and passed to a registered disassembler. The
|
|
|
|
|
disassembler is then responsible for disassembling an instruction and
|
|
|
|
|
returning a result.
|
|
|
|
|
|
|
|
|
|
Instances of this type are usually created within @value{GDBN},
|
|
|
|
|
however, it is possible to create a copy of an instance of this type,
|
|
|
|
|
see the description of @code{__init__} for more details.
|
|
|
|
|
|
|
|
|
|
This class has the following properties and methods:
|
|
|
|
|
|
|
|
|
|
@defvar DisassembleInfo.address
|
|
|
|
|
A read-only integer containing the address at which @value{GDBN}
|
|
|
|
|
wishes to disassemble a single instruction.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar DisassembleInfo.architecture
|
|
|
|
|
The @code{gdb.Architecture} (@pxref{Architectures In Python}) for
|
|
|
|
|
which @value{GDBN} is currently disassembling, this property is
|
|
|
|
|
read-only.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar DisassembleInfo.progspace
|
|
|
|
|
The @code{gdb.Progspace} (@pxref{Progspaces In Python,,Program Spaces
|
|
|
|
|
In Python}) for which @value{GDBN} is currently disassembling, this
|
|
|
|
|
property is read-only.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defun DisassembleInfo.is_valid ()
|
|
|
|
|
Returns @code{True} if the @code{DisassembleInfo} object is valid,
|
|
|
|
|
@code{False} if not. A @code{DisassembleInfo} object will become
|
|
|
|
|
invalid once the disassembly call for which the @code{DisassembleInfo}
|
|
|
|
|
was created, has returned. Calling other @code{DisassembleInfo}
|
|
|
|
|
methods, or accessing @code{DisassembleInfo} properties, will raise a
|
|
|
|
|
@code{RuntimeError} exception if it is invalid.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun DisassembleInfo.__init__ (info)
|
|
|
|
|
This can be used to create a new @code{DisassembleInfo} object that is
|
|
|
|
|
a copy of @var{info}. The copy will have the same @code{address},
|
|
|
|
|
@code{architecture}, and @code{progspace} values as @var{info}, and
|
|
|
|
|
will become invalid at the same time as @var{info}.
|
|
|
|
|
|
|
|
|
|
This method exists so that sub-classes of @code{DisassembleInfo} can
|
|
|
|
|
be created, these sub-classes must be initialized as copies of an
|
|
|
|
|
existing @code{DisassembleInfo} object, but sub-classes might choose
|
|
|
|
|
to override the @code{read_memory} method, and so control what
|
|
|
|
|
@value{GDBN} sees when reading from memory
|
|
|
|
|
(@pxref{builtin_disassemble}).
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun DisassembleInfo.read_memory (length, offset)
|
|
|
|
|
This method allows the disassembler to read the bytes of the
|
|
|
|
|
instruction to be disassembled. The method reads @var{length} bytes,
|
|
|
|
|
starting at @var{offset} from
|
|
|
|
|
@code{DisassembleInfo.address}.
|
|
|
|
|
|
|
|
|
|
It is important that the disassembler read the instruction bytes using
|
|
|
|
|
this method, rather than reading inferior memory directly, as in some
|
|
|
|
|
cases @value{GDBN} disassembles from an internal buffer rather than
|
|
|
|
|
directly from inferior memory, calling this method handles this
|
|
|
|
|
detail.
|
|
|
|
|
|
|
|
|
|
Returns a buffer object, which behaves much like an array or a string,
|
|
|
|
|
just as @code{Inferior.read_memory} does
|
|
|
|
|
(@pxref{gdbpy_inferior_read_memory,,Inferior.read_memory}). The
|
|
|
|
|
length of the returned buffer will always be exactly @var{length}.
|
|
|
|
|
|
|
|
|
|
If @value{GDBN} is unable to read the required memory then a
|
|
|
|
|
@code{gdb.MemoryError} exception is raised (@pxref{Exception
|
|
|
|
|
Handling}).
|
|
|
|
|
|
|
|
|
|
This method can be overridden by a sub-class in order to control what
|
|
|
|
|
@value{GDBN} sees when reading from memory
|
|
|
|
|
(@pxref{builtin_disassemble}). When overriding this method it is
|
|
|
|
|
important to understand how @code{builtin_disassemble} makes use of
|
|
|
|
|
this method.
|
|
|
|
|
|
|
|
|
|
While disassembling a single instruction there could be multiple calls
|
|
|
|
|
to this method, and the same bytes might be read multiple times. Any
|
|
|
|
|
single call might only read a subset of the total instruction bytes.
|
|
|
|
|
|
|
|
|
|
If an implementation of @code{read_memory} is unable to read the
|
|
|
|
|
requested memory contents, for example, if there's a request to read
|
|
|
|
|
from an invalid memory address, then a @code{gdb.MemoryError} should
|
|
|
|
|
be raised.
|
|
|
|
|
|
|
|
|
|
Raising a @code{MemoryError} inside @code{read_memory} does not
|
|
|
|
|
automatically mean a @code{MemoryError} will be raised by
|
|
|
|
|
@code{builtin_disassemble}. It is possible the @value{GDBN}'s builtin
|
|
|
|
|
disassembler is probing to see how many bytes are available. When
|
|
|
|
|
@code{read_memory} raises the @code{MemoryError} the builtin
|
|
|
|
|
disassembler might be able to perform a complete disassembly with the
|
|
|
|
|
bytes it has available, in this case @code{builtin_disassemble} will
|
|
|
|
|
not itself raise a @code{MemoryError}.
|
|
|
|
|
|
|
|
|
|
Any other exception type raised in @code{read_memory} will propagate
|
2022-10-24 18:04:42 +01:00
|
|
|
back and be re-raised by @code{builtin_disassemble}.
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
@end defun
|
gdb/python: extend the Python Disassembler API to allow for styling
This commit extends the Python Disassembler API to allow for styling
of the instructions.
Before this commit the Python Disassembler API allowed the user to do
two things:
- They could intercept instruction disassembly requests and return a
string of their choosing, this string then became the disassembled
instruction, or
- They could call builtin_disassemble, which would call back into
libopcode to perform the disassembly. As libopcode printed the
instruction GDB would collect these print requests and build a
string. This string was then returned from the builtin_disassemble
call, and the user could modify or extend this string as needed.
Neither of these approaches allowed for, or preserved, disassembler
styling, which is now available within libopcodes for many of the more
popular architectures GDB supports.
This commit aims to fill this gap. After this commit a user will be
able to do the following things:
- Implement a custom instruction disassembler entirely in Python
without calling back into libopcodes, the custom disassembler will
be able to return styling information such that GDB will display
the instruction fully styled. All of GDB's existing style
settings will affect how instructions coming from the Python
disassembler are displayed in the expected manner.
- Call builtin_disassemble and receive a result that represents how
libopcode would like the instruction styled. The user can then
adjust or extend the disassembled instruction before returning the
result to GDB. Again, the instruction will be styled as expected.
To achieve this I will add two new classes to GDB,
DisassemblerTextPart and DisassemblerAddressPart.
Within builtin_disassemble, instead of capturing the print calls from
libopcodes and building a single string, we will now create either a
text part or address part and store these parts in a vector.
The DisassemblerTextPart will capture a small piece of text along with
the associated style that should be used to display the text. This
corresponds to the disassembler calling
disassemble_info::fprintf_styled_func, or for disassemblers that don't
support styling disassemble_info::fprintf_func.
The DisassemblerAddressPart is used when libopcodes requests that an
address be printed, and takes care of printing the address and
associated symbol, this corresponds to the disassembler calling
disassemble_info::print_address_func.
These parts are then placed within the DisassemblerResult when
builtin_disassemble returns.
Alternatively, the user can directly create parts by calling two new
methods on the DisassembleInfo class: DisassembleInfo.text_part and
DisassembleInfo.address_part.
Having created these parts the user can then pass these parts when
initializing a new DisassemblerResult object.
Finally, when we return from Python to gdbpy_print_insn, one way or
another, the result being returned will have a list of parts. Back in
GDB's C++ code we walk the list of parts and call back into GDB's core
to display the disassembled instruction with the correct styling.
The new API lives in parallel with the old API. Any existing code
that creates a DisassemblerResult using a single string immediately
creates a single DisassemblerTextPart containing the entire
instruction and gives this part the default text style. This is also
what happens if the user calls builtin_disassemble for an architecture
that doesn't (yet) support libopcode styling.
This matches up with what happens when the Python API is not involved,
an architecture without disassembler styling support uses the old
libopcodes printing API (the API that doesn't pass style info), and
GDB just prints everything using the default text style.
The reason that parts are created by calling methods on
DisassembleInfo, rather than calling the class constructor directly,
is DisassemblerAddressPart. Ideally this part would only hold the
address which the part represents, but in order to support backwards
compatibility we need to be able to convert the
DisassemblerAddressPart into a string. To do that we need to call
GDB's internal print_address function, and to do that we need an
gdbarch.
What this means is that the DisassemblerAddressPart needs to take a
gdb.Architecture object at creation time. The only valid place a user
can pull this from is from the DisassembleInfo object, so having the
DisassembleInfo act as a factory ensures that the correct gdbarch is
passed over each time. I implemented both solutions (the one
presented here, and an alternative where parts could be constructed
directly), and this felt like the cleanest solution.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-01-24 15:35:45 +00:00
|
|
|
|
|
|
|
|
@defun DisassembleInfo.text_part (style, string)
|
|
|
|
|
Create a new @code{DisassemblerTextPart} representing a piece of a
|
|
|
|
|
disassembled instruction. @var{string} should be a non-empty string,
|
|
|
|
|
and @var{style} should be an appropriate style constant
|
|
|
|
|
(@pxref{Disassembler Style Constants}).
|
|
|
|
|
|
|
|
|
|
Disassembler parts are used when creating a @code{DisassemblerResult}
|
|
|
|
|
in order to represent the styling within an instruction
|
|
|
|
|
(@pxref{DisassemblerResult Class}).
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun DisassembleInfo.address_part (address)
|
|
|
|
|
Create a new @code{DisassemblerAddressPart}. @var{address} is the
|
|
|
|
|
value of the absolute address this part represents. A
|
|
|
|
|
@code{DisassemblerAddressPart} is displayed as an absolute address and
|
|
|
|
|
an associated symbol, the address and symbol are styled appropriately.
|
|
|
|
|
@end defun
|
|
|
|
|
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
@end deftp
|
|
|
|
|
|
2023-03-02 13:10:08 +00:00
|
|
|
@anchor{Disassembler Class}
|
|
|
|
|
@deftp {class} gdb.disassembler.Disassembler
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
This is a base class from which all user implemented disassemblers
|
|
|
|
|
must inherit.
|
|
|
|
|
|
|
|
|
|
@defun Disassembler.__init__ (name)
|
|
|
|
|
The constructor takes @var{name}, a string, which should be a short
|
|
|
|
|
name for this disassembler.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun Disassembler.__call__ (info)
|
|
|
|
|
The @code{__call__} method must be overridden by sub-classes to
|
|
|
|
|
perform disassembly. Calling @code{__call__} on this base class will
|
|
|
|
|
raise a @code{NotImplementedError} exception.
|
|
|
|
|
|
|
|
|
|
The @var{info} argument is an instance of @code{DisassembleInfo}, and
|
|
|
|
|
describes the instruction that @value{GDBN} wants disassembling.
|
|
|
|
|
|
|
|
|
|
If this function returns @code{None}, this indicates to @value{GDBN}
|
|
|
|
|
that this sub-class doesn't wish to disassemble the requested
|
|
|
|
|
instruction. @value{GDBN} will then use its builtin disassembler to
|
|
|
|
|
perform the disassembly.
|
|
|
|
|
|
|
|
|
|
Alternatively, this function can return a @code{DisassemblerResult}
|
|
|
|
|
that represents the disassembled instruction, this type is described
|
|
|
|
|
in more detail below.
|
|
|
|
|
|
|
|
|
|
The @code{__call__} method can raise a @code{gdb.MemoryError}
|
|
|
|
|
exception (@pxref{Exception Handling}) to indicate to @value{GDBN}
|
|
|
|
|
that there was a problem accessing the required memory, this will then
|
|
|
|
|
be displayed by @value{GDBN} within the disassembler output.
|
|
|
|
|
|
|
|
|
|
Ideally, the only three outcomes from invoking @code{__call__} would
|
|
|
|
|
be a return of @code{None}, a successful disassembly returned in a
|
|
|
|
|
@code{DisassemblerResult}, or a @code{MemoryError} indicating that
|
|
|
|
|
there was a problem reading memory.
|
|
|
|
|
|
|
|
|
|
However, as an implementation of @code{__call__} could fail due to
|
|
|
|
|
other reasons, e.g.@: some external resource required to perform
|
|
|
|
|
disassembly is temporarily unavailable, then, if @code{__call__}
|
|
|
|
|
raises a @code{GdbError}, the exception will be converted to a string
|
|
|
|
|
and printed at the end of the disassembly output, the disassembly
|
|
|
|
|
request will then stop.
|
|
|
|
|
|
|
|
|
|
Any other exception type raised by the @code{__call__} method is
|
|
|
|
|
considered an error in the user code, the exception will be printed to
|
|
|
|
|
the error stream according to the @kbd{set python print-stack} setting
|
|
|
|
|
(@pxref{set_python_print_stack,,@kbd{set python print-stack}}).
|
|
|
|
|
@end defun
|
|
|
|
|
@end deftp
|
|
|
|
|
|
gdb/python: extend the Python Disassembler API to allow for styling
This commit extends the Python Disassembler API to allow for styling
of the instructions.
Before this commit the Python Disassembler API allowed the user to do
two things:
- They could intercept instruction disassembly requests and return a
string of their choosing, this string then became the disassembled
instruction, or
- They could call builtin_disassemble, which would call back into
libopcode to perform the disassembly. As libopcode printed the
instruction GDB would collect these print requests and build a
string. This string was then returned from the builtin_disassemble
call, and the user could modify or extend this string as needed.
Neither of these approaches allowed for, or preserved, disassembler
styling, which is now available within libopcodes for many of the more
popular architectures GDB supports.
This commit aims to fill this gap. After this commit a user will be
able to do the following things:
- Implement a custom instruction disassembler entirely in Python
without calling back into libopcodes, the custom disassembler will
be able to return styling information such that GDB will display
the instruction fully styled. All of GDB's existing style
settings will affect how instructions coming from the Python
disassembler are displayed in the expected manner.
- Call builtin_disassemble and receive a result that represents how
libopcode would like the instruction styled. The user can then
adjust or extend the disassembled instruction before returning the
result to GDB. Again, the instruction will be styled as expected.
To achieve this I will add two new classes to GDB,
DisassemblerTextPart and DisassemblerAddressPart.
Within builtin_disassemble, instead of capturing the print calls from
libopcodes and building a single string, we will now create either a
text part or address part and store these parts in a vector.
The DisassemblerTextPart will capture a small piece of text along with
the associated style that should be used to display the text. This
corresponds to the disassembler calling
disassemble_info::fprintf_styled_func, or for disassemblers that don't
support styling disassemble_info::fprintf_func.
The DisassemblerAddressPart is used when libopcodes requests that an
address be printed, and takes care of printing the address and
associated symbol, this corresponds to the disassembler calling
disassemble_info::print_address_func.
These parts are then placed within the DisassemblerResult when
builtin_disassemble returns.
Alternatively, the user can directly create parts by calling two new
methods on the DisassembleInfo class: DisassembleInfo.text_part and
DisassembleInfo.address_part.
Having created these parts the user can then pass these parts when
initializing a new DisassemblerResult object.
Finally, when we return from Python to gdbpy_print_insn, one way or
another, the result being returned will have a list of parts. Back in
GDB's C++ code we walk the list of parts and call back into GDB's core
to display the disassembled instruction with the correct styling.
The new API lives in parallel with the old API. Any existing code
that creates a DisassemblerResult using a single string immediately
creates a single DisassemblerTextPart containing the entire
instruction and gives this part the default text style. This is also
what happens if the user calls builtin_disassemble for an architecture
that doesn't (yet) support libopcode styling.
This matches up with what happens when the Python API is not involved,
an architecture without disassembler styling support uses the old
libopcodes printing API (the API that doesn't pass style info), and
GDB just prints everything using the default text style.
The reason that parts are created by calling methods on
DisassembleInfo, rather than calling the class constructor directly,
is DisassemblerAddressPart. Ideally this part would only hold the
address which the part represents, but in order to support backwards
compatibility we need to be able to convert the
DisassemblerAddressPart into a string. To do that we need to call
GDB's internal print_address function, and to do that we need an
gdbarch.
What this means is that the DisassemblerAddressPart needs to take a
gdb.Architecture object at creation time. The only valid place a user
can pull this from is from the DisassembleInfo object, so having the
DisassembleInfo act as a factory ensures that the correct gdbarch is
passed over each time. I implemented both solutions (the one
presented here, and an alternative where parts could be constructed
directly), and this felt like the cleanest solution.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-01-24 15:35:45 +00:00
|
|
|
@anchor{DisassemblerResult Class}
|
2023-03-02 13:10:08 +00:00
|
|
|
@deftp {class} gdb.disassembler.DisassemblerResult
|
|
|
|
|
This class represents the result of disassembling a single
|
|
|
|
|
instruction. An instance of this class will be returned from
|
|
|
|
|
@code{builtin_disassemble} (@pxref{builtin_disassemble}), and an
|
|
|
|
|
instance of this class should be returned from
|
|
|
|
|
@w{@code{Disassembler.__call__}} (@pxref{Disassembler Class}) if an
|
|
|
|
|
instruction was successfully disassembled.
|
|
|
|
|
|
gdb/python: rework how the disassembler API reads the result object
This commit is a refactor ahead of the next change which will make
disassembler styling available through the Python API.
Unfortunately, in order to make the styling support available, I think
the easiest solution is to make a very small change to the existing
API.
The current API relies on returning a DisassemblerResult object to
represent each disassembled instruction. Currently GDB allows the
DisassemblerResult class to be sub-classed, which could mean that a
user tries to override the various attributes that exist on the
DisassemblerResult object.
This commit removes this ability, effectively making the
DisassemblerResult class final.
Though this is a change to the existing API, I'm hoping this isn't
going to cause too many issues:
- The Python disassembler API was only added in the previous release
of GDB, so I don't expect it to be widely used yet, and
- It's not clear to me why a user would need to sub-class the
DisassemblerResult type, I allowed it in the original patch
because at the time I couldn't see any reason to NOT allow it.
Having prevented sub-classing I can now rework the tail end of the
gdbpy_print_insn function; instead of pulling the results out of the
DisassemblerResult object by calling back into Python, I now cast the
Python object back to its C++ type (disasm_result_object), and access
the fields directly from there. In later commits I will be reworking
the disasm_result_object type in order to hold information about the
styled disassembler output.
The tests that dealt with sub-classing DisassemblerResult have been
removed, and a new test that confirms that DisassemblerResult can't be
sub-classed has been added.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-01-23 15:31:28 +00:00
|
|
|
It is not possible to sub-class the @code{DisassemblerResult} class.
|
|
|
|
|
|
2023-03-02 13:10:08 +00:00
|
|
|
The @code{DisassemblerResult} class has the following properties and
|
|
|
|
|
methods:
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
|
gdb/python: extend the Python Disassembler API to allow for styling
This commit extends the Python Disassembler API to allow for styling
of the instructions.
Before this commit the Python Disassembler API allowed the user to do
two things:
- They could intercept instruction disassembly requests and return a
string of their choosing, this string then became the disassembled
instruction, or
- They could call builtin_disassemble, which would call back into
libopcode to perform the disassembly. As libopcode printed the
instruction GDB would collect these print requests and build a
string. This string was then returned from the builtin_disassemble
call, and the user could modify or extend this string as needed.
Neither of these approaches allowed for, or preserved, disassembler
styling, which is now available within libopcodes for many of the more
popular architectures GDB supports.
This commit aims to fill this gap. After this commit a user will be
able to do the following things:
- Implement a custom instruction disassembler entirely in Python
without calling back into libopcodes, the custom disassembler will
be able to return styling information such that GDB will display
the instruction fully styled. All of GDB's existing style
settings will affect how instructions coming from the Python
disassembler are displayed in the expected manner.
- Call builtin_disassemble and receive a result that represents how
libopcode would like the instruction styled. The user can then
adjust or extend the disassembled instruction before returning the
result to GDB. Again, the instruction will be styled as expected.
To achieve this I will add two new classes to GDB,
DisassemblerTextPart and DisassemblerAddressPart.
Within builtin_disassemble, instead of capturing the print calls from
libopcodes and building a single string, we will now create either a
text part or address part and store these parts in a vector.
The DisassemblerTextPart will capture a small piece of text along with
the associated style that should be used to display the text. This
corresponds to the disassembler calling
disassemble_info::fprintf_styled_func, or for disassemblers that don't
support styling disassemble_info::fprintf_func.
The DisassemblerAddressPart is used when libopcodes requests that an
address be printed, and takes care of printing the address and
associated symbol, this corresponds to the disassembler calling
disassemble_info::print_address_func.
These parts are then placed within the DisassemblerResult when
builtin_disassemble returns.
Alternatively, the user can directly create parts by calling two new
methods on the DisassembleInfo class: DisassembleInfo.text_part and
DisassembleInfo.address_part.
Having created these parts the user can then pass these parts when
initializing a new DisassemblerResult object.
Finally, when we return from Python to gdbpy_print_insn, one way or
another, the result being returned will have a list of parts. Back in
GDB's C++ code we walk the list of parts and call back into GDB's core
to display the disassembled instruction with the correct styling.
The new API lives in parallel with the old API. Any existing code
that creates a DisassemblerResult using a single string immediately
creates a single DisassemblerTextPart containing the entire
instruction and gives this part the default text style. This is also
what happens if the user calls builtin_disassemble for an architecture
that doesn't (yet) support libopcode styling.
This matches up with what happens when the Python API is not involved,
an architecture without disassembler styling support uses the old
libopcodes printing API (the API that doesn't pass style info), and
GDB just prints everything using the default text style.
The reason that parts are created by calling methods on
DisassembleInfo, rather than calling the class constructor directly,
is DisassemblerAddressPart. Ideally this part would only hold the
address which the part represents, but in order to support backwards
compatibility we need to be able to convert the
DisassemblerAddressPart into a string. To do that we need to call
GDB's internal print_address function, and to do that we need an
gdbarch.
What this means is that the DisassemblerAddressPart needs to take a
gdb.Architecture object at creation time. The only valid place a user
can pull this from is from the DisassembleInfo object, so having the
DisassembleInfo act as a factory ensures that the correct gdbarch is
passed over each time. I implemented both solutions (the one
presented here, and an alternative where parts could be constructed
directly), and this felt like the cleanest solution.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-01-24 15:35:45 +00:00
|
|
|
@defun DisassemblerResult.__init__ (length, string, parts)
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
Initialize an instance of this class, @var{length} is the length of
|
|
|
|
|
the disassembled instruction in bytes, which must be greater than
|
gdb/python: extend the Python Disassembler API to allow for styling
This commit extends the Python Disassembler API to allow for styling
of the instructions.
Before this commit the Python Disassembler API allowed the user to do
two things:
- They could intercept instruction disassembly requests and return a
string of their choosing, this string then became the disassembled
instruction, or
- They could call builtin_disassemble, which would call back into
libopcode to perform the disassembly. As libopcode printed the
instruction GDB would collect these print requests and build a
string. This string was then returned from the builtin_disassemble
call, and the user could modify or extend this string as needed.
Neither of these approaches allowed for, or preserved, disassembler
styling, which is now available within libopcodes for many of the more
popular architectures GDB supports.
This commit aims to fill this gap. After this commit a user will be
able to do the following things:
- Implement a custom instruction disassembler entirely in Python
without calling back into libopcodes, the custom disassembler will
be able to return styling information such that GDB will display
the instruction fully styled. All of GDB's existing style
settings will affect how instructions coming from the Python
disassembler are displayed in the expected manner.
- Call builtin_disassemble and receive a result that represents how
libopcode would like the instruction styled. The user can then
adjust or extend the disassembled instruction before returning the
result to GDB. Again, the instruction will be styled as expected.
To achieve this I will add two new classes to GDB,
DisassemblerTextPart and DisassemblerAddressPart.
Within builtin_disassemble, instead of capturing the print calls from
libopcodes and building a single string, we will now create either a
text part or address part and store these parts in a vector.
The DisassemblerTextPart will capture a small piece of text along with
the associated style that should be used to display the text. This
corresponds to the disassembler calling
disassemble_info::fprintf_styled_func, or for disassemblers that don't
support styling disassemble_info::fprintf_func.
The DisassemblerAddressPart is used when libopcodes requests that an
address be printed, and takes care of printing the address and
associated symbol, this corresponds to the disassembler calling
disassemble_info::print_address_func.
These parts are then placed within the DisassemblerResult when
builtin_disassemble returns.
Alternatively, the user can directly create parts by calling two new
methods on the DisassembleInfo class: DisassembleInfo.text_part and
DisassembleInfo.address_part.
Having created these parts the user can then pass these parts when
initializing a new DisassemblerResult object.
Finally, when we return from Python to gdbpy_print_insn, one way or
another, the result being returned will have a list of parts. Back in
GDB's C++ code we walk the list of parts and call back into GDB's core
to display the disassembled instruction with the correct styling.
The new API lives in parallel with the old API. Any existing code
that creates a DisassemblerResult using a single string immediately
creates a single DisassemblerTextPart containing the entire
instruction and gives this part the default text style. This is also
what happens if the user calls builtin_disassemble for an architecture
that doesn't (yet) support libopcode styling.
This matches up with what happens when the Python API is not involved,
an architecture without disassembler styling support uses the old
libopcodes printing API (the API that doesn't pass style info), and
GDB just prints everything using the default text style.
The reason that parts are created by calling methods on
DisassembleInfo, rather than calling the class constructor directly,
is DisassemblerAddressPart. Ideally this part would only hold the
address which the part represents, but in order to support backwards
compatibility we need to be able to convert the
DisassemblerAddressPart into a string. To do that we need to call
GDB's internal print_address function, and to do that we need an
gdbarch.
What this means is that the DisassemblerAddressPart needs to take a
gdb.Architecture object at creation time. The only valid place a user
can pull this from is from the DisassembleInfo object, so having the
DisassembleInfo act as a factory ensures that the correct gdbarch is
passed over each time. I implemented both solutions (the one
presented here, and an alternative where parts could be constructed
directly), and this felt like the cleanest solution.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-01-24 15:35:45 +00:00
|
|
|
zero.
|
|
|
|
|
|
|
|
|
|
Only one of @var{string} or @var{parts} should be used to initialize a
|
|
|
|
|
new @code{DisassemblerResult}; the other one should be passed the
|
|
|
|
|
value @code{None}. Alternatively, the arguments can be passed by
|
|
|
|
|
name, and the unused argument can be ignored.
|
|
|
|
|
|
|
|
|
|
The @var{string} argument, if not @code{None}, is a non-empty string
|
|
|
|
|
that represents the entire disassembled instruction. Building a result
|
|
|
|
|
object using the @var{string} argument does not allow for any styling
|
|
|
|
|
information to be included in the result. @value{GDBN} will style the
|
|
|
|
|
result as a single @code{DisassemblerTextPart} with @code{STYLE_TEXT}
|
|
|
|
|
style (@pxref{Disassembler Styling Parts}).
|
|
|
|
|
|
|
|
|
|
The @var{parts} argument, if not @code{None}, is a non-empty sequence
|
|
|
|
|
of @code{DisassemblerPart} objects. Each part represents a small part
|
|
|
|
|
of the disassembled instruction along with associated styling
|
|
|
|
|
information. A result object built using @var{parts} can be displayed
|
|
|
|
|
by @value{GDBN} with full styling information
|
|
|
|
|
(@pxref{style_disassembler_enabled,,@kbd{set style disassembler
|
|
|
|
|
enabled}}).
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defvar DisassemblerResult.length
|
|
|
|
|
A read-only property containing the length of the disassembled
|
|
|
|
|
instruction in bytes, this will always be greater than zero.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar DisassemblerResult.string
|
|
|
|
|
A read-only property containing a non-empty string representing the
|
gdb/python: extend the Python Disassembler API to allow for styling
This commit extends the Python Disassembler API to allow for styling
of the instructions.
Before this commit the Python Disassembler API allowed the user to do
two things:
- They could intercept instruction disassembly requests and return a
string of their choosing, this string then became the disassembled
instruction, or
- They could call builtin_disassemble, which would call back into
libopcode to perform the disassembly. As libopcode printed the
instruction GDB would collect these print requests and build a
string. This string was then returned from the builtin_disassemble
call, and the user could modify or extend this string as needed.
Neither of these approaches allowed for, or preserved, disassembler
styling, which is now available within libopcodes for many of the more
popular architectures GDB supports.
This commit aims to fill this gap. After this commit a user will be
able to do the following things:
- Implement a custom instruction disassembler entirely in Python
without calling back into libopcodes, the custom disassembler will
be able to return styling information such that GDB will display
the instruction fully styled. All of GDB's existing style
settings will affect how instructions coming from the Python
disassembler are displayed in the expected manner.
- Call builtin_disassemble and receive a result that represents how
libopcode would like the instruction styled. The user can then
adjust or extend the disassembled instruction before returning the
result to GDB. Again, the instruction will be styled as expected.
To achieve this I will add two new classes to GDB,
DisassemblerTextPart and DisassemblerAddressPart.
Within builtin_disassemble, instead of capturing the print calls from
libopcodes and building a single string, we will now create either a
text part or address part and store these parts in a vector.
The DisassemblerTextPart will capture a small piece of text along with
the associated style that should be used to display the text. This
corresponds to the disassembler calling
disassemble_info::fprintf_styled_func, or for disassemblers that don't
support styling disassemble_info::fprintf_func.
The DisassemblerAddressPart is used when libopcodes requests that an
address be printed, and takes care of printing the address and
associated symbol, this corresponds to the disassembler calling
disassemble_info::print_address_func.
These parts are then placed within the DisassemblerResult when
builtin_disassemble returns.
Alternatively, the user can directly create parts by calling two new
methods on the DisassembleInfo class: DisassembleInfo.text_part and
DisassembleInfo.address_part.
Having created these parts the user can then pass these parts when
initializing a new DisassemblerResult object.
Finally, when we return from Python to gdbpy_print_insn, one way or
another, the result being returned will have a list of parts. Back in
GDB's C++ code we walk the list of parts and call back into GDB's core
to display the disassembled instruction with the correct styling.
The new API lives in parallel with the old API. Any existing code
that creates a DisassemblerResult using a single string immediately
creates a single DisassemblerTextPart containing the entire
instruction and gives this part the default text style. This is also
what happens if the user calls builtin_disassemble for an architecture
that doesn't (yet) support libopcode styling.
This matches up with what happens when the Python API is not involved,
an architecture without disassembler styling support uses the old
libopcodes printing API (the API that doesn't pass style info), and
GDB just prints everything using the default text style.
The reason that parts are created by calling methods on
DisassembleInfo, rather than calling the class constructor directly,
is DisassemblerAddressPart. Ideally this part would only hold the
address which the part represents, but in order to support backwards
compatibility we need to be able to convert the
DisassemblerAddressPart into a string. To do that we need to call
GDB's internal print_address function, and to do that we need an
gdbarch.
What this means is that the DisassemblerAddressPart needs to take a
gdb.Architecture object at creation time. The only valid place a user
can pull this from is from the DisassembleInfo object, so having the
DisassembleInfo act as a factory ensures that the correct gdbarch is
passed over each time. I implemented both solutions (the one
presented here, and an alternative where parts could be constructed
directly), and this felt like the cleanest solution.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-01-24 15:35:45 +00:00
|
|
|
disassembled instruction. The @var{string} is a representation of the
|
|
|
|
|
disassembled instruction without any styling information. To see how
|
|
|
|
|
the instruction will be styled use the @var{parts} property.
|
|
|
|
|
|
|
|
|
|
If this instance was initialized using separate
|
|
|
|
|
@code{DisassemblerPart} objects, the @var{string} property will still
|
|
|
|
|
be valid. The @var{string} value is created by concatenating the
|
|
|
|
|
@code{DisassemblerPart.string} values of each component part
|
|
|
|
|
(@pxref{Disassembler Styling Parts}).
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar DisassemblerResult.parts
|
|
|
|
|
A read-only property containing a non-empty sequence of
|
|
|
|
|
@code{DisassemblerPart} objects. Each @code{DisassemblerPart} object
|
|
|
|
|
contains a small part of the instruction along with information about
|
|
|
|
|
how that part should be styled. @value{GDBN} uses this information to
|
|
|
|
|
create styled disassembler output
|
|
|
|
|
(@pxref{style_disassembler_enabled,,@kbd{set style disassembler
|
|
|
|
|
enabled}}).
|
|
|
|
|
|
|
|
|
|
If this instance was initialized using a single string rather than
|
|
|
|
|
with a sequence of @code{DisassemblerPart} objects, the @var{parts}
|
|
|
|
|
property will still be valid. In this case the @var{parts} property
|
|
|
|
|
will hold a sequence containing a single @code{DisassemblerTextPart}
|
|
|
|
|
object, the string of which will represent the entire instruction, and
|
|
|
|
|
the style of which will be @code{STYLE_TEXT}.
|
|
|
|
|
@end defvar
|
|
|
|
|
@end deftp
|
|
|
|
|
|
|
|
|
|
@anchor{Disassembler Styling Parts}
|
|
|
|
|
@deftp {class} gdb.disassembler.DisassemblerPart
|
|
|
|
|
This is a parent class from which the different part sub-classes
|
|
|
|
|
inherit. Only instances of the sub-classes detailed below will be
|
|
|
|
|
returned by the Python API.
|
|
|
|
|
|
|
|
|
|
It is not possible to directly create instances of either this parent
|
|
|
|
|
class, or any of the sub-classes listed below. Instances of the
|
|
|
|
|
sub-classes listed below are created by calling
|
|
|
|
|
@code{builtin_disassemble} (@pxref{builtin_disassemble}) and are
|
|
|
|
|
returned within the @code{DisassemblerResult} object, or can be
|
|
|
|
|
created by calling the @code{text_part} and @code{address_part}
|
|
|
|
|
methods on the @code{DisassembleInfo} class (@pxref{DisassembleInfo
|
|
|
|
|
Class}).
|
|
|
|
|
|
|
|
|
|
The @code{DisassemblerPart} class has a single property:
|
|
|
|
|
|
|
|
|
|
@defvar DisassemblerPart.string
|
|
|
|
|
A read-only property that contains a non-empty string representing
|
|
|
|
|
this part of the disassembled instruction. The string within this
|
|
|
|
|
property doesn't include any styling information.
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
@end defvar
|
|
|
|
|
@end deftp
|
|
|
|
|
|
gdb/python: extend the Python Disassembler API to allow for styling
This commit extends the Python Disassembler API to allow for styling
of the instructions.
Before this commit the Python Disassembler API allowed the user to do
two things:
- They could intercept instruction disassembly requests and return a
string of their choosing, this string then became the disassembled
instruction, or
- They could call builtin_disassemble, which would call back into
libopcode to perform the disassembly. As libopcode printed the
instruction GDB would collect these print requests and build a
string. This string was then returned from the builtin_disassemble
call, and the user could modify or extend this string as needed.
Neither of these approaches allowed for, or preserved, disassembler
styling, which is now available within libopcodes for many of the more
popular architectures GDB supports.
This commit aims to fill this gap. After this commit a user will be
able to do the following things:
- Implement a custom instruction disassembler entirely in Python
without calling back into libopcodes, the custom disassembler will
be able to return styling information such that GDB will display
the instruction fully styled. All of GDB's existing style
settings will affect how instructions coming from the Python
disassembler are displayed in the expected manner.
- Call builtin_disassemble and receive a result that represents how
libopcode would like the instruction styled. The user can then
adjust or extend the disassembled instruction before returning the
result to GDB. Again, the instruction will be styled as expected.
To achieve this I will add two new classes to GDB,
DisassemblerTextPart and DisassemblerAddressPart.
Within builtin_disassemble, instead of capturing the print calls from
libopcodes and building a single string, we will now create either a
text part or address part and store these parts in a vector.
The DisassemblerTextPart will capture a small piece of text along with
the associated style that should be used to display the text. This
corresponds to the disassembler calling
disassemble_info::fprintf_styled_func, or for disassemblers that don't
support styling disassemble_info::fprintf_func.
The DisassemblerAddressPart is used when libopcodes requests that an
address be printed, and takes care of printing the address and
associated symbol, this corresponds to the disassembler calling
disassemble_info::print_address_func.
These parts are then placed within the DisassemblerResult when
builtin_disassemble returns.
Alternatively, the user can directly create parts by calling two new
methods on the DisassembleInfo class: DisassembleInfo.text_part and
DisassembleInfo.address_part.
Having created these parts the user can then pass these parts when
initializing a new DisassemblerResult object.
Finally, when we return from Python to gdbpy_print_insn, one way or
another, the result being returned will have a list of parts. Back in
GDB's C++ code we walk the list of parts and call back into GDB's core
to display the disassembled instruction with the correct styling.
The new API lives in parallel with the old API. Any existing code
that creates a DisassemblerResult using a single string immediately
creates a single DisassemblerTextPart containing the entire
instruction and gives this part the default text style. This is also
what happens if the user calls builtin_disassemble for an architecture
that doesn't (yet) support libopcode styling.
This matches up with what happens when the Python API is not involved,
an architecture without disassembler styling support uses the old
libopcodes printing API (the API that doesn't pass style info), and
GDB just prints everything using the default text style.
The reason that parts are created by calling methods on
DisassembleInfo, rather than calling the class constructor directly,
is DisassemblerAddressPart. Ideally this part would only hold the
address which the part represents, but in order to support backwards
compatibility we need to be able to convert the
DisassemblerAddressPart into a string. To do that we need to call
GDB's internal print_address function, and to do that we need an
gdbarch.
What this means is that the DisassemblerAddressPart needs to take a
gdb.Architecture object at creation time. The only valid place a user
can pull this from is from the DisassembleInfo object, so having the
DisassembleInfo act as a factory ensures that the correct gdbarch is
passed over each time. I implemented both solutions (the one
presented here, and an alternative where parts could be constructed
directly), and this felt like the cleanest solution.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
2023-01-24 15:35:45 +00:00
|
|
|
@deftp {class} gdb.disassembler.DisassemblerTextPart
|
|
|
|
|
The @code{DisassemblerTextPart} class represents a piece of the
|
|
|
|
|
disassembled instruction and the associated style for that piece.
|
|
|
|
|
Instances of this class can't be created directly, instead call
|
|
|
|
|
@code{DisassembleInfo.text_part} to create a new instance of this
|
|
|
|
|
class (@pxref{DisassembleInfo Class}).
|
|
|
|
|
|
|
|
|
|
As well as the properties of its parent class, the
|
|
|
|
|
@code{DisassemblerTextPart} has the following additional property:
|
|
|
|
|
|
|
|
|
|
@defvar DisassemblerTextPart.style
|
|
|
|
|
A read-only property that contains one of the defined style constants.
|
|
|
|
|
@value{GDBN} will use this style when styling this part of the
|
|
|
|
|
disassembled instruction (@pxref{Disassembler Style Constants}).
|
|
|
|
|
@end defvar
|
|
|
|
|
@end deftp
|
|
|
|
|
|
|
|
|
|
@deftp {class} gdb.disassembler.DisassemblerAddressPart
|
|
|
|
|
The @code{DisassemblerAddressPart} class represents an absolute
|
|
|
|
|
address within a disassembled instruction. Using a
|
|
|
|
|
@code{DisassemblerAddressPart} instead of a
|
|
|
|
|
@code{DisassemblerTextPart} with @code{STYLE_ADDRESS} is preferred,
|
|
|
|
|
@value{GDBN} will display the address as both an absolute address, and
|
|
|
|
|
will look up a suitable symbol to display next to the address. Using
|
|
|
|
|
@code{DisassemblerAddressPart} also ensures that user settings such as
|
|
|
|
|
@code{set print max-symbolic-offset} are respected.
|
|
|
|
|
|
|
|
|
|
Here is an example of an x86-64 instruction:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
call 0x401136 <foo>
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
In this instruction the @code{0x401136 <foo>} was generated from a
|
|
|
|
|
single @code{DisassemblerAddressPart}. The @code{0x401136} will be
|
|
|
|
|
styled with @code{STYLE_ADDRESS}, and @code{foo} will be styled with
|
|
|
|
|
@code{STYLE_SYMBOL}. The @code{<} and @code{>} will be styled as
|
|
|
|
|
@code{STYLE_TEXT}.
|
|
|
|
|
|
|
|
|
|
If the inclusion of the symbol name is not required then a
|
|
|
|
|
@code{DisassemblerTextPart} with style @code{STYLE_ADDRESS} can be
|
|
|
|
|
used instead.
|
|
|
|
|
|
|
|
|
|
Instances of this class can't be created directly, instead call
|
|
|
|
|
@code{DisassembleInfo.address_part} to create a new instance of this
|
|
|
|
|
class (@pxref{DisassembleInfo Class}).
|
|
|
|
|
|
|
|
|
|
As well as the properties of its parent class, the
|
|
|
|
|
@code{DisassemblerAddressPart} has the following additional property:
|
|
|
|
|
|
|
|
|
|
@defvar DisassemblerAddressPart.address
|
|
|
|
|
A read-only property that contains the @var{address} passed to this
|
|
|
|
|
object's @code{__init__} method.
|
|
|
|
|
@end defvar
|
|
|
|
|
@end deftp
|
|
|
|
|
|
|
|
|
|
@anchor{Disassembler Style Constants}
|
|
|
|
|
|
|
|
|
|
The following table lists all of the disassembler styles that are
|
|
|
|
|
available. @value{GDBN} maps these style constants onto its style
|
|
|
|
|
settings (@pxref{Output Styling}). In some cases, several style
|
|
|
|
|
constants produce the same style settings, and thus will produce the
|
|
|
|
|
same visual effect on the screen. This could change in future
|
|
|
|
|
releases of @value{GDBN}, so care should be taken to select the
|
|
|
|
|
correct style constant to ensure correct output styling in future
|
|
|
|
|
releases of @value{GDBN}.
|
|
|
|
|
|
|
|
|
|
@vtable @code
|
|
|
|
|
@vindex STYLE_TEXT
|
|
|
|
|
@item gdb.disassembler.STYLE_TEXT
|
|
|
|
|
This is the default style used by @value{GDBN} when styling
|
|
|
|
|
disassembler output. This style should be used for any parts of the
|
|
|
|
|
instruction that don't fit any of the other styles listed below.
|
|
|
|
|
@value{GDBN} styles text with this style using its default style.
|
|
|
|
|
|
|
|
|
|
@vindex STYLE_MNEMONIC
|
|
|
|
|
@item gdb.disassembler.STYLE_MNEMONIC
|
|
|
|
|
This style is used for styling the primary instruction mnemonic, which
|
|
|
|
|
usually appears at, or near, the start of the disassembled instruction
|
|
|
|
|
string.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} styles text with this style using the @code{disassembler
|
|
|
|
|
mnemonic} style setting.
|
|
|
|
|
|
|
|
|
|
@vindex STYLE_SUB_MNEMONIC
|
|
|
|
|
@item gdb.disassembler.STYLE_SUB_MNEMONIC
|
|
|
|
|
This style is used for styling any sub-mnemonics within a disassembled
|
|
|
|
|
instruction. A sub-mnemonic is any text within the instruction that
|
|
|
|
|
controls the function of the instruction, but which is disjoint from
|
|
|
|
|
the primary mnemonic (which will have styled @code{STYLE_MNEMONIC}).
|
|
|
|
|
|
|
|
|
|
As an example, consider this AArch64 instruction:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
add w16, w7, w1, lsl #1
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
The @code{add} is the primary instruction mnemonic, and would be given
|
|
|
|
|
style @code{STYLE_MNEMONIC}, while @code{lsl} is the sub-mnemonic, and
|
|
|
|
|
would be given the style @code{STYLE_SUB_MNEMONIC}.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} styles text with this style using the @code{disassembler
|
|
|
|
|
mnemonic} style setting.
|
|
|
|
|
|
|
|
|
|
@vindex STYLE_ASSEMBLER_DIRECTIVE
|
|
|
|
|
@item gdb.disassembler.STYLE_ASSEMBLER_DIRECTIVE
|
|
|
|
|
Sometimes a series of bytes doesn't decode to a valid instruction. In
|
|
|
|
|
this case the disassembler may choose to represent the result of
|
|
|
|
|
disassembling using an assembler directive, for example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
.word 0x1234
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
In this case, the @code{.word} would be give the
|
|
|
|
|
@code{STYLE_ASSEMBLER_DIRECTIVE} style. An assembler directive is
|
|
|
|
|
similar to a mnemonic in many ways but is something that is not part
|
|
|
|
|
of the architecture's instruction set.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} styles text with this style using the @code{disassembler
|
|
|
|
|
mnemonic} style setting.
|
|
|
|
|
|
|
|
|
|
@vindex STYLE_REGISTER
|
|
|
|
|
@item gdb.disassembler.STYLE_REGISTER
|
|
|
|
|
This style is used for styling any text that represents a register
|
|
|
|
|
name, or register number, within a disassembled instruction.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} styles text with this style using the @code{disassembler
|
|
|
|
|
register} style setting.
|
|
|
|
|
|
|
|
|
|
@vindex STYLE_ADDRESS
|
|
|
|
|
@item gdb.disassembler.STYLE_ADDRESS
|
|
|
|
|
This style is used for styling numerical values that represent
|
|
|
|
|
absolute addresses within the disassembled instruction.
|
|
|
|
|
|
|
|
|
|
When creating a @code{DisassemblerTextPart} with this style, you
|
|
|
|
|
should consider if a @code{DisassemblerAddressPart} would be more
|
|
|
|
|
appropriate. See @ref{Disassembler Styling Parts} for a description
|
|
|
|
|
of what each part offers.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} styles text with this style using the @code{disassembler
|
|
|
|
|
address} style setting.
|
|
|
|
|
|
|
|
|
|
@vindex STYLE_ADDRESS_OFFSET
|
|
|
|
|
@item gdb.disassembler.STYLE_ADDRESS_OFFSET
|
|
|
|
|
This style is used for styling numerical values that represent offsets
|
|
|
|
|
to addresses within the disassembled instruction. A value is
|
|
|
|
|
considered an address offset when the instruction itself is going to
|
|
|
|
|
access memory, and the value is being used to offset which address is
|
|
|
|
|
accessed.
|
|
|
|
|
|
|
|
|
|
For example, an architecture might have an instruction that loads from
|
|
|
|
|
memory using an address within a register. If that instruction also
|
|
|
|
|
allowed for an immediate offset to be encoded into the instruction,
|
|
|
|
|
this would be an address offset. Similarly, a branch instruction
|
|
|
|
|
might jump to an address in a register plus an address offset that is
|
|
|
|
|
encoded into the instruction.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} styles text with this style using the @code{disassembler
|
|
|
|
|
immediate} style setting.
|
|
|
|
|
|
|
|
|
|
@vindex STYLE_IMMEDIATE
|
|
|
|
|
@item gdb.disassembler.STYLE_IMMEDIATE
|
|
|
|
|
Use @code{STYLE_IMMEDIATE} for any numerical values within a
|
|
|
|
|
disassembled instruction when those values are not addresses, address
|
|
|
|
|
offsets, or register numbers (The styles @code{STYLE_ADDRESS},
|
|
|
|
|
@code{STYLE_ADDRESS_OFFSET}, or @code{STYLE_REGISTER} can be used in
|
|
|
|
|
those cases).
|
|
|
|
|
|
|
|
|
|
@value{GDBN} styles text with this style using the @code{disassembler
|
|
|
|
|
immediate} style setting.
|
|
|
|
|
|
|
|
|
|
@vindex STYLE_SYMBOL
|
|
|
|
|
@item gdb.disassembler.STYLE_SYMBOL
|
|
|
|
|
This style is used for styling the textual name of a symbol that is
|
|
|
|
|
included within a disassembled instruction. A symbol name is often
|
|
|
|
|
included next to an absolute address within a disassembled instruction
|
|
|
|
|
to make it easier for the user to understand what the address is
|
|
|
|
|
referring too. For example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
call 0x401136 <foo>
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
Here @code{foo} is the name of a symbol, and should be given the
|
|
|
|
|
@code{STYLE_SYMBOL} style.
|
|
|
|
|
|
|
|
|
|
Adding symbols next to absolute addresses like this is handled
|
|
|
|
|
automatically by the @code{DisassemblerAddressPart} class
|
|
|
|
|
(@pxref{Disassembler Styling Parts}).
|
|
|
|
|
|
|
|
|
|
@value{GDBN} styles text with this style using the @code{disassembler
|
|
|
|
|
symbol} style setting.
|
|
|
|
|
|
|
|
|
|
@vindex STYLE_COMMENT_START
|
|
|
|
|
@item gdb.disassembler.STYLE_COMMENT_START
|
|
|
|
|
This style is used to start a line comment in the disassembly output.
|
|
|
|
|
Unlike other styles, which only apply to the single
|
|
|
|
|
@code{DisassemblerTextPiece} to which they are applied, the comment
|
|
|
|
|
style is sticky, and overrides the style of any further pieces within
|
|
|
|
|
this instruction.
|
|
|
|
|
|
|
|
|
|
This means that, after a @code{STYLE_COMMENT_START} piece has been
|
|
|
|
|
seen, @value{GDBN} will apply the comment style until the end of the
|
|
|
|
|
line, ignoring the specific style within a piece.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} styles text with this style using the @code{disassembler
|
|
|
|
|
comment} style setting.
|
|
|
|
|
@end vtable
|
|
|
|
|
|
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2021-09-17 18:12:34 +01:00
|
|
|
The following functions are also contained in the
|
|
|
|
|
@code{gdb.disassembler} module:
|
|
|
|
|
|
|
|
|
|
@defun register_disassembler (disassembler, architecture)
|
|
|
|
|
The @var{disassembler} must be a sub-class of
|
|
|
|
|
@code{gdb.disassembler.Disassembler} or @code{None}.
|
|
|
|
|
|
|
|
|
|
The optional @var{architecture} is either a string, or the value
|
|
|
|
|
@code{None}. If it is a string, then it should be the name of an
|
|
|
|
|
architecture known to @value{GDBN}, as returned either from
|
|
|
|
|
@code{gdb.Architecture.name}
|
|
|
|
|
(@pxref{gdbpy_architecture_name,,gdb.Architecture.name}), or from
|
|
|
|
|
@code{gdb.architecture_names}
|
|
|
|
|
(@pxref{gdb_architecture_names,,gdb.architecture_names}).
|
|
|
|
|
|
|
|
|
|
The @var{disassembler} will be installed for the architecture named by
|
|
|
|
|
@var{architecture}, or if @var{architecture} is @code{None}, then
|
|
|
|
|
@var{disassembler} will be installed as a global disassembler for use
|
|
|
|
|
by all architectures.
|
|
|
|
|
|
|
|
|
|
@cindex disassembler in Python, global vs.@: specific
|
|
|
|
|
@cindex search order for disassembler in Python
|
|
|
|
|
@cindex look up of disassembler in Python
|
|
|
|
|
@value{GDBN} only records a single disassembler for each architecture,
|
|
|
|
|
and a single global disassembler. Calling
|
|
|
|
|
@code{register_disassembler} for an architecture, or for the global
|
|
|
|
|
disassembler, will replace any existing disassembler registered for
|
|
|
|
|
that @var{architecture} value. The previous disassembler is returned.
|
|
|
|
|
|
|
|
|
|
If @var{disassembler} is @code{None} then any disassembler currently
|
|
|
|
|
registered for @var{architecture} is deregistered and returned.
|
|
|
|
|
|
|
|
|
|
When @value{GDBN} is looking for a disassembler to use, @value{GDBN}
|
|
|
|
|
first looks for an architecture specific disassembler. If none has
|
|
|
|
|
been registered then @value{GDBN} looks for a global disassembler (one
|
|
|
|
|
registered with @var{architecture} set to @code{None}). Only one
|
|
|
|
|
disassembler is called to perform disassembly, so, if there is both an
|
|
|
|
|
architecture specific disassembler, and a global disassembler
|
|
|
|
|
registered, it is the architecture specific disassembler that will be
|
|
|
|
|
used.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} tracks the architecture specific, and global
|
|
|
|
|
disassemblers separately, so it doesn't matter in which order
|
|
|
|
|
disassemblers are created or registered; an architecture specific
|
|
|
|
|
disassembler, if present, will always be used in preference to a
|
|
|
|
|
global disassembler.
|
|
|
|
|
|
|
|
|
|
You can use the @kbd{maint info python-disassemblers} command
|
|
|
|
|
(@pxref{maint info python-disassemblers}) to see which disassemblers
|
|
|
|
|
have been registered.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@anchor{builtin_disassemble}
|
|
|
|
|
@defun builtin_disassemble (info)
|
|
|
|
|
This function calls back into @value{GDBN}'s builtin disassembler to
|
|
|
|
|
disassemble the instruction identified by @var{info}, an instance, or
|
|
|
|
|
sub-class, of @code{DisassembleInfo}.
|
|
|
|
|
|
|
|
|
|
When the builtin disassembler needs to read memory the
|
|
|
|
|
@code{read_memory} method on @var{info} will be called. By
|
|
|
|
|
sub-classing @code{DisassembleInfo} and overriding the
|
|
|
|
|
@code{read_memory} method, it is possible to intercept calls to
|
|
|
|
|
@code{read_memory} from the builtin disassembler, and to modify the
|
|
|
|
|
values returned.
|
|
|
|
|
|
|
|
|
|
It is important to understand that, even when
|
|
|
|
|
@code{DisassembleInfo.read_memory} raises a @code{gdb.MemoryError}, it
|
|
|
|
|
is the internal disassembler itself that reports the memory error to
|
|
|
|
|
@value{GDBN}. The reason for this is that the disassembler might
|
|
|
|
|
probe memory to see if a byte is readable or not; if the byte can't be
|
|
|
|
|
read then the disassembler may choose not to report an error, but
|
|
|
|
|
instead to disassemble the bytes that it does have available.
|
|
|
|
|
|
|
|
|
|
If the builtin disassembler is successful then an instance of
|
|
|
|
|
@code{DisassemblerResult} is returned from @code{builtin_disassemble},
|
|
|
|
|
alternatively, if something goes wrong, an exception will be raised.
|
|
|
|
|
|
|
|
|
|
A @code{MemoryError} will be raised if @code{builtin_disassemble} is
|
|
|
|
|
unable to read some memory that is required in order to perform
|
|
|
|
|
disassembly correctly.
|
|
|
|
|
|
|
|
|
|
Any exception that is not a @code{MemoryError}, that is raised in a
|
|
|
|
|
call to @code{read_memory}, will pass through
|
|
|
|
|
@code{builtin_disassemble}, and be visible to the caller.
|
|
|
|
|
|
|
|
|
|
Finally, there are a few cases where @value{GDBN}'s builtin
|
|
|
|
|
disassembler can fail for reasons that are not covered by
|
|
|
|
|
@code{MemoryError}. In these cases, a @code{GdbError} will be raised.
|
|
|
|
|
The contents of the exception will be a string describing the problem
|
|
|
|
|
the disassembler encountered.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
Here is an example that registers a global disassembler. The new
|
|
|
|
|
disassembler invokes the builtin disassembler, and then adds a
|
|
|
|
|
comment, @code{## Comment}, to each line of disassembly output:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class ExampleDisassembler(gdb.disassembler.Disassembler):
|
|
|
|
|
def __init__(self):
|
|
|
|
|
super().__init__("ExampleDisassembler")
|
|
|
|
|
|
|
|
|
|
def __call__(self, info):
|
|
|
|
|
result = gdb.disassembler.builtin_disassemble(info)
|
|
|
|
|
length = result.length
|
|
|
|
|
text = result.string + "\t## Comment"
|
|
|
|
|
return gdb.disassembler.DisassemblerResult(length, text)
|
|
|
|
|
|
|
|
|
|
gdb.disassembler.register_disassembler(ExampleDisassembler())
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The following example creates a sub-class of @code{DisassembleInfo} in
|
|
|
|
|
order to intercept the @code{read_memory} calls, within
|
|
|
|
|
@code{read_memory} any bytes read from memory have the two 4-bit
|
|
|
|
|
nibbles swapped around. This isn't a very useful adjustment, but
|
|
|
|
|
serves as an example.
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
class MyInfo(gdb.disassembler.DisassembleInfo):
|
|
|
|
|
def __init__(self, info):
|
|
|
|
|
super().__init__(info)
|
|
|
|
|
|
|
|
|
|
def read_memory(self, length, offset):
|
|
|
|
|
buffer = super().read_memory(length, offset)
|
|
|
|
|
result = bytearray()
|
|
|
|
|
for b in buffer:
|
|
|
|
|
v = int.from_bytes(b, 'little')
|
|
|
|
|
v = (v << 4) & 0xf0 | (v >> 4)
|
|
|
|
|
result.append(v)
|
|
|
|
|
return memoryview(result)
|
|
|
|
|
|
|
|
|
|
class NibbleSwapDisassembler(gdb.disassembler.Disassembler):
|
|
|
|
|
def __init__(self):
|
|
|
|
|
super().__init__("NibbleSwapDisassembler")
|
|
|
|
|
|
|
|
|
|
def __call__(self, info):
|
|
|
|
|
info = MyInfo(info)
|
|
|
|
|
return gdb.disassembler.builtin_disassemble(info)
|
|
|
|
|
|
|
|
|
|
gdb.disassembler.register_disassembler(NibbleSwapDisassembler())
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
gdb: implement missing debug handler hook for Python
This commit builds on the previous commit, and implements the
extension_language_ops::handle_missing_debuginfo function for Python.
This hook will give user supplied Python code a chance to help find
missing debug information.
The implementation of the new hook is pretty minimal within GDB's C++
code; most of the work is out-sourced to a Python implementation which
is modelled heavily on how GDB's Python frame unwinders are
implemented.
The following new commands are added as commands implemented in
Python, this is similar to how the Python unwinder commands are
implemented:
info missing-debug-handlers
enable missing-debug-handler LOCUS HANDLER
disable missing-debug-handler LOCUS HANDLER
To make use of this extension hook a user will create missing debug
information handler objects, and registers these handlers with GDB.
When GDB encounters an objfile that is missing debug information, each
handler is called in turn until one is able to help. Here is a
minimal handler that does nothing useful:
import gdb
import gdb.missing_debug
class MyFirstHandler(gdb.missing_debug.MissingDebugHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, objfile):
# This handler does nothing useful.
return None
gdb.missing_debug.register_handler(None, MyFirstHandler())
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing debug information, and GDB should ask
any other registered handlers.
By extending the __call__ method it is possible for the Python
extension to locate the debug information for objfile and return a
value that tells GDB how to use the information that has been located.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the debug information
for the objfile still couldn't be found. GDB will not call
any other handlers, and will continue without the debug
information for objfile.
- True: The handler has installed the debug information into a
location where GDB would normally expect to find it. GDB
should look again for the debug information.
- A string: The handler can return a filename, which is the file
containing the missing debug information. GDB will load
this file.
When a handler returns True, GDB will look again for the debug
information, but only using the standard built-in build-id and
.gnu_debuglink based lookup strategies. It is not possible for an
extension to trigger another debuginfod lookup; the assumption is that
the debuginfod server is remote, and out of the control of extensions
running within GDB.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the objfile, at which point GDB continues.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
2023-10-15 22:48:42 +01:00
|
|
|
@node Missing Debug Info In Python
|
|
|
|
|
@subsubsection Missing Debug Info In Python
|
|
|
|
|
@cindex python, handle missing debug information
|
|
|
|
|
|
|
|
|
|
When @value{GDBN} encounters a new objfile (@pxref{Objfiles In
|
|
|
|
|
Python}), e.g.@: the primary executable, or any shared libraries used
|
|
|
|
|
by the inferior, @value{GDBN} will attempt to load the corresponding
|
|
|
|
|
debug information for that objfile. The debug information might be
|
|
|
|
|
found within the objfile itself, or within a separate objfile which
|
|
|
|
|
@value{GDBN} will automatically locate and load.
|
|
|
|
|
|
|
|
|
|
Sometimes though, @value{GDBN} might not find any debug information
|
|
|
|
|
for an objfile, in this case the debugging experience will be
|
|
|
|
|
restricted.
|
|
|
|
|
|
|
|
|
|
If @value{GDBN} fails to locate any debug information for a particular
|
|
|
|
|
objfile, there is an opportunity for a Python extension to step in. A
|
|
|
|
|
Python extension can potentially locate the missing debug information
|
|
|
|
|
using some platform- or project-specific steps, and inform
|
|
|
|
|
@value{GDBN} of its location. Or a Python extension might provide
|
|
|
|
|
some platform- or project-specific advice to the user about how to
|
|
|
|
|
obtain the missing debug information.
|
|
|
|
|
|
|
|
|
|
A missing debug information Python extension consists of a handler
|
|
|
|
|
object which has the @code{name} and @code{enabled} attributes, and
|
|
|
|
|
implements the @code{__call__} method. When @value{GDBN} encounters
|
|
|
|
|
an objfile for which it is unable to find any debug information, it
|
|
|
|
|
invokes the @code{__call__} method. Full details of how handlers are
|
|
|
|
|
written can be found below.
|
|
|
|
|
|
|
|
|
|
@subheading The @code{gdb.missing_debug} Module
|
|
|
|
|
|
|
|
|
|
@value{GDBN} comes with a @code{gdb.missing_debug} module which
|
|
|
|
|
contains the following class and global function:
|
|
|
|
|
|
|
|
|
|
@deftp{class} gdb.missing_debug.MissingDebugHandler
|
|
|
|
|
|
|
|
|
|
@code{MissingDebugHandler} is a base class from which user-created
|
|
|
|
|
handlers can derive, though it is not required that handlers derive
|
|
|
|
|
from this class, so long as any user created handler has the
|
|
|
|
|
@code{name} and @code{enabled} attributes, and implements the
|
|
|
|
|
@code{__call__} method.
|
|
|
|
|
|
|
|
|
|
@defun MissingDebugHandler.__init__ (name)
|
|
|
|
|
The @var{name} is a string used to reference this missing debug
|
|
|
|
|
handler within some @value{GDBN} commands. Valid names consist of the
|
|
|
|
|
characters @code{[-_a-zA-Z0-9]}, creating a handler with an invalid
|
|
|
|
|
name raises a @code{ValueError} exception.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun MissingDebugHandler.__call__ (objfile)
|
|
|
|
|
Sub-classes must override the @code{__call__} method. The
|
|
|
|
|
@var{objfile} argument will be a @code{gdb.Objfile}, this is the
|
|
|
|
|
objfile for which @value{GDBN} was unable to find any debug
|
|
|
|
|
information.
|
|
|
|
|
|
|
|
|
|
The return value from the @code{__call__} method indicates what
|
|
|
|
|
@value{GDBN} should do next. The possible return values are:
|
|
|
|
|
|
|
|
|
|
@itemize @bullet
|
|
|
|
|
@item @code{None}
|
|
|
|
|
|
|
|
|
|
This indicates that this handler could not help with @var{objfile},
|
|
|
|
|
@value{GDBN} should call any other registered handlers.
|
|
|
|
|
|
|
|
|
|
@item @code{True}
|
|
|
|
|
|
|
|
|
|
This indicates that this handler has installed the debug information
|
|
|
|
|
into a location where @value{GDBN} would normally expect to find it
|
|
|
|
|
when looking for separate debug information files (@pxref{Separate
|
|
|
|
|
Debug Files}). @value{GDBN} will repeat the normal lookup process,
|
|
|
|
|
which should now find the separate debug file.
|
|
|
|
|
|
|
|
|
|
If @value{GDBN} still doesn't find the separate debug information file
|
|
|
|
|
after this second attempt, then the Python missing debug information
|
|
|
|
|
handlers are not invoked a second time, this prevents a badly behaved
|
|
|
|
|
handler causing @value{GDBN} to get stuck in a loop. @value{GDBN}
|
|
|
|
|
will continue without any debug information for @var{objfile}.
|
|
|
|
|
|
|
|
|
|
@item @code{False}
|
|
|
|
|
|
|
|
|
|
This indicates that this handler has done everything that it intends
|
|
|
|
|
to do with @var{objfile}, but no separate debug information can be
|
|
|
|
|
found. @value{GDBN} will not call any other registered handlers for
|
|
|
|
|
@var{objfile}. @value{GDBN} will continue without debugging
|
|
|
|
|
information for @var{objfile}.
|
|
|
|
|
|
|
|
|
|
@item A string
|
|
|
|
|
|
|
|
|
|
The returned string should contain a filename. @value{GDBN} will not
|
|
|
|
|
call any further registered handlers, and will instead load the debug
|
|
|
|
|
information from the file identified by the returned filename.
|
|
|
|
|
@end itemize
|
|
|
|
|
|
|
|
|
|
Invoking the @code{__call__} method from this base class will raise a
|
|
|
|
|
@code{NotImplementedError} exception.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defvar MissingDebugHandler.name
|
|
|
|
|
A read-only attribute which is a string, the name of this handler
|
|
|
|
|
passed to the @code{__init__} method.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar MissingDebugHandler.enabled
|
|
|
|
|
A modifiable attribute containing a boolean; when @code{True}, the
|
|
|
|
|
handler is enabled, and will be used by @value{GDBN}. When
|
|
|
|
|
@code{False}, the handler has been disabled, and will not be used.
|
|
|
|
|
@end defvar
|
|
|
|
|
@end deftp
|
|
|
|
|
|
|
|
|
|
@defun gdb.missing_debug.register_handler (locus, handler, replace=@code{False})
|
|
|
|
|
Register a new missing debug handler with @value{GDBN}.
|
|
|
|
|
|
|
|
|
|
@var{handler} is an instance of a sub-class of
|
|
|
|
|
@code{MissingDebugHandler}, or at least an instance of an object that
|
|
|
|
|
has the same attributes and methods as @code{MissingDebugHandler}.
|
|
|
|
|
|
|
|
|
|
@var{locus} specifies to which handler list to prepend @var{handler}.
|
|
|
|
|
It can be either a @code{gdb.Progspace} (@pxref{Progspaces In Python})
|
|
|
|
|
or @code{None}, in which case the handler is registered globally. The
|
|
|
|
|
newly registered @var{handler} will be called before any other handler
|
|
|
|
|
from the same locus. Two handlers in the same locus cannot have the
|
|
|
|
|
same name, an attempt to add a handler with an already existing name
|
|
|
|
|
raises an exception unless @var{replace} is @code{True}, in which case
|
|
|
|
|
the old handler is deleted and the new handler is prepended to the
|
|
|
|
|
selected handler list.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} first calls the handlers for the current program space,
|
|
|
|
|
and then the globally registered handlers. As soon as a handler
|
|
|
|
|
returns a value other than @code{None}, no further handlers are called
|
|
|
|
|
for this objfile.
|
|
|
|
|
@end defun
|
|
|
|
|
|
gdb/python: implement Python find_exec_by_build_id hook
Implement extension_language_ops::find_objfile_from_buildid within
GDB's Python API. Doing this allows users to write Python extensions
that can help locate missing objfiles when GDB opens a core file. A
handler might perform some project- or site-specific actions to find a
missing objfile. Or might provide some project- or site-specific
advice to the user on how they can obtain the missing objfile.
The implementation is very similar to the approach taken in:
commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416
Date: Sun Oct 15 22:48:42 2023 +0100
gdb: implement missing debug handler hook for Python
The following new commands are added as commands implemented in
Python, this is similar to how the Python missing debug and unwinder
commands are implemented:
info missing-objfile-handlers
enable missing-objfile-handler LOCUS HANDLER
disable missing-objfile-handler LOCUS HANDLER
To make use of this extension hook a user will create missing objfile
handler objects, and registers these handlers with GDB. When GDB
opens a core file and encounters a missing objfile each handler is
called in turn until one is able to help. Here is a minimal handler
that does nothing useful:
import gdb
import gdb.missing_objfile
class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, pspace, build_id, filename):
# This handler does nothing useful.
return None
gdb.missing_objfile.register_handler(None, MyFirstHandler())
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing objfile, and GDB should ask any other
registered handlers.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the objfile couldn't
be found. GDB will not call any other handlers, and will
continue without the objfile.
- True: The handler has installed the objfile into a location where
GDB would normally expect to find it. GDB should repeat its
normal lookup process and the objfile should now be found.
- A string: The handler can return a filename, which is the missing
objfile. GDB will load this file.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the missing objfile, at which point GDB continues.
The implementation of this feature is mostly straight forward. I have
reworked some of the missing debug file related code so that it can be
shared with this feature. E.g. gdb/python/lib/gdb/missing_files.py is
mostly content moved from gdb/python/lib/gdb/missing_debug.py, but
updated to be more generic. Now gdb/python/lib/gdb/missing_debug.py
and the new file gdb/python/lib/gdb/missing_objfile.py both call into
the missing_files.py file.
For gdb/python/lib/gdb/command/missing_files.py this is even more
extreme, gdb/python/lib/gdb/command/missing_debug.py is completely
gone now and gdb/python/lib/gdb/command/missing_files.py provides all
of the new commands in a generic way.
I have made one change to the existing Python API, I renamed the
attribute Progspace.missing_debug_handlers to
Progspace.missing_file_handlers. I don't see this as too
problematic. This attribute was only used to implement the missing
debug feature and was never documented beyond the fact that it
existed. There was no reason for users to be touching this attribute.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-07-31 15:55:57 +01:00
|
|
|
@node Missing Objfiles In Python
|
|
|
|
|
@subsubsection Missing Objfiles In Python
|
|
|
|
|
@cindex python, handle missing objfiles
|
|
|
|
|
|
|
|
|
|
When @value{GDBN} opens a core file, for example with the
|
|
|
|
|
@kbd{core-file} command (@pxref{core-file command}), @value{GDBN} will
|
|
|
|
|
attempt to load the corresponding executable and shared libraries.
|
|
|
|
|
Often these files can be found on the local machine, but sometimes
|
|
|
|
|
these files cannot be found, in which case the debugging experience
|
|
|
|
|
will be restricted.
|
|
|
|
|
|
|
|
|
|
If @value{GDBN} fails to locate a particular file then there is an
|
|
|
|
|
opportunity for a Python extension to step in. A Python extension can
|
|
|
|
|
potentially locate the missing file using some platform- or
|
|
|
|
|
project-specific steps, and inform @value{GDBN} of its location. Or a
|
|
|
|
|
Python extension might provide some platform- or project-specific
|
|
|
|
|
advice to the user about how to obtain the missing file.
|
|
|
|
|
|
|
|
|
|
A missing-objfile Python extension consists of a handler object which
|
|
|
|
|
has the @code{name} and @code{enabled} attributes, and implements the
|
|
|
|
|
@code{__call__} method. When @value{GDBN} encounters a situation
|
|
|
|
|
where a file cannot be found, but the build-id (@pxref{build ID}) for
|
|
|
|
|
the missing file is known, then the @code{__call__} method is invoked
|
|
|
|
|
to try and find the file. Full details of how handlers are written
|
|
|
|
|
can be found below.
|
|
|
|
|
|
|
|
|
|
@subheading The @code{gdb.missing_objfile} Module
|
|
|
|
|
|
|
|
|
|
@value{GDBN} comes with a @code{gdb.missing_objfile} module which
|
|
|
|
|
contains the following class and global function:
|
|
|
|
|
|
|
|
|
|
@deftp{class} gdb.missing_objfile.MissingObjfileHandler
|
|
|
|
|
|
|
|
|
|
@code{MissingObjfileHandler} is a base class from which user-created
|
|
|
|
|
handlers can derive, though it is not required that handlers derive
|
|
|
|
|
from this class, so long as any user created handler has the
|
|
|
|
|
@code{name} and @code{enabled} attributes, and implements the
|
|
|
|
|
@code{__call__} method.
|
|
|
|
|
|
|
|
|
|
@defun MissingObjfileHandler.__init__ (name)
|
|
|
|
|
The @var{name} is a string used to reference this missing-objfile
|
|
|
|
|
handler within some @value{GDBN} commands. Valid names consist of the
|
|
|
|
|
characters @samp{[-_a-zA-Z0-9]}, creating a handler with an invalid
|
|
|
|
|
name raises a @code{ValueError} exception.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defun MissingObjfileHandler.__call__ (pspace, build_id, filename)
|
|
|
|
|
|
|
|
|
|
Sub-classes must override the @code{__call__} method. The
|
|
|
|
|
@var{pspace} argument will be a @code{gdb.Progspace}
|
|
|
|
|
(@pxref{Progspaces In Python}), this is the program space in which
|
|
|
|
|
@value{GDBN} is looking for the missing file.
|
|
|
|
|
|
|
|
|
|
The @var{build_id} argument is a string containing the build-id of the
|
|
|
|
|
file that is missing, this will be in the same format as returned by
|
|
|
|
|
@code{Objfile.build_id} (@pxref{Objfile.build_id}).
|
|
|
|
|
|
|
|
|
|
The @var{filename} argument contains the name of the file that
|
|
|
|
|
@value{GDBN} is looking for. This information is provided to allow
|
|
|
|
|
handlers to generate informative messages for the user. A handler is
|
|
|
|
|
not required to place the missing file at this location. There might
|
|
|
|
|
already be a file present at this location, but it might not match the
|
|
|
|
|
required build-id, in which case @value{GDBN} will have ignored it.
|
|
|
|
|
In some limited cases @value{GDBN} might not be able to establish the
|
|
|
|
|
@var{filename} of the file it is searching for, in this case
|
|
|
|
|
@value{GDBN} will use a string @samp{with build-id @var{build_id}} as a
|
|
|
|
|
replacement.
|
|
|
|
|
|
|
|
|
|
The return value from the @code{__call__} method indicates what
|
|
|
|
|
@value{GDBN} should do next. The possible return values are:
|
|
|
|
|
|
|
|
|
|
@itemize @bullet
|
|
|
|
|
@item @code{None}
|
|
|
|
|
|
|
|
|
|
This indicates that this handler could not locate the missing file and
|
|
|
|
|
@value{GDBN} should call any other registered handlers.
|
|
|
|
|
|
|
|
|
|
@item @code{True}
|
|
|
|
|
|
|
|
|
|
This indicates that this handler has installed the missing file into a
|
|
|
|
|
location where @value{GDBN} would normally expect to find it. The
|
|
|
|
|
only location in which @value{GDBN} will look is within the
|
|
|
|
|
@file{.build-id} sub-directory within the @var{debug-file-directory}
|
|
|
|
|
(@pxref{debug-file-directory}).
|
|
|
|
|
|
|
|
|
|
@value{GDBN} will repeat the normal lookup process, which should now
|
|
|
|
|
find the previously missing file.
|
|
|
|
|
|
|
|
|
|
If @value{GDBN} still doesn't find file after this second attempt,
|
|
|
|
|
then the Python missing-objfile handlers are not invoked a second
|
|
|
|
|
time, this prevents a badly behaved handler causing @value{GDBN} to
|
|
|
|
|
get stuck in a loop. @value{GDBN} will continue without the missing
|
|
|
|
|
file, though this will degrade the debugging experience.
|
|
|
|
|
|
|
|
|
|
@item @code{False}
|
|
|
|
|
|
|
|
|
|
This indicates that this handler has done everything that it intends
|
|
|
|
|
to do but the missing file could not be found. @value{GDBN} will not
|
|
|
|
|
call any other registered handlers to look for the missing file.
|
|
|
|
|
@value{GDBN} will continue without the missing file, though this will
|
|
|
|
|
degrade the debugging experience.
|
|
|
|
|
|
|
|
|
|
@item A string
|
|
|
|
|
|
|
|
|
|
The returned string should contain a filename. @value{GDBN} will not
|
|
|
|
|
call any further registered handlers, and will instead use the
|
|
|
|
|
returned filename as the missing file.
|
|
|
|
|
@end itemize
|
|
|
|
|
|
|
|
|
|
Invoking the @code{__call__} method from this base class will raise a
|
|
|
|
|
@code{NotImplementedError} exception.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@defvar MissingObjfileHandler.name
|
|
|
|
|
A read-only attribute which is a string, the name of this handler
|
|
|
|
|
passed to the @code{__init__} method.
|
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
|
|
@defvar MissingObjfileHandler.enabled
|
|
|
|
|
A modifiable attribute containing a boolean; when @code{True}, the
|
|
|
|
|
handler is enabled, and will be used by @value{GDBN}. When
|
|
|
|
|
@code{False}, the handler has been disabled, and will not be used.
|
|
|
|
|
@end defvar
|
|
|
|
|
@end deftp
|
|
|
|
|
|
|
|
|
|
@defun gdb.missing_objfile.register_handler (locus, handler, replace=@code{False})
|
|
|
|
|
Register a new missing-objfile handler with @value{GDBN}.
|
|
|
|
|
|
|
|
|
|
@var{handler} is an instance of a sub-class of
|
|
|
|
|
@code{MissingObjfileHandler}, or at least an instance of an object that
|
|
|
|
|
has the same attributes and methods as @code{MissingObjfileHandler}.
|
|
|
|
|
|
|
|
|
|
@var{locus} specifies to which handler list to prepend @var{handler}.
|
|
|
|
|
It can be either a @code{gdb.Progspace} (@pxref{Progspaces In Python})
|
|
|
|
|
or @code{None}, in which case the handler is registered globally. The
|
|
|
|
|
newly registered @var{handler} will be called before any other handler
|
|
|
|
|
from the same locus. Two handlers in the same locus cannot have the
|
|
|
|
|
same name, an attempt to add a handler with an already existing name
|
|
|
|
|
raises an exception unless @var{replace} is @code{True}, in which case
|
|
|
|
|
the old handler is deleted and the new handler is prepended to the
|
|
|
|
|
selected handler list.
|
|
|
|
|
|
|
|
|
|
@value{GDBN} first calls the handlers for the current program space,
|
|
|
|
|
and then the globally registered handlers. As soon as a handler
|
|
|
|
|
returns a value other than @code{None}, no further handlers are
|
|
|
|
|
called.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@subheading Managing Missing-Objfile Handlers
|
|
|
|
|
|
|
|
|
|
@value{GDBN} defines the following commands to manage registered
|
|
|
|
|
missing-objfile handlers:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
|
|
|
|
|
@kindex info missing-objfile-handlers
|
|
|
|
|
@item info missing-objfile-handlers @r{[} @var{locus} @r{[} @var{name-regexp} @r{]} @r{]}
|
|
|
|
|
Lists all registered missing-objfile handlers. Arguments @var{locus}
|
|
|
|
|
and @var{name-regexp} are both optional and can be used to filter
|
|
|
|
|
which handlers are listed.
|
|
|
|
|
|
|
|
|
|
The @var{locus} argument should be either @kbd{global},
|
|
|
|
|
@kbd{progspace}, or the name of an object file. Only handlers
|
|
|
|
|
registered for the specified locus will be listed.
|
|
|
|
|
|
|
|
|
|
The @var{name-regexp} is a regular expression used to match against
|
|
|
|
|
handler names.
|
|
|
|
|
|
|
|
|
|
@kindex disable missing-objfile-handler
|
|
|
|
|
@item disable missing-objfile-handler @r{[} @var{locus} @r{[} @var{name-regexp} @r{]} @r{]}
|
|
|
|
|
The @var{locus} and @var{name-regexp} are interpreted as in @kbd{info
|
|
|
|
|
missing-objfile-handlers} above, but instead of listing the matching
|
|
|
|
|
handlers, all of the matching handlers are disabled. The
|
|
|
|
|
@code{enabled} field of each matching handler is set to @code{False}.
|
|
|
|
|
|
|
|
|
|
@kindex enable missing-objfile-handler
|
|
|
|
|
@item enable missing-objfile-handler @r{[} @var{locus} @r{[} @var{name-regexp} @r{]} @r{]}
|
|
|
|
|
The @var{locus} and @var{name-regexp} are interpreted as in @kbd{info
|
|
|
|
|
missing-objfile-handlers} above, but instead of listing the matching
|
|
|
|
|
handlers, all of the matching handlers are enabled. The
|
|
|
|
|
@code{enabled} field of each matching handler is set to @code{True}.
|
|
|
|
|
@end table
|
|
|
|
|
|
2014-02-17 10:35:03 -08:00
|
|
|
@node Python Auto-loading
|
|
|
|
|
@subsection Python Auto-loading
|
|
|
|
|
@cindex Python auto-loading
|
|
|
|
|
|
|
|
|
|
When a new object file is read (for example, due to the @code{file}
|
|
|
|
|
command, or because the inferior has loaded a shared library),
|
|
|
|
|
@value{GDBN} will look for Python support scripts in several ways:
|
|
|
|
|
@file{@var{objfile}-gdb.py} and @code{.debug_gdb_scripts} section.
|
|
|
|
|
@xref{Auto-loading extensions}.
|
|
|
|
|
|
|
|
|
|
The auto-loading feature is useful for supplying application-specific
|
|
|
|
|
debugging commands and scripts.
|
|
|
|
|
|
|
|
|
|
Auto-loading can be enabled or disabled,
|
|
|
|
|
and the list of auto-loaded scripts can be printed.
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@anchor{set auto-load python-scripts}
|
|
|
|
|
@kindex set auto-load python-scripts
|
|
|
|
|
@item set auto-load python-scripts [on|off]
|
|
|
|
|
Enable or disable the auto-loading of Python scripts.
|
|
|
|
|
|
|
|
|
|
@anchor{show auto-load python-scripts}
|
|
|
|
|
@kindex show auto-load python-scripts
|
|
|
|
|
@item show auto-load python-scripts
|
|
|
|
|
Show whether auto-loading of Python scripts is enabled or disabled.
|
|
|
|
|
|
|
|
|
|
@anchor{info auto-load python-scripts}
|
|
|
|
|
@kindex info auto-load python-scripts
|
|
|
|
|
@cindex print list of auto-loaded Python scripts
|
|
|
|
|
@item info auto-load python-scripts [@var{regexp}]
|
|
|
|
|
Print the list of all Python scripts that @value{GDBN} auto-loaded.
|
|
|
|
|
|
|
|
|
|
Also printed is the list of Python scripts that were mentioned in
|
2015-01-31 12:01:13 -08:00
|
|
|
the @code{.debug_gdb_scripts} section and were either not found
|
|
|
|
|
(@pxref{dotdebug_gdb_scripts section}) or were not auto-loaded due to
|
|
|
|
|
@code{auto-load safe-path} rejection (@pxref{Auto-loading}).
|
2014-02-17 10:35:03 -08:00
|
|
|
This is useful because their names are not printed when @value{GDBN}
|
|
|
|
|
tries to load them and fails. There may be many of them, and printing
|
|
|
|
|
an error message for each one is problematic.
|
|
|
|
|
|
|
|
|
|
If @var{regexp} is supplied only Python scripts with matching names are printed.
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(gdb) info auto-load python-scripts
|
|
|
|
|
Loaded Script
|
|
|
|
|
Yes py-section-script.py
|
|
|
|
|
full name: /tmp/py-section-script.py
|
|
|
|
|
No my-foo-pretty-printers.py
|
|
|
|
|
@end smallexample
|
|
|
|
|
@end table
|
|
|
|
|
|
2015-01-31 12:01:13 -08:00
|
|
|
When reading an auto-loaded file or script, @value{GDBN} sets the
|
2014-02-17 10:35:03 -08:00
|
|
|
@dfn{current objfile}. This is available via the @code{gdb.current_objfile}
|
|
|
|
|
function (@pxref{Objfiles In Python}). This can be useful for
|
|
|
|
|
registering objfile-specific pretty-printers and frame-filters.
|
|
|
|
|
|
|
|
|
|
@node Python modules
|
|
|
|
|
@subsection Python modules
|
|
|
|
|
@cindex python modules
|
|
|
|
|
|
|
|
|
|
@value{GDBN} comes with several modules to assist writing Python code.
|
|
|
|
|
|
|
|
|
|
@menu
|
|
|
|
|
* gdb.printing:: Building and registering pretty-printers.
|
|
|
|
|
* gdb.types:: Utilities for working with types.
|
|
|
|
|
* gdb.prompt:: Utilities for prompt value substitution.
|
2019-02-18 15:50:49 +01:00
|
|
|
* gdb.ptwrite:: Utilities for PTWRITE filter registration.
|
2014-02-17 10:35:03 -08:00
|
|
|
@end menu
|
|
|
|
|
|
|
|
|
|
@node gdb.printing
|
|
|
|
|
@subsubsection gdb.printing
|
|
|
|
|
@cindex gdb.printing
|
|
|
|
|
|
|
|
|
|
This module provides a collection of utilities for working with
|
|
|
|
|
pretty-printers.
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@item PrettyPrinter (@var{name}, @var{subprinters}=None)
|
|
|
|
|
This class specifies the API that makes @samp{info pretty-printer},
|
|
|
|
|
@samp{enable pretty-printer} and @samp{disable pretty-printer} work.
|
|
|
|
|
Pretty-printers should generally inherit from this class.
|
|
|
|
|
|
|
|
|
|
@item SubPrettyPrinter (@var{name})
|
|
|
|
|
For printers that handle multiple types, this class specifies the
|
|
|
|
|
corresponding API for the subprinters.
|
|
|
|
|
|
|
|
|
|
@item RegexpCollectionPrettyPrinter (@var{name})
|
|
|
|
|
Utility class for handling multiple printers, all recognized via
|
|
|
|
|
regular expressions.
|
|
|
|
|
@xref{Writing a Pretty-Printer}, for an example.
|
|
|
|
|
|
|
|
|
|
@item FlagEnumerationPrinter (@var{name})
|
|
|
|
|
A pretty-printer which handles printing of @code{enum} values. Unlike
|
|
|
|
|
@value{GDBN}'s built-in @code{enum} printing, this printer attempts to
|
|
|
|
|
work properly when there is some overlap between the enumeration
|
Don't use @var at the beginning of a sentence in GDB documentation.
gdb/doc/guile.texi (Types In Guile, Basic Guile, Frames In Guile)
(Breakpoints In Guile, Guile Printing Module)
(Guile Exception Handling, Values From Inferior In Guile)
(Objfiles In Guile, Breakpoints In Guile, Memory Ports in Guile):
Don't use @var at the beginning of a sentence.
gdb/doc/gdb.texinfo (Frame Filter Management, Trace Files)
(C Operators, Ada Tasks, Calling, Bootstrapping, ARM)
(PowerPC Embedded, Define, Annotations for Running)
(IPA Protocol Commands, Packets, General Query Packets)
(Tracepoint Packets, Notification Packets, Environment)
(Inferiors and Programs, Set Breaks, Set Catchpoints)
(Continuing and Stepping, Signals, Thread-Specific Breakpoints)
(Frames, Backtrace, Selection, Expressions, Registers)
(Trace State Variables, Built-In Func/Proc, Signaling, Files)
(Numbers, GDB/MI Async Records, GDB/MI Data Manipulation)
(Source Annotations, Using JIT Debug Info Readers, Packets)
(Stop Reply Packets, Host I/O Packets)
(Target Description Format): Don't use @var at the beginning of a
sentence.
gdb/doc/python.texi (Basic Python, Types In Python)
(Commands In Python, Frames In Python, Line Tables In Python)
(Breakpoints In Python, gdb.printing, gdb.types)
(Type Printing API): Don't use @var at the beginning of a
sentence.
2014-05-24 13:02:42 +03:00
|
|
|
constants. The argument @var{name} is the name of the printer and
|
|
|
|
|
also the name of the @code{enum} type to look up.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@item register_pretty_printer (@var{obj}, @var{printer}, @var{replace}=False)
|
|
|
|
|
Register @var{printer} with the pretty-printer list of @var{obj}.
|
|
|
|
|
If @var{replace} is @code{True} then any existing copy of the printer
|
|
|
|
|
is replaced. Otherwise a @code{RuntimeError} exception is raised
|
|
|
|
|
if a printer with the same name already exists.
|
|
|
|
|
@end table
|
|
|
|
|
|
|
|
|
|
@node gdb.types
|
|
|
|
|
@subsubsection gdb.types
|
|
|
|
|
@cindex gdb.types
|
|
|
|
|
|
|
|
|
|
This module provides a collection of utilities for working with
|
|
|
|
|
@code{gdb.Type} objects.
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@item get_basic_type (@var{type})
|
|
|
|
|
Return @var{type} with const and volatile qualifiers stripped,
|
|
|
|
|
and with typedefs and C@t{++} references converted to the underlying type.
|
|
|
|
|
|
|
|
|
|
C@t{++} example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
typedef const int const_int;
|
|
|
|
|
const_int foo (3);
|
|
|
|
|
const_int& foo_ref (foo);
|
|
|
|
|
int main () @{ return 0; @}
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
Then in gdb:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
(gdb) start
|
|
|
|
|
(gdb) python import gdb.types
|
|
|
|
|
(gdb) python foo_ref = gdb.parse_and_eval("foo_ref")
|
|
|
|
|
(gdb) python print gdb.types.get_basic_type(foo_ref.type)
|
|
|
|
|
int
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@item has_field (@var{type}, @var{field})
|
|
|
|
|
Return @code{True} if @var{type}, assumed to be a type with fields
|
|
|
|
|
(e.g., a structure or union), has field @var{field}.
|
|
|
|
|
|
|
|
|
|
@item make_enum_dict (@var{enum_type})
|
|
|
|
|
Return a Python @code{dictionary} type produced from @var{enum_type}.
|
|
|
|
|
|
|
|
|
|
@item deep_items (@var{type})
|
|
|
|
|
Returns a Python iterator similar to the standard
|
|
|
|
|
@code{gdb.Type.iteritems} method, except that the iterator returned
|
|
|
|
|
by @code{deep_items} will recursively traverse anonymous struct or
|
|
|
|
|
union fields. For example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
struct A
|
|
|
|
|
@{
|
|
|
|
|
int a;
|
|
|
|
|
union @{
|
|
|
|
|
int b0;
|
|
|
|
|
int b1;
|
|
|
|
|
@};
|
|
|
|
|
@};
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
|
Then in @value{GDBN}:
|
|
|
|
|
@smallexample
|
|
|
|
|
(@value{GDBP}) python import gdb.types
|
|
|
|
|
(@value{GDBP}) python struct_a = gdb.lookup_type("struct A")
|
|
|
|
|
(@value{GDBP}) python print struct_a.keys ()
|
|
|
|
|
@{['a', '']@}
|
|
|
|
|
(@value{GDBP}) python print [k for k,v in gdb.types.deep_items(struct_a)]
|
|
|
|
|
@{['a', 'b0', 'b1']@}
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@item get_type_recognizers ()
|
|
|
|
|
Return a list of the enabled type recognizers for the current context.
|
|
|
|
|
This is called by @value{GDBN} during the type-printing process
|
|
|
|
|
(@pxref{Type Printing API}).
|
|
|
|
|
|
|
|
|
|
@item apply_type_recognizers (recognizers, type_obj)
|
|
|
|
|
Apply the type recognizers, @var{recognizers}, to the type object
|
|
|
|
|
@var{type_obj}. If any recognizer returns a string, return that
|
|
|
|
|
string. Otherwise, return @code{None}. This is called by
|
|
|
|
|
@value{GDBN} during the type-printing process (@pxref{Type Printing
|
|
|
|
|
API}).
|
|
|
|
|
|
|
|
|
|
@item register_type_printer (locus, printer)
|
Don't use @var at the beginning of a sentence in GDB documentation.
gdb/doc/guile.texi (Types In Guile, Basic Guile, Frames In Guile)
(Breakpoints In Guile, Guile Printing Module)
(Guile Exception Handling, Values From Inferior In Guile)
(Objfiles In Guile, Breakpoints In Guile, Memory Ports in Guile):
Don't use @var at the beginning of a sentence.
gdb/doc/gdb.texinfo (Frame Filter Management, Trace Files)
(C Operators, Ada Tasks, Calling, Bootstrapping, ARM)
(PowerPC Embedded, Define, Annotations for Running)
(IPA Protocol Commands, Packets, General Query Packets)
(Tracepoint Packets, Notification Packets, Environment)
(Inferiors and Programs, Set Breaks, Set Catchpoints)
(Continuing and Stepping, Signals, Thread-Specific Breakpoints)
(Frames, Backtrace, Selection, Expressions, Registers)
(Trace State Variables, Built-In Func/Proc, Signaling, Files)
(Numbers, GDB/MI Async Records, GDB/MI Data Manipulation)
(Source Annotations, Using JIT Debug Info Readers, Packets)
(Stop Reply Packets, Host I/O Packets)
(Target Description Format): Don't use @var at the beginning of a
sentence.
gdb/doc/python.texi (Basic Python, Types In Python)
(Commands In Python, Frames In Python, Line Tables In Python)
(Breakpoints In Python, gdb.printing, gdb.types)
(Type Printing API): Don't use @var at the beginning of a
sentence.
2014-05-24 13:02:42 +03:00
|
|
|
This is a convenience function to register a type printer
|
|
|
|
|
@var{printer}. The printer must implement the type printer protocol.
|
|
|
|
|
The @var{locus} argument is either a @code{gdb.Objfile}, in which case
|
|
|
|
|
the printer is registered with that objfile; a @code{gdb.Progspace},
|
|
|
|
|
in which case the printer is registered with that progspace; or
|
|
|
|
|
@code{None}, in which case the printer is registered globally.
|
2014-02-17 10:35:03 -08:00
|
|
|
|
|
|
|
|
@item TypePrinter
|
|
|
|
|
This is a base class that implements the type printer protocol. Type
|
|
|
|
|
printers are encouraged, but not required, to derive from this class.
|
|
|
|
|
It defines a constructor:
|
|
|
|
|
|
|
|
|
|
@defmethod TypePrinter __init__ (self, name)
|
|
|
|
|
Initialize the type printer with the given name. The new printer
|
|
|
|
|
starts in the enabled state.
|
|
|
|
|
@end defmethod
|
|
|
|
|
|
|
|
|
|
@end table
|
|
|
|
|
|
|
|
|
|
@node gdb.prompt
|
|
|
|
|
@subsubsection gdb.prompt
|
|
|
|
|
@cindex gdb.prompt
|
|
|
|
|
|
|
|
|
|
This module provides a method for prompt value-substitution.
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@item substitute_prompt (@var{string})
|
|
|
|
|
Return @var{string} with escape sequences substituted by values. Some
|
|
|
|
|
escape sequences take arguments. You can specify arguments inside
|
|
|
|
|
``@{@}'' immediately following the escape sequence.
|
|
|
|
|
|
|
|
|
|
The escape sequences you can pass to this function are:
|
|
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
|
@item \\
|
|
|
|
|
Substitute a backslash.
|
|
|
|
|
@item \e
|
|
|
|
|
Substitute an ESC character.
|
|
|
|
|
@item \f
|
|
|
|
|
Substitute the selected frame; an argument names a frame parameter.
|
|
|
|
|
@item \n
|
|
|
|
|
Substitute a newline.
|
|
|
|
|
@item \p
|
|
|
|
|
Substitute a parameter's value; the argument names the parameter.
|
|
|
|
|
@item \r
|
|
|
|
|
Substitute a carriage return.
|
|
|
|
|
@item \t
|
|
|
|
|
Substitute the selected thread; an argument names a thread parameter.
|
|
|
|
|
@item \v
|
|
|
|
|
Substitute the version of GDB.
|
|
|
|
|
@item \w
|
|
|
|
|
Substitute the current working directory.
|
|
|
|
|
@item \[
|
|
|
|
|
Begin a sequence of non-printing characters. These sequences are
|
|
|
|
|
typically used with the ESC character, and are not counted in the string
|
|
|
|
|
length. Example: ``\[\e[0;34m\](gdb)\[\e[0m\]'' will return a
|
|
|
|
|
blue-colored ``(gdb)'' prompt where the length is five.
|
|
|
|
|
@item \]
|
|
|
|
|
End a sequence of non-printing characters.
|
|
|
|
|
@end table
|
|
|
|
|
|
|
|
|
|
For example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
2019-11-20 16:07:46 -07:00
|
|
|
substitute_prompt ("frame: \f, args: \p@{print frame-arguments@}")
|
2014-02-17 10:35:03 -08:00
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
@exdent will return the string:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
2019-11-20 16:07:46 -07:00
|
|
|
"frame: main, args: scalars"
|
2014-02-17 10:35:03 -08:00
|
|
|
@end smallexample
|
|
|
|
|
@end table
|
2019-02-18 15:50:49 +01:00
|
|
|
|
|
|
|
|
@node gdb.ptwrite
|
|
|
|
|
@subsubsection gdb.ptwrite
|
|
|
|
|
@cindex gdb.ptwrite
|
|
|
|
|
|
|
|
|
|
This module provides additional functionality for recording programs that
|
|
|
|
|
make use of the @code{PTWRITE} instruction. @code{PTWRITE} is a x86
|
|
|
|
|
instruction that allows to write values into the Intel Processor Trace
|
|
|
|
|
(@pxref{Process Record and Replay}).
|
|
|
|
|
The @value{NGCC} intrinsics for it are:
|
|
|
|
|
@smallexample
|
|
|
|
|
void _ptwrite32 (unsigned int a)
|
|
|
|
|
void _ptwrite64 (unsigned __int64 a)
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
If an inferior uses the instruction, @value{GDBN} by default inserts the
|
|
|
|
|
raw payload value as auxiliary information into the execution history.
|
|
|
|
|
Auxiliary information is by default printed during
|
|
|
|
|
@code{record instruction-history}, @code{record function-call-history},
|
|
|
|
|
and all stepping commands, and is accessible in Python as a
|
|
|
|
|
@code{RecordAuxiliary} object (@pxref{Recordings In Python}).
|
|
|
|
|
|
|
|
|
|
@exdent Sample program:
|
|
|
|
|
@smallexample
|
|
|
|
|
@group
|
|
|
|
|
#include <immintrin.h>
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
ptwrite64 (unsigned long long value)
|
|
|
|
|
@{
|
|
|
|
|
_ptwrite64 (value);
|
|
|
|
|
@}
|
|
|
|
|
@end group
|
|
|
|
|
|
|
|
|
|
@group
|
|
|
|
|
int
|
|
|
|
|
main (void)
|
|
|
|
|
@{
|
|
|
|
|
ptwrite64 (0x42);
|
|
|
|
|
return 0; /* break here. */
|
|
|
|
|
@}
|
|
|
|
|
@end group
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@exdent @value{GDBN} output after recording the sample program in pt format:
|
|
|
|
|
@smallexample
|
|
|
|
|
@group
|
|
|
|
|
(gdb) record instruction-history 12,14
|
|
|
|
|
12 0x0040074c <ptwrite64+16>: ptwrite %rbx
|
|
|
|
|
13 [0x42]
|
|
|
|
|
14 0x00400751 <ptwrite64+21>: mov -0x8(%rbp),%rbx
|
|
|
|
|
(gdb) record function-call-history
|
|
|
|
|
1 main
|
|
|
|
|
2 ptwrite64
|
|
|
|
|
[0x42]
|
|
|
|
|
3 main
|
|
|
|
|
@end group
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
The @code{gdb.ptwrite} module allows customizing the default output of
|
|
|
|
|
@code{PTWRITE} auxiliary information. A custom Python function can be
|
|
|
|
|
registered as the @code{PTWRITE} filter function. This function will be
|
|
|
|
|
called with the @code{PTWRITE} payload and PC as arguments during trace
|
|
|
|
|
decoding. The function can return a string, which will be printed by
|
|
|
|
|
@value{GDBN} during the aforementioned commands, or @code{None}, resulting
|
|
|
|
|
in no output. To register such a filter function, the user needs to
|
|
|
|
|
provide a filter factory function, which returns a new filter function
|
|
|
|
|
object to be called by @value{GDBN}.
|
|
|
|
|
|
|
|
|
|
@findex gdb.ptwrite.register_filter_factory
|
|
|
|
|
@defun register_filter_factory (filter_factory)
|
|
|
|
|
Used to register the @code{PTWRITE} filter factory. This filter factory can
|
|
|
|
|
be any callable object that accepts one argument, the current thread as
|
|
|
|
|
a @code{gdb.InferiorThread}.
|
|
|
|
|
It can return None or a callable. This callable is the @code{PTWRITE} filter
|
|
|
|
|
function for the specified thread. If @code{None} is returned by the factory
|
|
|
|
|
function, the default auxiliary information will be printed.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
@findex gdb.ptwrite.get_filter
|
|
|
|
|
@defun get_filter ()
|
|
|
|
|
Return the currently active @code{PTWRITE} filter function.
|
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
|
|
An example:
|
|
|
|
|
|
|
|
|
|
@smallexample
|
|
|
|
|
@group
|
|
|
|
|
(gdb) python-interactive
|
|
|
|
|
>>> class my_filter():
|
|
|
|
|
... def __init__(self):
|
|
|
|
|
... self.var = 0
|
|
|
|
|
... def __call__(self, payload, ip):
|
|
|
|
|
... self.var += 1
|
|
|
|
|
... return f"counter: @{self.var@}, ip: @{ip:#x@}"
|
|
|
|
|
...
|
|
|
|
|
>>> def my_filter_factory(thread):
|
|
|
|
|
... if thread.global_num == 1:
|
|
|
|
|
... return my_filter()
|
|
|
|
|
... else:
|
|
|
|
|
... return None
|
|
|
|
|
...
|
|
|
|
|
>>> import gdb.ptwrite
|
|
|
|
|
>>> gdb.ptwrite.register_filter_factory(my_filter_factory)
|
|
|
|
|
>>>
|
|
|
|
|
@end group
|
|
|
|
|
|
|
|
|
|
@group
|
|
|
|
|
(gdb) record function-call-history 59,64
|
|
|
|
|
59 pthread_create@@GLIBC_2.2.5
|
|
|
|
|
60 job()
|
|
|
|
|
61 task(void*)
|
|
|
|
|
62 ptwrite64(unsigned long)
|
|
|
|
|
[counter: 1, ip: 0x401156]
|
|
|
|
|
63 task(void*)
|
|
|
|
|
64 ptwrite32(unsigned int)
|
|
|
|
|
[counter: 2, ip: 0x40116c]
|
|
|
|
|
@end group
|
|
|
|
|
|
|
|
|
|
@group
|
|
|
|
|
(gdb) info threads
|
|
|
|
|
* 1 Thread 0x7ffff7fd8740 (LWP 25796) "ptw_threads" task ()
|
|
|
|
|
at bin/ptwrite/ptw_threads.c:45
|
|
|
|
|
2 Thread 0x7ffff6eb8700 (LWP 25797) "ptw_threads" task ()
|
|
|
|
|
at bin/ptwrite/ptw_threads.c:45
|
|
|
|
|
@end group
|
|
|
|
|
|
|
|
|
|
@group
|
|
|
|
|
(gdb) thread 2
|
|
|
|
|
[Switching to thread 2 (Thread 0x7ffff6eb8700 (LWP 25797))]
|
|
|
|
|
#0 task (arg=0x0) at ptwrite_threads.c:45
|
|
|
|
|
45 return NULL;
|
|
|
|
|
@end group
|
|
|
|
|
|
|
|
|
|
@group
|
|
|
|
|
(gdb) record function-call-history 10,14
|
|
|
|
|
10 start_thread
|
|
|
|
|
11 task(void*)
|
|
|
|
|
12 ptwrite64(unsigned long)
|
|
|
|
|
[0x42]
|
|
|
|
|
13 task(void*)
|
|
|
|
|
14 ptwrite32(unsigned int)
|
|
|
|
|
[0x43]
|
|
|
|
|
@end group
|
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
|
|
This @value{GDBN} feature is dependent on hardware and operating system
|
|
|
|
|
support and requires the Intel Processor Trace decoder library in version
|
|
|
|
|
2.0.0 or newer.
|