Consider this command defined in Python (in the file test-cmd.py):
class test_cmd (gdb.Command):
"""
This is the first line.
Indented second line.
This is the third line.
"""
def __init__ (self):
super ().__init__ ("test-cmd", gdb.COMMAND_OBSCURE)
def invoke (self, arg, from_tty):
print ("In test-cmd")
test_cmd()
Now, within a GDB session:
(gdb) source test-cmd.py
(gdb) help test-cmd
This is the first line.
Indented second line.
This is the third line.
(gdb)
I think there's three things wrong here:
1. The leading blank line,
2. The trailing blank line, and
3. Every line is indented from the left edge slightly.
The problem of course, is that GDB is using the Python doc string
verbatim as its help text. While the user has formatted the help text
so that it appears clear within the .py file, this means that the text
appear less well formatted when displayed in the "help" output.
The same problem can be observed for gdb.Parameter objects in their
set/show output.
In this commit I aim to improve the "help" output for commands and
parameters.
To do this I have added gdbpy_fix_doc_string_indentation, a new
function that rewrites the doc string text following the following
rules:
1. Leading blank lines are removed,
2. Trailing blank lines are removed, and
3. Leading whitespace is removed in a "smart" way such that the
relative indentation of lines is retained.
With this commit in place the above example now looks like this:
(gdb) source ~/tmp/test-cmd.py
(gdb) help test-cmd
This is the first line.
Indented second line.
This is the third line.
(gdb)
Which I think is much neater. Notice that the indentation of the
second line is retained. Any blank lines within the help text (not
leading or trailing) will be retained.
I've added a NEWS entry to note that there has been a change in
behaviour, but I didn't update the manual. The existing manual is
suitably vague about how the doc string is used, so I think the new
behaviour is covered just as well by the existing text.
New in this version:
- Rebase on master, fix a few more issues that appeared.
python-internal.h contains a number of macros that helped make the code
work with both Python 2 and 3. Remove them and adjust the code to use
the Python 3 functions.
Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d
New in this version:
- Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON. If
the user passes --with-python=python2, this will cause a configure
failure saying that GDB only supports Python 3.
Support for Python 2 is a maintenance burden for any patches touching
Python support. Among others, the differences between Python 2 and 3
string and integer types are subtle. It requires a lot of effort and
thinking to get something that behaves correctly on both. And that's if
the author and reviewer of the patch even remember to test with Python
2.
See this thread for an example:
https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html
So, remove Python 2 support. Update the documentation to state that GDB
can be built against Python 3 (as opposed to Python 2 or 3).
Update all the spots that use:
- sys.version_info
- IS_PY3K
- PY_MAJOR_VERSION
- gdb_py_is_py3k
... to only keep the Python 3 portions and drop the use of some
now-removed compatibility macros.
I did not update the configure script more than just removing the
explicit references to Python 2. We could maybe do more there, like
check the Python version and reject it if that version is not
supported. Otherwise (with this patch), things will only fail at
compile time, so it won't really be clear to the user that they are
trying to use an unsupported Python version. But I'm a bit lost in the
configure code that checks for Python, so I kept that for later.
Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62
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.
The motivation for this patch is the fact that py-micmd.c doesn't build
with Python 2, due to PyDict_GetItemWithError being a Python 3-only
function:
CXX python/py-micmd.o
/home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’:
/home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’?
430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (),
| ^~~~~~~~~~~~~~~~~~~~~~~
| PyDict_GetItemString
A first solution to fix this would be to try to replace
PyDict_GetItemWithError equivalent Python 2 code. But I looked at why
we are doing this in the first place: it is to maintain the
`gdb._mi_commands` Python dictionary that we use as a `name ->
gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is
never actually used in Python, it seems like a lot of trouble to use a
Python object for this.
My first idea was to replace it with a C++ map
(std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While
implementing this, I realized we don't really need this map at all. The
mi_command_py objects registered in the main MI command table can own
their backing micmdpy_object (that's a gdb.MICommand, but seen from the
C++ code). To know whether an mi_command is an mi_command_py, we can
use a dynamic cast. Since there's one less data structure to maintain,
there are less chances of messing things up.
- Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is
now what keeps the MICommand alive.
- Set micmdpy_object::mi_command in the constructor of mi_command_py.
If mi_command_py manages setting/clearing that field in
swap_python_object, I think it makes sense that it also takes care of
setting it initially.
- Move a bunch of checks from micmdpy_install_command to
swap_python_object, and make them gdb_asserts.
- In micmdpy_install_command, start by doing an mi_cmd_lookup. This is
needed to know whether there's a Python MI command already registered
with that name. But we can already tell if there's a non-Python
command registered with that name. Return an error if that happens,
rather than waiting for insert_mi_cmd_entry to fail. Change the
error message to "name is already in use" rather than "may already be
in use", since it's more precise.
I asked Andrew about the original intent of using a Python dictionary
object to hold the command objects. The reason was to make sure the
objects get destroyed when the Python runtime gets finalized, not later.
Holding the objects in global C++ data structures and not doing anything
more means that the held Python objects will be decref'd after the
Python interpreter has been finalized. That's not desirable. I tried
it and it indeed segfaults.
Handle this by adding a gdbpy_finalize_micommands function called in
finalize_python. This is the mirror of gdbpy_initialize_micommands
called in do_start_initialization. In there, delete all Python MI
commands. I think it makes sense to do it this way: if it was somehow
possible to unload Python support from GDB in the middle of a session
we'd want to unregister any Python MI command. Otherwise, these MI
commands would be backed with a stale PyObject or simply nothing.
Delete tests that were related to `gdb._mi_commands`.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
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>
Add a new function gdb.history_count to the Python api, this function
returns an integer, the number of items in GDB's value history.
This is useful if you want to pull items from the history by their
absolute number, for example, if you wanted to show a complete history
list. Previously we could figure out how many items are in the
history list by trying to fetch the items, and then catching the
exception when the item is not available, but having this function
seems nicer.
Currently, gdb's Python layer captures the current architecture and
language when "entering" Python code. This has some undesirable
effects, and so this series changes how this is handled.
First, there is code like this:
gdbpy_enter enter_py (python_gdbarch, python_language);
This is incorrect, because both of these are NULL when not otherwise
assigned. This can cause crashes in some cases -- I've added one to
the test suite. (Note that this crasher is just an example, other
ones along the same lines are possible.)
Second, when the language is captured in this way, it means that
Python code cannot affect the current language for its own purposes.
It's reasonable to want to write code like this:
gdb.execute('set language mumble')
... stuff using the current language
gdb.execute('set language previous-value')
However, this won't actually work, because the language is captured on
entry. I've added a test to show this as well.
This patch changes gdb to try to avoid capturing the current values.
The Python concept of the current gdbarch is only set in those few
cases where a non-default value is computed or needed; and the
language is not captured at all -- instead, in the cases where it's
required, the current language is temporarily changed.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
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'.
I don't find that the bpstat typedef, which hides a pointer, is
particularly useful. In fact, it confused me many times, and I just see
it as something to remember that adds cognitive load. Also, with C++,
we might want to be able to pass bpstats objects by const-reference, not
necessarily by pointer.
So, remove the bpstat typedef and rename struct bpstats to bpstat (since
it represents one bpstat, it makes sense that it is singular).
Change-Id: I52e763b6e54ee666a9e045785f686d37b4f5f849
In a future commit I'm going to be creating gdb.Membuf objects from a
new file within gdb/python/py*.c. Currently all gdb.Membuf objects
are created directly within infpy_read_memory (as a result of calling
gdb.Inferior.read_memory()).
Initially I split out the Membuf creation code into a new function,
and left the new function in gdb/python/py-inferior.c, however, it
felt a little random that the Membuf creation code should live with
the inferior handling code.
So, then I moved all of the Membuf related code out into a new file,
gdb/python/py-membuf.c, the interface is gdbpy_buffer_to_membuf, which
wraps an array of bytes into a gdb.Membuf object.
Most of the code is moved directly from py-inferior.c with only minor
tweaks to layout and replacing NULL with nullptr, hence, I've left the
copyright date on py-membuf.c as 2009-2021 to match py-inferior.c.
Currently, the only user of this code is still py-inferior.c, but in
later commits this will change.
There should be no user visible changes after this commit.
Add a new function to the Python API, gdb.architecture_names(). This
function returns a list containing all of the supported architecture
names within the current build of GDB.
The values returned in this list are all of the possible values that
can be returned from gdb.Architecture.name().
cmd_list_element can contain a pointer to data that can be set and / or
shown. This is achieved with the void* VAR member which points to the
data that can be accessed, while the VAR_TYPE member (of type enum
var_types) indicates how to interpret the data pointed to.
With this pattern, the user of the cmd_list_element needs to know what
is the storage type associated with a given VAR_TYPES in order to do
the proper casting. No automatic safeguard is available to prevent
miss-use of the pointer. Client code typically looks something like:
switch (c->var_type)
{
case var_zuinteger:
unsigned int v = *(unsigned int*) c->var;
...
break;
case var_boolean:
bool v = *(bool *) c->var;
...
break;
...
}
This patch proposes to add an abstraction around the var_types and void*
pointer pair. The abstraction is meant to prevent the user from having
to handle the cast and verify that the data is read or written as a type
that is coherent with the setting's var_type. This is achieved by
introducing the struct setting which exposes a set of templated get /
set member functions. The template parameter is the type of the
variable that holds the referred variable.
Using those accessors allows runtime checks to be inserted in order to
ensure that the data pointed to has the expected type. For example,
instantiating the member functions with bool will yield something
similar to:
const bool &get<bool> () const
{
gdb_assert (m_var_type == var_boolean);
gdb_assert (m_var != nullptr);
return *static_cast<bool *> (m_var);
}
void set<bool> (const bool &var)
{
gdb_assert (m_var_type == var_boolean);
gdb_assert (m_var != nullptr);
*static_cast<bool *> (m_var) = var;
}
Using the new abstraction, our initial example becomes:
switch (c->var_type)
{
case var_zuinteger:
unsigned int v = c->var->get<unsigned int> ();
...
break;
case var_boolean:
bool v = c->var->get<bool> ();
...
break;
...
}
While the call site is still similar, the introduction of runtime checks
help ensure correct usage of the data.
In order to avoid turning the bulk of add_setshow_cmd_full into a
templated function, and following a suggestion from Pedro Alves, a
setting can be constructed from a pre validated type erased reference to
a variable. This is what setting::erased_args is used for.
Introducing an opaque abstraction to describe a setting will also make
it possible to use callbacks to retrieve or set the value of the setting
on the fly instead of pointing to a static chunk of memory. This will
be done added in a later commit.
Given that a cmd_list_element may or may not reference a setting, the
VAR and VAR_TYPES members of the struct are replaced with a
gdb::optional<setting> named VAR.
Few internal function signatures have been modified to take into account
this new abstraction:
-The functions value_from_setting, str_value_from_setting and
get_setshow_command_value_string used to have a 'cmd_list_element *'
parameter but only used it for the VAR and VAR_TYPE member. They now
take a 'const setting &' parameter instead.
- Similarly, the 'void *' and a 'enum var_types' parameters of
pascm_param_value and gdbpy_parameter_value have been replaced with a
'const setting &' parameter.
No user visible change is expected after this patch.
Tested on GNU/Linux x86_64, with no regression noticed.
Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>
Change-Id: Ie1d08c3ceb8b30b3d7bf1efe036eb8acffcd2f34
Python 2 has a bit flag Py_TPFLAGS_HAVE_ITER which can be passed as
part of the tp_flags field when defining a new object type. This flag
is not defined in Python 3 and so we define it to 0 in
python-internal.h (when IS_PY3K is defined).
The meaning of this flag is that the object has the fields tp_iter and
tp_iternext. Note the use of "has" here, the flag says nothing about
the values in those fields, just that the type object has the fields.
In early versions of Python 2 these fields were no part of the
PyTypeObject struct, they were added in version 2.2 (see
https://docs.python.org/release/2.3/api/type-structs.html). And so,
there could be a some code compiled out there which has a PyTypeObject
structure within it that doesn't even have the tp_iter and tp_iternext
fields, attempting to access these fields would be undefined
behaviour.
And so Python added the Py_TPFLAGS_HAVE_ITER flag. If the flag is
present then Python is free to access the tp_iter and tp_iternext
fields.
If we consider GDB then we always assume that the tp_iter and
tp_iternext fields are part of PyTypeObject. If someone was crazy
enough to try and compile GDB against Python 2.1 then we'd get lots of
build errors saying that we were passing too many fields when
initializing PyTypeObject structures. And so, I claim, we can be sure
that GDB will always be compiled with a version of Python that has the
tp_iter and tp_iternext fields in PyTypeObject.
Next we can look at the Py_TPFLAGS_DEFAULT flag. In Python 2, each
time additional fields are added to PyTypeObject a new Py_TPFLAGS_*
flag would be defined to indicate whether those flags are present or
not. And, those new flags would be added to Py_TPFLAGS_DEFAULT. And
so, in the latest version of Python 2 the Py_TPFLAGS_DEFAULT flag
includes Py_TPFLAGS_HAVE_ITER (see
https://docs.python.org/2.7/c-api/typeobj.html).
In GDB we pass Py_TPFLAGS_DEFAULT as part of the tp_flags for all
objects we define.
And so, in this commit, I propose to remove all uses of
Py_TPFLAGS_HAVE_ITER from GDB, it's simply not needed.
There should be no user visible changes after this commit.
The guile API has (history-append! <value>) to add values into GDB's
history list. There is currently no equivalent in the Python API.
This commit adds gdb.add_history(<value>) to the Python API, this
function takes <value> a gdb.Value (or anything that can be passed to
the constructor of gdb.Value), and adds the value it represents to
GDB's history list. The index of the newly added value is returned.
This avoids some manual memory management.
cmdpy_init correctly transfers ownership of the name to the
cmd_list_element, as it sets the name_allocated flag. However,
cmdpy_init (and add_setshow_generic) doesn't, it looks like the name is
just leaked. This is a bit tricky, because it actually creates two
commands (one set and one show), it would take a bit of refactoring of
the command code to give each their own allocated copy. For now, just
keep doing what the current code does but in a more explicit fashion,
with an explicit release.
gdb/ChangeLog:
* python/python-internal.h (gdbpy_parse_command_name): Return
gdb::unique_xmalloc_ptr.
* python/py-cmd.c (gdbpy_parse_command_name): Likewise.
(cmdpy_init): Adjust.
* python/py-param.c (parmpy_init): Adjust.
(add_setshow_generic): Take gdb::unique_xmalloc_ptr, release it
when done.
Change-Id: Iae5bc21fe2b22f12d5f954057b0aca7ca4cd3f0d
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
Avoid the use of PyInt_FromLong, preferring gdb_py_object_from_longest
instead. I found found another spot that was incorrectly handling
errors (see gdbpy_create_ptid_object) while writing this patch; it is
fixed here.
gdb/ChangeLog
2020-09-15 Tom Tromey <tromey@adacore.com>
* python/python-internal.h (PyInt_FromLong): Remove define.
* python/py-value.c (convert_value_from_python): Use
gdb_py_object_from_longest.
* python/py-type.c (typy_get_code): Use
gdb_py_object_from_longest.
* python/py-symtab.c (salpy_get_line): Use
gdb_py_object_from_longest.
* python/py-symbol.c (sympy_get_addr_class, sympy_line): Use
gdb_py_object_from_longest.
* python/py-record.c (recpy_gap_reason_code): Use
gdb_py_object_from_longest.
* python/py-record-btrace.c (recpy_bt_insn_size)
(recpy_bt_func_level, btpy_list_count): Use
gdb_py_object_from_longest.
* python/py-infthread.c (gdbpy_create_ptid_object): Use
gdb_py_object_from_longest. Fix error handling.
* python/py-framefilter.c (bootstrap_python_frame_filters): Use
gdb_py_object_from_longest.
* python/py-frame.c (frapy_type, frapy_unwind_stop_reason): Use
gdb_py_object_from_longest.
* python/py-breakpoint.c (bppy_get_type, bppy_get_number)
(bppy_get_thread, bppy_get_task, bppy_get_hit_count)
(bppy_get_ignore_count): Use gdb_py_object_from_longest.
Remove the gdb_py_long_from_ulongest defines and change the Python
layer to prefer gdb_py_object_from_ulongest. While writing this I
noticed that the error handling in archpy_disassemble was incorrect --
it could call PyDict_SetItemString with a NULL value. This patch also
fixes this bug.
gdb/ChangeLog
2020-09-15 Tom Tromey <tromey@adacore.com>
* python/python-internal.h (gdb_py_long_from_ulongest): Remove
defines.
* python/py-value.c (valpy_long): Use
gdb_py_object_from_ulongest.
* python/py-symtab.c (salpy_get_pc): Use
gdb_py_object_from_ulongest.
(salpy_get_last): Likewise.
* python/py-record-btrace.c (recpy_bt_insn_pc): Use
gdb_py_object_from_ulongest.
* python/py-lazy-string.c (stpy_get_address): Use
gdb_py_object_from_ulongest.
* python/py-frame.c (frapy_pc): Use gdb_py_object_from_ulongest.
* python/py-arch.c (archpy_disassemble): Use
gdb_py_object_from_ulongest and gdb_py_object_from_longest. Fix
error handling.
Change the Python layer to avoid gdb_py_long_from_longest, and remove
the defines.
gdb/ChangeLog
2020-09-15 Tom Tromey <tromey@adacore.com>
* python/python-internal.h (gdb_py_long_from_longest): Remove
defines.
* python/py-value.c (valpy_long): Use gdb_py_object_from_longest.
* python/py-type.c (convert_field, typy_get_sizeof): Use
gdb_py_object_from_longest.
* python/py-record-btrace.c (btpy_list_index): Use
gdb_py_object_from_longest.
Change the Python layer to avoid PyInt_FromSsize_t, and remove the
compatibility define.
gdb/ChangeLog
2020-09-15 Tom Tromey <tromey@adacore.com>
* python/python-internal.h (PyInt_FromSsize_t): Remove define.
* python/py-record.c (recpy_element_number): Use
gdb_py_object_from_longest.
(recpy_gap_number): Likewise.
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.
Add a new method gdb.Architecture.register_groups which returns a new
object of type gdb.RegisterGroupsIterator. This new iterator then
returns objects of type gdb.RegisterGroup.
Each gdb.RegisterGroup object just wraps a single reggroup pointer,
and (currently) has just one read-only property 'name' that is a
string, the name of the register group.
As with the previous commit (adding gdb.RegisterDescriptor) I made
gdb.RegisterGroup an object rather than just a string in case we want
to add additional properties in the future.
gdb/ChangeLog:
* NEWS: Mention additions to Python API.
* python/py-arch.c (archpy_register_groups): New function.
(arch_object_methods): Add 'register_groups' method.
* python/py-registers.c (reggroup_iterator_object): New struct.
(reggroup_object): New struct.
(gdbpy_new_reggroup): New function.
(gdbpy_reggroup_to_string): New function.
(gdbpy_reggroup_name): New function.
(gdbpy_reggroup_iter): New function.
(gdbpy_reggroup_iter_next): New function.
(gdbpy_new_reggroup_iterator): New function
(gdbpy_initialize_registers): Register new types.
(reggroup_iterator_object_type): Define new Python type.
(gdbpy_reggroup_getset): New static global.
(reggroup_object_type): Define new Python type.
* python/python-internal.h
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-groups.exp: New file.
gdb/doc/ChangeLog:
* gdb.texi (Registers): Add @anchor for 'info registers
<reggroup>' command.
* python.texi (Architectures In Python): Document new
register_groups method.
(Registers In Python): Document two new object types related to
register groups.
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.
This changes the extension language pretty-printers to use the value
API.
Note that new functions were needed, for both Guile and Python.
Currently both languages always wrap values by removing the values
from the value chain. This makes sense to avoid strange behavior with
watchpoints, and to avoid excessive memory use. However, when
printing, it's important to leave the passed-in value untouched, in
case pretty-printing does nothing -- that way the caller can still
access it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): Update.
* python/python-internal.h (gdbpy_apply_val_pretty_printer): Take
a struct value.
(value_to_value_object_no_release): Declare.
* python/py-value.c (value_to_value_object_no_release): New
function.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Take a
struct value.
* guile/scm-value.c (vlscm_scm_from_value_no_release): New
function.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Take
a struct value.
* guile/guile-internal.h (vlscm_scm_from_value_no_release):
Declare.
(gdbscm_apply_val_pretty_printer): Take a struct value.
* extension.h (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension.c (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension-priv.h (struct extension_language_ops)
<apply_val_pretty_printer>: Take a struct value.
* cp-valprint.c (cp_print_value): Create a struct value.
(cp_print_value): Update.
This patch adds support for writing new TUI windows in Python.
2020-02-22 Tom Tromey <tom@tromey.com>
* NEWS: Add entry for gdb.register_window_type.
* tui/tui-layout.h (window_factory): New typedef.
(tui_register_window): Declare.
* tui/tui-layout.c (saved_tui_windows): New global.
(tui_apply_current_layout): Use it.
(tui_register_window): New function.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_tui.
(python_GdbMethods): Add "register_window_type" function.
* python/python-internal.h (gdbpy_register_tui_window)
(gdbpy_initialize_tui): Declare.
* python/py-tui.c: New file.
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-tui.c.
gdb/doc/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* python.texi (Python API): Add menu item.
(TUI Windows In Python): New node.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.python/tui-window.exp: New file.
* gdb.python/tui-window.py: New file.
Change-Id: I85fbfb923a1840450a00a7dce113a05d7f048baa
If gdb.lookup_static_symbol is going to return a single symbol then it
makes sense (I think) for it to return a context sensitive choice of
symbol, that is the global static symbol that would be visible to the
program at that point.
However, if the user of the python API wants to instead get a
consistent set of global static symbols, no matter where they stop,
then they have to instead consider all global static symbols with a
given name - there could be many. That is what this new API function
offers, it returns a list (possibly empty) of all global static
symbols matching a given name (and optionally a given symbol domain).
gdb/ChangeLog:
* python/py-symbol.c (gdbpy_lookup_static_symbols): New
function.
* python/python-internal.h (gdbpy_lookup_static_symbols):
Declare new function.
* python/python.c (python_GdbMethods): Add
gdb.lookup_static_symbols method.
* NEWS: Mention gdb.lookup_static_symbols.
gdb/testsuite/ChangeLog:
* gdb.python/py-symbol.exp: Add test for
gdb.lookup_static_symbols.
gdb/doc/ChangeLog:
* python.texi (Symbols In Python): Add documentation for
gdb.lookup_static_symbols.
Change-Id: I1153b0ae5bcbc43b3dcf139043c7a48bf791e1a3
Similar to lookup_global_symbol, except that it checks the
STATIC_SCOPE.
gdb/ChangeLog:
2019-07-30 Christian Biesinger <cbiesinger@google.com>
PR/24474: Add a function to lookup static variables.
* NEWS: Mention this new function.
* python/py-symbol.c (gdbpy_lookup_static_symbol): New function.
* python/python-internal.h (gdbpy_lookup_static_symbol): New function.
* python/python.c (python_GdbMethods): Add new function.
gdb/doc/ChangeLog:
2019-07-30 Christian Biesinger <cbiesinger@google.com>
* python.texi (Symbols In Python): Document new function
gdb.lookup_static_symbol.
gdb/testsuite/ChangeLog:
2019-07-30 Christian Biesinger <cbiesinger@google.com>
* gdb.python/py-symbol.c: Add a static variable and one in an anonymous
namespace.
* gdb.python/py-symbol.exp: Test gdb.lookup_static_symbol.
This patch changes py-inferior.c to use gdbpy_ref<> when possible,
reducing the amount of manual reference counting.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-07-10 Tom Tromey <tromey@adacore.com>
* python/python-internal.h (create_thread_object): Return
gdbpy_ref.
* python/py-infthread.c (create_thread_object): Return gdbpy_ref.
* python/py-inferior.c (struct threadlist_entry): Add
constructor.
<thread_obj>: Now a gdbpy_ref.
(thread_to_thread_object): Update.
(add_thread_object): Use new.
(delete_thread_object): Use delete.
(infpy_threads): Update.
(py_free_inferior): Update. Construct "inf_obj" after acquiring
GIL.
This makes exception handling more efficient in a few spots, through
the use of const- and rvalue-references.
I wrote this patch by commenting out the gdb_exception copy
constructor and then examining the resulting error messages one by
one, introducing the use of std::move where appropriate.
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
* xml-support.c (struct gdb_xml_parser) <set_error>: Take an
rvalue reference.
(gdb_xml_start_element_wrapper, gdb_xml_end_element_wrapper)
(gdb_xml_parser::parse): Use std::move.
* python/python-internal.h (gdbpy_convert_exception): Take a const
reference.
* python/py-value.c (valpy_getitem, valpy_nonzero): Use
std::move.
* python/py-utils.c (gdbpy_convert_exception): Take a const
reference.
* python/py-inferior.c (infpy_write_memory, infpy_search_memory):
Use std::move.
* python/py-breakpoint.c (bppy_set_condition, bppy_set_commands):
Use std::move.
* mi/mi-main.c (mi_print_exception): Take a const reference.
* main.c (handle_command_errors): Take a const reference.
* linespec.c (parse_linespec): Use std::move.
* infcall.c (run_inferior_call): Use std::move.
(call_function_by_hand_dummy): Use std::move.
* exec.c (try_open_exec_file): Use std::move.
* exceptions.h (exception_print, exception_fprintf)
(exception_print_same): Update.
* exceptions.c (print_exception, exception_print)
(exception_fprintf, exception_print_same): Change parameters to
const reference.
* event-top.c (gdb_rl_callback_read_char_wrapper): Update.
* common/new-op.c: Use std::move.
* common/common-exceptions.h (struct gdb_exception): Add move
constructor.
(struct gdb_exception_error, struct gdb_exception_quit, struct
gdb_quit_bad_alloc): Change constructor to move constructor.
(throw_exception): Change parameter to rvalue reference.
* common/common-exceptions.c (throw_exception): Take rvalue
reference.
* cli/cli-interp.c (safe_execute_command): Use std::move.
* breakpoint.c (insert_bp_location, location_to_sals): Use
std::move.
This patch causes PyBuffer_Release() to be called when the associated
buffer goes out of scope. I've been using it as follows:
...
Py_buffer_up buffer_up;
Py_buffer py_buf;
if (PyObject_CheckBuffer (obj)
&& PyObject_GetBuffer (obj, &py_buf, PyBUF_SIMPLE) == 0)
{
/* Got a buffer, py_buf, out of obj. Cause it to released
when it goes out of scope. */
buffer_up.reset (&py_buf);
}
...
This snippet of code was taken directly from an upcoming patch to
python-value.c.
gdb/ChangeLog:
* python/python-internal.h (Py_buffer_deleter): New struct.
(Py_buffer_up): New typedef.
While working on my other scripts to deal with gdb headers, I noticed
that some files were missing include guards. I wrote a script to add
the missing ones, but found that using the obvious names for the
guards ran into clashes -- for example, gdb/nat/linux-nat.h used
"LINUX_NAT_H", but this was also the script's choice for
gdb/linux-nat.h.
So, I changed the script to normalize all include guards in gdb. This
patch is the result.
As usual the script is available here:
https://github.com/tromey/gdb-refactoring-scripts
Tested by rebuilding; I also ran it through "Fedora-x86_64-m64" on the
buildbot.
gdb/ChangeLog
2019-02-07 Tom Tromey <tom@tromey.com>
* yy-remap.h: Add include guard.
* xtensa-tdep.h: Add include guard.
* xcoffread.h: Rename include guard.
* varobj-iter.h: Add include guard.
* tui/tui.h: Rename include guard.
* tui/tui-winsource.h: Rename include guard.
* tui/tui-wingeneral.h: Rename include guard.
* tui/tui-windata.h: Rename include guard.
* tui/tui-win.h: Rename include guard.
* tui/tui-stack.h: Rename include guard.
* tui/tui-source.h: Rename include guard.
* tui/tui-regs.h: Rename include guard.
* tui/tui-out.h: Rename include guard.
* tui/tui-layout.h: Rename include guard.
* tui/tui-io.h: Rename include guard.
* tui/tui-hooks.h: Rename include guard.
* tui/tui-file.h: Rename include guard.
* tui/tui-disasm.h: Rename include guard.
* tui/tui-data.h: Rename include guard.
* tui/tui-command.h: Rename include guard.
* tic6x-tdep.h: Add include guard.
* target/waitstatus.h: Rename include guard.
* target/wait.h: Rename include guard.
* target/target.h: Rename include guard.
* target/resume.h: Rename include guard.
* target-float.h: Rename include guard.
* stabsread.h: Add include guard.
* rs6000-tdep.h: Add include guard.
* riscv-fbsd-tdep.h: Add include guard.
* regformats/regdef.h: Rename include guard.
* record.h: Rename include guard.
* python/python.h: Rename include guard.
* python/python-internal.h: Rename include guard.
* python/py-stopevent.h: Rename include guard.
* python/py-ref.h: Rename include guard.
* python/py-record.h: Rename include guard.
* python/py-record-full.h: Rename include guard.
* python/py-record-btrace.h: Rename include guard.
* python/py-instruction.h: Rename include guard.
* python/py-events.h: Rename include guard.
* python/py-event.h: Rename include guard.
* procfs.h: Add include guard.
* proc-utils.h: Add include guard.
* p-lang.h: Add include guard.
* or1k-tdep.h: Rename include guard.
* observable.h: Rename include guard.
* nto-tdep.h: Rename include guard.
* nat/x86-linux.h: Rename include guard.
* nat/x86-linux-dregs.h: Rename include guard.
* nat/x86-gcc-cpuid.h: Add include guard.
* nat/x86-dregs.h: Rename include guard.
* nat/x86-cpuid.h: Rename include guard.
* nat/ppc-linux.h: Rename include guard.
* nat/mips-linux-watch.h: Rename include guard.
* nat/linux-waitpid.h: Rename include guard.
* nat/linux-ptrace.h: Rename include guard.
* nat/linux-procfs.h: Rename include guard.
* nat/linux-osdata.h: Rename include guard.
* nat/linux-nat.h: Rename include guard.
* nat/linux-namespaces.h: Rename include guard.
* nat/linux-btrace.h: Rename include guard.
* nat/glibc_thread_db.h: Rename include guard.
* nat/gdb_thread_db.h: Rename include guard.
* nat/gdb_ptrace.h: Rename include guard.
* nat/fork-inferior.h: Rename include guard.
* nat/amd64-linux-siginfo.h: Rename include guard.
* nat/aarch64-sve-linux-sigcontext.h: Rename include guard.
* nat/aarch64-sve-linux-ptrace.h: Rename include guard.
* nat/aarch64-linux.h: Rename include guard.
* nat/aarch64-linux-hw-point.h: Rename include guard.
* mn10300-tdep.h: Add include guard.
* mips-linux-tdep.h: Add include guard.
* mi/mi-parse.h: Rename include guard.
* mi/mi-out.h: Rename include guard.
* mi/mi-main.h: Rename include guard.
* mi/mi-interp.h: Rename include guard.
* mi/mi-getopt.h: Rename include guard.
* mi/mi-console.h: Rename include guard.
* mi/mi-common.h: Rename include guard.
* mi/mi-cmds.h: Rename include guard.
* mi/mi-cmd-break.h: Rename include guard.
* m2-lang.h: Add include guard.
* location.h: Rename include guard.
* linux-record.h: Rename include guard.
* linux-nat.h: Add include guard.
* linux-fork.h: Add include guard.
* i386-darwin-tdep.h: Rename include guard.
* hppa-linux-offsets.h: Add include guard.
* guile/guile.h: Rename include guard.
* guile/guile-internal.h: Rename include guard.
* gnu-nat.h: Rename include guard.
* gdb-stabs.h: Rename include guard.
* frv-tdep.h: Add include guard.
* f-lang.h: Add include guard.
* event-loop.h: Add include guard.
* darwin-nat.h: Rename include guard.
* cp-abi.h: Rename include guard.
* config/sparc/nm-sol2.h: Rename include guard.
* config/nm-nto.h: Rename include guard.
* config/nm-linux.h: Add include guard.
* config/i386/nm-i386gnu.h: Rename include guard.
* config/djgpp/nl_types.h: Rename include guard.
* config/djgpp/langinfo.h: Rename include guard.
* compile/gcc-cp-plugin.h: Add include guard.
* compile/gcc-c-plugin.h: Add include guard.
* compile/compile.h: Rename include guard.
* compile/compile-object-run.h: Rename include guard.
* compile/compile-object-load.h: Rename include guard.
* compile/compile-internal.h: Rename include guard.
* compile/compile-cplus.h: Rename include guard.
* compile/compile-c.h: Rename include guard.
* common/xml-utils.h: Rename include guard.
* common/x86-xstate.h: Rename include guard.
* common/version.h: Rename include guard.
* common/vec.h: Rename include guard.
* common/tdesc.h: Rename include guard.
* common/selftest.h: Rename include guard.
* common/scoped_restore.h: Rename include guard.
* common/scoped_mmap.h: Rename include guard.
* common/scoped_fd.h: Rename include guard.
* common/safe-iterator.h: Rename include guard.
* common/run-time-clock.h: Rename include guard.
* common/refcounted-object.h: Rename include guard.
* common/queue.h: Rename include guard.
* common/ptid.h: Rename include guard.
* common/print-utils.h: Rename include guard.
* common/preprocessor.h: Rename include guard.
* common/pathstuff.h: Rename include guard.
* common/observable.h: Rename include guard.
* common/netstuff.h: Rename include guard.
* common/job-control.h: Rename include guard.
* common/host-defs.h: Rename include guard.
* common/gdb_wait.h: Rename include guard.
* common/gdb_vecs.h: Rename include guard.
* common/gdb_unlinker.h: Rename include guard.
* common/gdb_unique_ptr.h: Rename include guard.
* common/gdb_tilde_expand.h: Rename include guard.
* common/gdb_sys_time.h: Rename include guard.
* common/gdb_string_view.h: Rename include guard.
* common/gdb_splay_tree.h: Rename include guard.
* common/gdb_setjmp.h: Rename include guard.
* common/gdb_ref_ptr.h: Rename include guard.
* common/gdb_optional.h: Rename include guard.
* common/gdb_locale.h: Rename include guard.
* common/gdb_assert.h: Rename include guard.
* common/filtered-iterator.h: Rename include guard.
* common/filestuff.h: Rename include guard.
* common/fileio.h: Rename include guard.
* common/environ.h: Rename include guard.
* common/common-utils.h: Rename include guard.
* common/common-types.h: Rename include guard.
* common/common-regcache.h: Rename include guard.
* common/common-inferior.h: Rename include guard.
* common/common-gdbthread.h: Rename include guard.
* common/common-exceptions.h: Rename include guard.
* common/common-defs.h: Rename include guard.
* common/common-debug.h: Rename include guard.
* common/cleanups.h: Rename include guard.
* common/buffer.h: Rename include guard.
* common/btrace-common.h: Rename include guard.
* common/break-common.h: Rename include guard.
* cli/cli-utils.h: Rename include guard.
* cli/cli-style.h: Rename include guard.
* cli/cli-setshow.h: Rename include guard.
* cli/cli-script.h: Rename include guard.
* cli/cli-interp.h: Rename include guard.
* cli/cli-decode.h: Rename include guard.
* cli/cli-cmds.h: Rename include guard.
* charset-list.h: Add include guard.
* buildsym-legacy.h: Rename include guard.
* bfin-tdep.h: Add include guard.
* ax.h: Rename include guard.
* arm-linux-tdep.h: Add include guard.
* arm-fbsd-tdep.h: Add include guard.
* arch/xtensa.h: Rename include guard.
* arch/tic6x.h: Add include guard.
* arch/i386.h: Add include guard.
* arch/arm.h: Rename include guard.
* arch/arm-linux.h: Rename include guard.
* arch/arm-get-next-pcs.h: Rename include guard.
* arch/amd64.h: Add include guard.
* arch/aarch64-insn.h: Rename include guard.
* arch-utils.h: Rename include guard.
* annotate.h: Add include guard.
* amd64-darwin-tdep.h: Rename include guard.
* aarch64-linux-tdep.h: Add include guard.
* aarch64-fbsd-tdep.h: Add include guard.
* aarch32-linux-nat.h: Add include guard.
gdb/gdbserver/ChangeLog
2019-02-07 Tom Tromey <tom@tromey.com>
* x86-tdesc.h: Rename include guard.
* x86-low.h: Add include guard.
* wincecompat.h: Rename include guard.
* win32-low.h: Add include guard.
* utils.h: Rename include guard.
* tracepoint.h: Rename include guard.
* tdesc.h: Rename include guard.
* target.h: Rename include guard.
* server.h: Rename include guard.
* remote-utils.h: Rename include guard.
* regcache.h: Rename include guard.
* nto-low.h: Rename include guard.
* notif.h: Add include guard.
* mem-break.h: Rename include guard.
* lynx-low.h: Add include guard.
* linux-x86-tdesc.h: Add include guard.
* linux-s390-tdesc.h: Add include guard.
* linux-ppc-tdesc-init.h: Add include guard.
* linux-low.h: Add include guard.
* linux-aarch64-tdesc.h: Add include guard.
* linux-aarch32-low.h: Add include guard.
* inferiors.h: Rename include guard.
* i387-fp.h: Rename include guard.
* hostio.h: Rename include guard.
* gdbthread.h: Rename include guard.
* gdb_proc_service.h: Rename include guard.
* event-loop.h: Rename include guard.
* dll.h: Rename include guard.
* debug.h: Rename include guard.
* ax.h: Rename include guard.
PR python/23615 points out that gdb.execute_gdb_command does not
release the Python GIL. This means that, while the gdb command is
running, other Python threads do not run.
This patch solves the problem by introducing a new RAII class that can
be used to temporarily release and then re-acquire the GIL, then puts
this into the appropriate places in execute_gdb_command and
gdbpy_parse_and_eval.
This does not include a test case, because after some research I could
not find a way to write one that was not racy.
gdb/ChangeLog
2019-01-30 Tom Tromey <tom@tromey.com>
PR python/23615:
* python/python.c (execute_gdb_command): Use gdbpy_allow_threads.
(gdbpy_parse_and_eval): Likewise.
* python/python-internal.h (gdbpy_allow_threads): New class.
This introduces a new class that wraps PyErr_Fetch and PyErr_Restore,
and then changes all the callers in gdb to use it. This reduces the
amount of explicit reference counting that is done in the Python code.
I also found and fixed a latent bug in gdbpy_print_stack -- it was not
correctly checking some error conditions, nor clearing the exception
when needed.
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/python.c (gdbpy_enter, ~gdbpy_enter): Update.
(gdbpy_print_stack): Use gdbpy_err_fetch.
* python/python-internal.h (class gdbpy_err_fetch): New class.
(class gdbpy_enter) <m_error_type, m_error_value,
m_error_traceback>: Remove.
<m_error>: New member.
(gdbpy_exception_to_string): Don't declare.
* python/py-varobj.c (py_varobj_iter_next): Use gdbpy_err_fetch.
* python/py-value.c (convert_value_from_python): Use
gdbpy_err_fetch.
* python/py-utils.c (gdbpy_err_fetch::to_string): Rename from
gdbpy_exception_to_string.
(gdbpy_handle_exception): Use gdbpy_err_fetch.
* python/py-prettyprint.c (print_stack_unless_memory_error): Use
gdbpy_err_fetch.
Most callers of inferior_to_inferior_object already use a gdbpy_ref,
so this changes inferior_to_inferior_object to return one. Doing this
revealed that create_thread_object was not correctly handling the case
where inferior_to_inferior_object failed, so this patch fixes this as
well.
gdb/ChangeLog
2019-01-02 Tom Tromey <tom@tromey.com>
* python/python-internal.h (inferior_to_inferior_object): Change
return type.
* python/py-exitedevent.c (create_exited_event_object): Update.
* python/py-inferior.c (inferior_to_inferior_object): Return
gdbpy_ref.
(python_new_inferior, python_inferior_deleted)
(thread_to_thread_object, delete_thread_object)
(build_inferior_list, gdbpy_selected_inferior): Update.
* python/py-infthread.c (create_thread_object): Update. Also fail
if inferior_to_inferior_object fails.
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
A few places in the Python code would either call gdbpy_print_stack,
or throw a gdb "quit", depending on the pending exception. This patch
consolidates these into a helper function.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* python/python-internal.h (gdbpy_print_stack_or_quit): Declare.
* python/py-unwind.c (pyuw_sniffer): Use
gdbpy_print_stack_or_quit.
* python/py-framefilter.c (throw_quit_or_print_exception):
Remove.
(gdbpy_apply_frame_filter): Use gdbpy_print_stack_or_quit.
* python/python.c (gdbpy_print_stack_or_quit): New function.
I noticed two nearly identical copies of the same code for handling
gdb.GdbError. The only differences were in some error messages.
These differences didn't seem very important, so this patch pulls the
code out into a new function.
2018-09-23 Tom Tromey <tom@tromey.com>
* python/py-function.c (fnpy_call): Use gdbpy_handle_exception.
* python/py-cmd.c (cmdpy_function): Use gdbpy_handle_exception.
* python/python-internal.h (gdbpy_handle_exception): Declare.
* python/py-utils.c (gdbpy_handle_exception): New function.
Some Python APIs steal references from their caller, and the refcount
checker supports this via an attribute.
However, in gdb with C++ we have a better idiom available: we can use
std::move on a gdbpy_ref<> instead. This makes the semantics obvious
at the point of call, and is safer at runtime as well, because the
callee's gdbpy_ref<> will be emptied.
This patch changes the reference-stealing code in gdb to use rvalue
references instead.
Tested on x86-64 Fedora 28.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/python-internal.h (CPYCHECKER_STEALS_REFERENCE_TO_ARG):
Remove.
* python/py-varobj.c (py_varobj_iter_ctor): Change pyiter to
rvalue reference. Remove CPYCHECKER_STEALS_REFERENCE_TO_ARG.
(py_varobj_iter_new): Likewise.
(py_varobj_get_iterator): Use gdbpy_ref.
CPYCHECKER_RETURNS_BORROWED_REF is not used, and I think should never
be used. This patch removes it.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/python-internal.h (CPYCHECKER_RETURNS_BORROWED_REF):
Remove.
