Just like the title says... I think this makes things a bit clearer, for
instance where the exec filename is set. It also makes the read call
sites a bit nicer, avoiding the `.get ()`.
Change-Id: If8b58ae8f6270c8a34b868f6ca06128c6671ea3c
Approved-By: Tom Tromey <tom@tromey.com>
Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them. Remove all the inclusions of these files I could find. Update
the generation scripts where relevant.
Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
Approved-By: Pedro Alves <pedro@palves.net>
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
I noticed that it is possible for the user to create a new
gdb.Progspace object, like this:
(gdb) pi
>>> p = gdb.Progspace()
>>> p
<gdb.Progspace object at 0x7ffad4219c10>
>>> p.is_valid()
False
As the new gdb.Progspace object is not associated with an actual C++
program_space object within GDB core, then the new gdb.Progspace is
created invalid, and there is no way in which the new object can ever
become valid.
Nor do I believe there's anywhere in the Python API where it makes
sense to consume an invalid gdb.Progspace created in this way, for
example, the gdb.Progspace could be passed as the locus to
register_type_printer, but all that would happen is that the
registered printer would never be used.
In this commit I propose to remove the ability to create new
gdb.Progspace objects. Attempting to do so now gives an error, like
this:
(gdb) pi
>>> gdb.Progspace()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot create 'gdb.Progspace' instances
Of course, there is a small risk here that some existing user code
might break ... but if that happens I don't believe the user code can
have been doing anything useful, so I see this as a small risk.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
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>
This function is just a wrapper around the current inferior's gdbarch.
I find that having that wrapper just obscures where the arch is coming
from, and that it's often used as "I don't know which arch to use so
I'll use this magical target_gdbarch function that gets me an arch" when
the arch should in fact come from something in the context (a thread,
objfile, symbol, etc). I think that removing it and inlining
`current_inferior ()->arch ()` everywhere will make it a bit clearer
where that arch comes from and will trigger people into reflecting
whether this is the right place to get the arch or not.
Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
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>
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>
Add a new Progspace.executable_filename attribute that contains the
path to the executable for this program space, or None if no
executable is set.
The path within this attribute will be set by the "exec-file" and/or
"file" commands.
Accessing this attribute for an invalid program space will raise an
exception.
This new attribute is similar too, but not the same as the existing
gdb.Progspace.filename attribute. If I could change the past, I'd
change the 'filename' attribute to 'symbol_filename', which is what it
actually represents. The old attribute will be set by the
'symbol-file' command, while the new attribute is set by the
'exec-file' command. Obviously the 'file' command sets both of these
attributes.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Add a new Progspace.symbol_file attribute. This attribute holds the
gdb.Objfile object that corresponds to Progspace.filename, or None if
there is no main symbol file currently set.
Currently, to get this gdb.Objfile, a user would need to use
Progspace.objfiles, and then search for the objfile with a name that
matches Progspace.filename -- which should work just fine, but having
direct access seems a little nicer.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Extend the description for Progspace.filename in the documentation to
mention what the returned string is actually the filename
for (e.g. that it is the filename passed to the 'symbol-file' or
'file' command).
Also document that this attribute will be None if no symbol file is
currently loaded.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
This adds a new objfile_for_address method to gdb.Progspace. This
makes it easy to find the objfile for a given address.
There's a related PR; and while this change would have been sufficient
for my original need, it's not clear to me whether I should close the
bug. Nevertheless I think it makes sense to at least mention it here.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19288
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Currently, when we add a new python sub-system to GDB,
e.g. py-inferior.c, we end up having to create a new function like
gdbpy_initialize_inferior, which then has to be called from the
function do_start_initialization in python.c.
In some cases (py-micmd.c and py-tui.c), we have two functions
gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called
from finalize_python which is also in python.c.
This commit proposes a mechanism to manage these initialization and
finalization calls, this means that adding a new Python subsystem will
no longer require changes to python.c or python-internal.h, instead,
the initialization and finalization functions will be registered
directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c.
The initialization and finalization functions are managed through a
new class gdbpy_initialize_file in python-internal.h. This class
contains a single global vector of all the initialization and
finalization functions.
In each Python sub-system we create a new gdbpy_initialize_file
object, the object constructor takes care of registering the two
callback functions.
Now from python.c we can call static functions on the
gdbpy_initialize_file class which take care of walking the callback
list and invoking each callback in turn.
To slightly simplify the Python sub-system files I added a new macro
GDBPY_INITIALIZE_FILE, which hides the need to create an object. We
can now just do this:
GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers);
One possible problem with this change is that there is now no
guaranteed ordering of how the various sub-systems are initialized (or
finalized). To try and avoid dependencies creeping in I have added a
use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is
the same environment variable used in the generated init.c file.
Just like with init.c, when this environment variable is set we
reverse the list of Python initialization (and finalization)
functions. As there is already a test that starts GDB with the
environment variable set then this should offer some level of
protection against dependencies creeping in - though for full
protection I guess we'd need to run all gdb.python/*.exp tests with
the variable set.
I have tested this patch with the environment variable set, and saw no
regressions, so I think we are fine right now.
One other change of note was for gdbpy_initialize_gdb_readline, this
function previously returned void. In order to make this function
have the correct signature I've updated its return type to int, and we
now return 0 to indicate success.
All of the other initialize (and finalize) functions have been made
static within their respective sub-system files.
There should be no user visible changes after this commit.
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
This rewrites registry.h, removing all the macros and replacing it
with relatively ordinary template classes. The result is less code
than the previous setup. It replaces large macros with a relatively
straightforward C++ class, and now manages its own cleanup.
The existing type-safe "key" class is replaced with the equivalent
template class. This approach ended up requiring relatively few
changes to the users of the registry code in gdb -- code using the key
system just required a small change to the key's declaration.
All existing users of the old C-like API are now converted to use the
type-safe API. This mostly involved changing explicit deletion
functions to be an operator() in a deleter class.
The old "save/free" two-phase process is removed, and replaced with a
single "free" phase. No existing code used both phases.
The old "free" callbacks took a parameter for the enclosing container
object. However, this wasn't truly needed and is removed here as
well.
PR python/27000 points out that gdb.block_for_pc will accept a Python
integer, but not a gdb.Value. This patch corrects this oversight.
I looked at all uses of GDB_PY_LLU_ARG and fixed these up to use
get_addr_from_python instead. I also looked at uses of GDB_PY_LL_ARG,
but those seemed relatively unlikely to be useful with a gdb.Value, so
I didn't change them. My thinking here is that a Value will typically
come from inferior memory, and something like a line number is not too
likely to be found this way.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27000
I noticed that solib_name_from_address returned a non-const string,
but it's more appropriate to return const. This patch implements
this. Tested by rebuilding.
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.
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.
Delay Python initialisation until gdbpy_finish_initialization.
This is mostly about splitting the existing gdbpy_initialize_*
functions in two, all the calls to register_objfile_data_with_cleanup,
gdbarch_data_register_post_init, etc are moved into new _initialize_*
functions, but everything else is left in the gdbpy_initialize_*
functions.
Then the call to do_start_initialization (in python/python.c) is moved
from the _initialize_python function into gdbpy_finish_initialization.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* python/py-arch.c (_initialize_py_arch): New function.
(gdbpy_initialize_arch): Move code to _initialize_py_arch.
* python/py-block.c (_initialize_py_block): New function.
(gdbpy_initialize_blocks): Move code to _initialize_py_block.
* python/py-inferior.c (_initialize_py_inferior): New function.
(gdbpy_initialize_inferior): Move code to _initialize_py_inferior.
* python/py-objfile.c (_initialize_py_objfile): New function.
(gdbpy_initialize_objfile): Move code to _initialize_py_objfile.
* python/py-progspace.c (_initialize_py_progspace): New function.
(gdbpy_initialize_pspace): Move code to _initialize_py_progspace.
* python/py-registers.c (_initialize_py_registers): New function.
(gdbpy_initialize_registers): Move code to
_initialize_py_registers.
* python/py-symbol.c (_initialize_py_symbol): New function.
(gdbpy_initialize_symbols): Move code to _initialize_py_symbol.
* python/py-symtab.c (_initialize_py_symtab): New function.
(gdbpy_initialize_symtabs): Move code to _initialize_py_symtab.
* python/py-type.c (_initialize_py_type): New function.
(gdbpy_initialize_types): Move code to _initialize_py_type.
* python/py-unwind.c (_initialize_py_unwind): New function.
(gdbpy_initialize_unwind): Move code to _initialize_py_unwind.
* python/python.c (_initialize_python): Move call to
do_start_initialization to gdbpy_finish_initialization.
(gdbpy_finish_initialization): Add call to
do_start_initialization.
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.
The documentation for Progspace.block_for_pc says:
Return the innermost gdb.Block containing the given pc value. If the
block cannot be found for the pc value specified, the function will
return None.
However, the implementation actually throws an error for invalid
addresses, like this:
(gdb) python print gdb.current_progspace ().block_for_pc (1)
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Cannot locate object file for block.
Error while executing Python code.
(gdb)
This has been the behaviour since the command was first added (when
the documentation was still as above) in this commit:
commit f3e9a8177c
Date: Wed Feb 24 21:18:28 2010 +0000
Since that commit the code in question has moved around, but the
important parts are largely unchanged. The function in question is
now in py-progspace.c:pspy_block_for_pc.
Examining the code shows that the real state is more complex than just
the function throws an error instead of returning None, instead the
real situation is:
1. If we can't find a compilation unit for the $pc value then we
throw an error, but
2. If we can find a compilation unit, but can't find a block within
the compilation unit for the $pc then return None.
I suspect for most users of the Python API this distinction is
irrelevant, and I propose that we standardise on one single failure
mechanism.
Given the function can currently return None in some cases, and is
documented to return None on error, I propose we make that the case
for all error paths, which is what this patch does.
As the Progspace.block_for_pc method is currently untested, I've added
some basic tests including for a call with an invalid $pc.
This is potentially an API breaking change, though an undocumented
part of the API. Also, users should have been checking and handling a
None return value anyway, so my hope is that this shouldn't be too
disruptive.
gdb/ChangeLog:
* python/py-progspace.c (pspy_block_for_pc): Return None for all
error paths.
gdb/testsuite/ChangeLog:
* gdb.python/py-progspace.exp: Add tests for the
Progspace.block_for_pc method.
Change-Id: I9cea8d2132902bcad0013d1fd39080dd5423cc57
This rewrites gdb's TRY/CATCH to plain C++ try/catch. The patch was
largely written by script, though one change (to a comment in
common-exceptions.h) was reverted by hand.
gdb/ChangeLog
2019-04-08 Tom Tromey <tom@tromey.com>
* xml-support.c: Use C++ exception handling.
* x86-linux-nat.c: Use C++ exception handling.
* windows-nat.c: Use C++ exception handling.
* varobj.c: Use C++ exception handling.
* value.c: Use C++ exception handling.
* valprint.c: Use C++ exception handling.
* valops.c: Use C++ exception handling.
* unittests/parse-connection-spec-selftests.c: Use C++ exception
handling.
* unittests/cli-utils-selftests.c: Use C++ exception handling.
* typeprint.c: Use C++ exception handling.
* tui/tui.c: Use C++ exception handling.
* tracefile-tfile.c: Use C++ exception handling.
* top.c: Use C++ exception handling.
* thread.c: Use C++ exception handling.
* target.c: Use C++ exception handling.
* symmisc.c: Use C++ exception handling.
* symfile-mem.c: Use C++ exception handling.
* stack.c: Use C++ exception handling.
* sparc64-linux-tdep.c: Use C++ exception handling.
* solib.c: Use C++ exception handling.
* solib-svr4.c: Use C++ exception handling.
* solib-spu.c: Use C++ exception handling.
* solib-frv.c: Use C++ exception handling.
* solib-dsbt.c: Use C++ exception handling.
* selftest-arch.c: Use C++ exception handling.
* s390-tdep.c: Use C++ exception handling.
* rust-lang.c: Use C++ exception handling.
* rust-exp.y: Use C++ exception handling.
* rs6000-tdep.c: Use C++ exception handling.
* rs6000-aix-tdep.c: Use C++ exception handling.
* riscv-tdep.c: Use C++ exception handling.
* remote.c: Use C++ exception handling.
* remote-fileio.c: Use C++ exception handling.
* record-full.c: Use C++ exception handling.
* record-btrace.c: Use C++ exception handling.
* python/python.c: Use C++ exception handling.
* python/py-value.c: Use C++ exception handling.
* python/py-utils.c: Use C++ exception handling.
* python/py-unwind.c: Use C++ exception handling.
* python/py-type.c: Use C++ exception handling.
* python/py-symbol.c: Use C++ exception handling.
* python/py-record.c: Use C++ exception handling.
* python/py-record-btrace.c: Use C++ exception handling.
* python/py-progspace.c: Use C++ exception handling.
* python/py-prettyprint.c: Use C++ exception handling.
* python/py-param.c: Use C++ exception handling.
* python/py-objfile.c: Use C++ exception handling.
* python/py-linetable.c: Use C++ exception handling.
* python/py-lazy-string.c: Use C++ exception handling.
* python/py-infthread.c: Use C++ exception handling.
* python/py-inferior.c: Use C++ exception handling.
* python/py-gdb-readline.c: Use C++ exception handling.
* python/py-framefilter.c: Use C++ exception handling.
* python/py-frame.c: Use C++ exception handling.
* python/py-finishbreakpoint.c: Use C++ exception handling.
* python/py-cmd.c: Use C++ exception handling.
* python/py-breakpoint.c: Use C++ exception handling.
* python/py-arch.c: Use C++ exception handling.
* printcmd.c: Use C++ exception handling.
* ppc-linux-tdep.c: Use C++ exception handling.
* parse.c: Use C++ exception handling.
* p-valprint.c: Use C++ exception handling.
* objc-lang.c: Use C++ exception handling.
* mi/mi-main.c: Use C++ exception handling.
* mi/mi-interp.c: Use C++ exception handling.
* mi/mi-cmd-stack.c: Use C++ exception handling.
* mi/mi-cmd-break.c: Use C++ exception handling.
* main.c: Use C++ exception handling.
* linux-thread-db.c: Use C++ exception handling.
* linux-tdep.c: Use C++ exception handling.
* linux-nat.c: Use C++ exception handling.
* linux-fork.c: Use C++ exception handling.
* linespec.c: Use C++ exception handling.
* language.c: Use C++ exception handling.
* jit.c: Use C++ exception handling.
* infrun.c: Use C++ exception handling.
* infcmd.c: Use C++ exception handling.
* infcall.c: Use C++ exception handling.
* inf-loop.c: Use C++ exception handling.
* i386-tdep.c: Use C++ exception handling.
* i386-linux-tdep.c: Use C++ exception handling.
* guile/scm-value.c: Use C++ exception handling.
* guile/scm-type.c: Use C++ exception handling.
* guile/scm-symtab.c: Use C++ exception handling.
* guile/scm-symbol.c: Use C++ exception handling.
* guile/scm-pretty-print.c: Use C++ exception handling.
* guile/scm-ports.c: Use C++ exception handling.
* guile/scm-param.c: Use C++ exception handling.
* guile/scm-math.c: Use C++ exception handling.
* guile/scm-lazy-string.c: Use C++ exception handling.
* guile/scm-frame.c: Use C++ exception handling.
* guile/scm-disasm.c: Use C++ exception handling.
* guile/scm-cmd.c: Use C++ exception handling.
* guile/scm-breakpoint.c: Use C++ exception handling.
* guile/scm-block.c: Use C++ exception handling.
* guile/guile-internal.h: Use C++ exception handling.
* gnu-v3-abi.c: Use C++ exception handling.
* gdbtypes.c: Use C++ exception handling.
* frame.c: Use C++ exception handling.
* frame-unwind.c: Use C++ exception handling.
* fbsd-tdep.c: Use C++ exception handling.
* f-valprint.c: Use C++ exception handling.
* exec.c: Use C++ exception handling.
* event-top.c: Use C++ exception handling.
* event-loop.c: Use C++ exception handling.
* eval.c: Use C++ exception handling.
* dwarf2read.c: Use C++ exception handling.
* dwarf2loc.c: Use C++ exception handling.
* dwarf2-frame.c: Use C++ exception handling.
* dwarf2-frame-tailcall.c: Use C++ exception handling.
* dwarf-index-write.c: Use C++ exception handling.
* dwarf-index-cache.c: Use C++ exception handling.
* dtrace-probe.c: Use C++ exception handling.
* disasm-selftests.c: Use C++ exception handling.
* darwin-nat.c: Use C++ exception handling.
* cp-valprint.c: Use C++ exception handling.
* cp-support.c: Use C++ exception handling.
* cp-abi.c: Use C++ exception handling.
* corelow.c: Use C++ exception handling.
* completer.c: Use C++ exception handling.
* compile/compile-object-run.c: Use C++ exception handling.
* compile/compile-object-load.c: Use C++ exception handling.
* compile/compile-cplus-symbols.c: Use C++ exception handling.
* compile/compile-c-symbols.c: Use C++ exception handling.
* common/selftest.c: Use C++ exception handling.
* common/new-op.c: Use C++ exception handling.
* cli/cli-script.c: Use C++ exception handling.
* cli/cli-interp.c: Use C++ exception handling.
* cli/cli-cmds.c: Use C++ exception handling.
* c-varobj.c: Use C++ exception handling.
* btrace.c: Use C++ exception handling.
* breakpoint.c: Use C++ exception handling.
* break-catch-throw.c: Use C++ exception handling.
* arch-utils.c: Use C++ exception handling.
* amd64-tdep.c: Use C++ exception handling.
* ada-valprint.c: Use C++ exception handling.
* ada-typeprint.c: Use C++ exception handling.
* ada-lang.c: Use C++ exception handling.
* aarch64-tdep.c: Use C++ exception handling.
gdb/gdbserver/ChangeLog
2019-04-08 Tom Tromey <tom@tromey.com>
* server.c: Use C++ exception handling.
* linux-low.c: Use C++ exception handling.
* gdbreplay.c: Use C++ exception handling.
py-ref.h can really only be included from a specific spot in
python-internal.h. The other includes are not useful, and cause
compilation errors if the includes are ever sorted. So, remove these
includes.
Arguably, py-ref.h should simply not be a separate header.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* python/py-arch.c: Do not include py-ref.h.
* python/py-bpevent.c: Do not include py-ref.h.
* python/py-cmd.c: Do not include py-ref.h.
* python/py-continueevent.c: Do not include py-ref.h.
* python/py-event.h: Do not include py-ref.h.
* python/py-evtregistry.c: Do not include py-ref.h.
* python/py-finishbreakpoint.c: Do not include py-ref.h.
* python/py-frame.c: Do not include py-ref.h.
* python/py-framefilter.c: Do not include py-ref.h.
* python/py-function.c: Do not include py-ref.h.
* python/py-infevents.c: Do not include py-ref.h.
* python/py-linetable.c: Do not include py-ref.h.
* python/py-objfile.c: Do not include py-ref.h.
* python/py-param.c: Do not include py-ref.h.
* python/py-prettyprint.c: Do not include py-ref.h.
* python/py-progspace.c: Do not include py-ref.h.
* python/py-symbol.c: Do not include py-ref.h.
* python/py-symtab.c: Do not include py-ref.h.
* python/py-type.c: Do not include py-ref.h.
* python/py-unwind.c: Do not include py-ref.h.
* python/py-utils.c: Do not include py-ref.h.
* python/py-value.c: Do not include py-ref.h.
* python/py-varobj.c: Do not include py-ref.h.
* python/py-xmethods.c: Do not include py-ref.h.
* python/python.c: Do not include py-ref.h.
* varobj.c: Do not include py-ref.h.
This removes the ALL_PSPACE_OBJFILES macro in favor of ranged for
loops.
gdb/ChangeLog
2019-01-09 Tom Tromey <tom@tromey.com>
* probe.c (parse_probes_in_pspace): Use all_objfiles.
* guile/scm-progspace.c (gdbscm_progspace_objfiles): Use
all_objfiles.
* objfiles.h (ALL_PSPACE_OBJFILES): Remove.
* symmisc.c (print_symbol_bcache_statistics)
(print_objfile_statistics, maintenance_print_objfiles)
(maintenance_info_symtabs, maintenance_check_symtabs)
(maintenance_expand_symtabs, maintenance_info_line_tables): Use
all_objfiles.
* source.c (forget_cached_source_info): Use all_objfiles.
* symfile-debug.c (set_debug_symfile): Use all_objfiles.
* elfread.c (elf_gnu_ifunc_resolve_by_cache)
(elf_gnu_ifunc_resolve_by_got): Use all_objfiles.
* objfiles.c (update_section_map): Use all_objfiles.
(shared_objfile_contains_address_p): Likewise.
* psymtab.c (maintenance_info_psymtabs): Use all_objfiles.
* python/py-progspace.c (pspy_get_objfiles): Use all_objfiles.
This changes some more place in the Python code to use gdbpy_ref
rather than explicit reference counting. While doing this I found a
latent bug in typy_fields_items -- it was not checking for errors in
one spot. I also changed valpy_dealloc to use Py_XDECREF rather than
an explicit "if".
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/py-value.c (valpy_dealloc): Use Py_XDECREF.
* python/py-type.c (typy_fields_items): Use gdbpy_ref.
* python/py-progspace.c (pspy_set_printers): Use gdbpy_ref.
(pspy_set_frame_filters, pspy_set_frame_unwinders)
(pspy_set_type_printers): Likewise.
* python/py-function.c (fnpy_init): Use gdbpy_ref.
* python/py-cmd.c (cmdpy_init): Use gdbpy_ref.
* python/py-objfile.c (objfpy_set_printers): Use gdbpy_ref.
(objfpy_set_frame_filters, objfpy_set_frame_unwinders)
(objfpy_set_type_printers): Likewise.
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.
When using cpychecker, we run into:
...
gdb/python/py-progspace.c: \
In function ‘PyObject* pspy_solib_name(PyObject*, PyObject*)’:
gdb/python/py-progspace.c:370:25: error: Mismatching type in call to \
PyArg_ParseTuple with format code "K" [-Werror]
if (!PyArg_ParseTuple (args, GDB_PY_LLU_ARG, &pc))
argument 3 ("&pc") had type
"gdb_py_longest *" (pointing to 64 bits)
but was expecting
"long long unsigned int *" (pointing to 64 bits)
for format code "K"
...
Fix this fixing the type of the variable.
Build and reg-tested on x86_64-linux.
2018-10-05 Tom de Vries <tdevries@suse.de>
* python/py-progspace.c (pspy_solib_name): Fix type mismatch in
PyArg_ParseTuple call.
This changes pspace_to_pspace_object to return a new reference and
fixes up all the callers.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/py-inferior.c (infpy_get_progspace): Update.
* python/python-internal.h (pspace_to_pspace_object): Change
return type.
* python/py-newobjfileevent.c
(create_clear_objfiles_event_object): Update.
* python/py-xmethods.c (gdbpy_get_matching_xmethod_workers):
Update.
* python/python.c (gdbpy_get_current_progspace): Update.
(gdbpy_progspaces): Update.
* python/py-progspace.c (pspace_to_pspace_object): Return a new
reference.
* python/py-objfile.c (objfpy_get_progspace): Update.
* python/py-prettyprint.c (find_pretty_printer_from_progspace):
Update.
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.
This patch adds an objfiles method to the Progspace object, which
returns a sequence of the objfiles associated to that program space. I
chose a method rather than a property for symmetry with gdb.objfiles().
gdb/ChangeLog:
* python/py-progspace.c (PSPY_REQUIRE_VALID): New macro.
(pspy_get_objfiles): New function.
(progspace_object_methods): New.
(pspace_object_type): Add tp_methods callback.
* python/python-internal.h (build_objfiles_list): New
declaration.
* python/python.c (build_objfiles_list): New function.
(gdbpy_objfiles): Implement using build_objfiles_list.
* NEWS: Mention the Progspace.objfiles method.
gdb/doc/ChangeLog:
* python.texi (Program Spaces In Python): Document the
Progspace.objfiles method.
(Objfiles In Python): Mention that gdb.objfiles() is identical
to gdb.selected_inferior().progspace.objfiles().
gdb/testsuite/ChangeLog:
* gdb.python/py-progspace.exp: Test the Progspace.objfiles
method.
Unfortunately, PyGetSetDef's 'name' and 'doc' members are 'char *'
instead of 'const char *', meaning that in order to list-initialize
PyGetSetDef arrays using string literals requires writing explicit
'char *' casts. For example:
static PyGetSetDef value_object_getset[] = {
- { "address", valpy_get_address, NULL, "The address of the value.",
+ { (char *) "address", valpy_get_address, NULL,
+ (char *) "The address of the value.",
NULL },
- { "is_optimized_out", valpy_get_is_optimized_out, NULL,
- "Boolean telling whether the value is optimized "
+ { (char *) "is_optimized_out", valpy_get_is_optimized_out, NULL,
+ (char *) "Boolean telling whether the value is optimized "
"out (i.e., not available).",
NULL },
- { "type", valpy_get_type, NULL, "Type of the value.", NULL },
- { "dynamic_type", valpy_get_dynamic_type, NULL,
- "Dynamic type of the value.", NULL },
- { "is_lazy", valpy_get_is_lazy, NULL,
- "Boolean telling whether the value is lazy (not fetched yet\n\
+ { (char *) "type", valpy_get_type, NULL,
+ (char *) "Type of the value.", NULL },
+ { (char *) "dynamic_type", valpy_get_dynamic_type, NULL,
+ (char *) "Dynamic type of the value.", NULL },
+ { (char *) "is_lazy", valpy_get_is_lazy, NULL,
+ (char *) "Boolean telling whether the value is lazy (not fetched yet\n\
from the inferior). A lazy value is fetched when needed, or when\n\
the \"fetch_lazy()\" method is called.", NULL },
{NULL} /* Sentinel */
We have ~20 such arrays, and I first wrote a patch that fixed all of
them like that... It's not pretty...
One way to make these a bit less ugly would be add a new macro that
hides the casts, like:
#define GDBPY_GSDEF(NAME, GET, SET, DOC, CLOSURE) \
{ (char *) NAME, GET, SET, (char *) DOC, CLOSURE }
and then use it like:
static PyGetSetDef value_object_getset[] = {
GDBPY_GSDEF ("address", valpy_get_address, NULL,
"The address of the value.", NULL),
GDBPY_GSDEF ("is_optimized_out", valpy_get_is_optimized_out, NULL,
"Boolean telling whether the value is optimized ", NULL),
{NULL} /* Sentinel */
};
But since we have C++11, which gives us constexpr and list
initialization, I thought of a way that requires no changes where the
arrays are initialized:
We add a new type that extends PyGetSetDef (called gdb_PyGetSetDef),
and add constexpr constructors that accept const 'name' and 'doc', and
then list/aggregate initialization simply "calls" these matching
constructors instead.
I put "calls" in quotes, because given "constexpr", it's all done at
compile time, and there's no overhead either in binary size or at run
time. In fact, we get identical binaries, before/after this change.
Unlike the fixes that fix some old Python API to match the API of more
recent Python, this switches to using explicit "gdb_PyGetSetDef"
everywhere, just to be clear that we are using our own version of it.
gdb/ChangeLog:
2017-04-05 Pedro Alves <palves@redhat.com>
* python/python-internal.h (gdb_PyGetSetDef): New type.
* python/py-block.c (block_object_getset)
(breakpoint_object_getset): Now a gdb_PyGetSetDef array.
* python/py-event.c (event_object_getset)
(finish_breakpoint_object_getset): Likewise.
* python/py-inferior.c (inferior_object_getset): Likewise.
* python/py-infthread.c (thread_object_getset): Likewise.
* python/py-lazy-string.c (lazy_string_object_getset): Likewise.
* python/py-linetable.c (linetable_entry_object_getset): Likewise.
* python/py-objfile.c (objfile_getset): Likewise.
* python/py-progspace.c (pspace_getset): Likewise.
* python/py-record-btrace.c (btpy_insn_getset, btpy_call_getset):
Likewise.
* python/py-record.c (recpy_record_getset): Likewise.
* python/py-symbol.c (symbol_object_getset): Likewise.
* python/py-symtab.c (symtab_object_getset, sal_object_getset):
Likewise.
* python/py-type.c (type_object_getset, field_object_getset):
Likewise.
* python/py-value.c (value_object_getset): Likewise.
This uses the new gdbpy_ref template to simplify logic in various
parts of the Python layer; for example removing repeated error code or
removing gotos.
gdb/ChangeLog
2017-02-10 Tom Tromey <tom@tromey.com>
* python/py-cmd.c (cmdpy_destroyer): Use gdbpy_ref.
* python/py-breakpoint.c (gdbpy_breakpoint_deleted): Use
gdbpy_ref.
* python/py-type.c (field_new): Use gdbpy_ref.
* python/py-symtab.c (symtab_and_line_to_sal_object): Use
gdbpy_ref.
* python/py-progspace.c (pspy_new): Use gdbpy_ref.
(py_free_pspace): Likewise.
(pspace_to_pspace_object): Likewise.
* python/py-objfile.c (objfpy_new): Use gdbpy_ref.
(py_free_objfile): Likewise.
(objfile_to_objfile_object): Likewise.
* python/py-inferior.c (delete_thread_object): Use
gdbpy_ref.
(infpy_read_memory): Likewise.
(py_free_inferior): Likewise.
* python/py-evtregistry.c (create_eventregistry_object): Use
gdbpy_ref.
* python/py-event.c (create_event_object): Use gdbpy_ref.
This applies the second part of GDB's End of Year Procedure, which
updates the copyright year range in all of GDB's files.
gdb/ChangeLog:
Update copyright year range in all GDB files.
This fixes PR python/19438 and PR python/18393. Both bugs are about
invoking dir() on some Python object implemented by gdb, and getting a
crash.
The crash happens because the dictionary field of these objects was
not initialized. Apparently what happens is that this field can be
lazily initialized by Python when assigning to an attribute; and it
can also be handled ok when using dir() but without __dict__ defined;
but gdb defines __dict__ because this isn't supplied automatically by
Python.
The docs on this seem rather sparse, but this patch works ok.
An alternative might be to lazily create the dictionary in
gdb_py_generic_dict, but I went with this approach because it seemed
more straightforward.
Built and regtested on x86-64 Fedora 23.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/19438, PR python/18393:
* python/py-objfile.c (objfpy_initialize): Initialize self->dict.
* python/py-progspace.c (pspy_initialize): Initialize self->dict.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/19438, PR python/18393:
* gdb.python/py-progspace.exp: Add "dir" test.
* gdb.python/py-objfile.exp: Add "dir" test.
gdb/ChangeLog:
* python/py-utils.c (host_string_to_python_string): New function.
* python/python-internal.h (host_string_to_python_string): Declare it.
* python/py-*.c (*): Update all calls to
PyString_Decode (str, strlen (str), host_charset (), NULL);
to use host_string_to_python_string instead.
In C, we can forward declare static structure instances. That doesn't
work in C++ though. C++ treats these as definitions. So then the
compiler complains about symbol redefinition, like:
src/gdb/elfread.c:1569:29: error: redefinition of ‘const sym_fns elf_sym_fns_lazy_psyms’
src/gdb/elfread.c:53:29: error: ‘const sym_fns elf_sym_fns_lazy_psyms’ previously declared here
The intent of static here is naturally to avoid making these objects
visible outside the compilation unit. The equivalent in C++ would be
to instead define the objects in the anonymous namespace. But given
that it's desirable to leave the codebase compiling as both C and C++
for a while, this just makes the objects extern.
(base_breakpoint_ops is already declared in breakpoint.h, so we can
just remove the forward declare from breakpoint.c)
gdb/ChangeLog:
2015-02-11 Tom Tromey <tromey@redhat.com>
Pedro Alves <palves@redhat.com>
* breakpoint.c (base_breakpoint_ops): Delete.
* dwarf2loc.c (dwarf_expr_ctx_funcs): Make extern.
* elfread.c (elf_sym_fns_gdb_index, elf_sym_fns_lazy_psyms): Make extern.
* guile/guile.c (guile_extension_script_ops, guile_extension_ops): Make extern.
* ppcnbsd-tdep.c (ppcnbsd2_sigtramp): Make extern.
* python/py-arch.c (arch_object_type): Make extern.
* python/py-block.c (block_syms_iterator_object_type): Make extern.
* python/py-bpevent.c (breakpoint_event_object_type): Make extern.
* python/py-cmd.c (cmdpy_object_type): Make extern.
* python/py-continueevent.c (continue_event_object_type)
* python/py-event.h (GDBPY_NEW_EVENT_TYPE): Remove 'qual'
parameter. Update all callers.
* python/py-evtregistry.c (eventregistry_object_type): Make extern.
* python/py-exitedevent.c (exited_event_object_type): Make extern.
* python/py-finishbreakpoint.c (finish_breakpoint_object_type): Make extern.
* python/py-function.c (fnpy_object_type): Make extern.
* python/py-inferior.c (inferior_object_type, membuf_object_type): Make extern.
* python/py-infevents.c (call_pre_event_object_type)
(inferior_call_post_event_object_type).
(memory_changed_event_object_type): Make extern.
* python/py-infthread.c (thread_object_type): Make extern.
* python/py-lazy-string.c (lazy_string_object_type): Make extern.
* python/py-linetable.c (linetable_entry_object_type)
(linetable_object_type, ltpy_iterator_object_type): Make extern.
* python/py-newobjfileevent.c (new_objfile_event_object_type)
(clear_objfiles_event_object_type): Make extern.
* python/py-objfile.c (objfile_object_type): Make extern.
* python/py-param.c (parmpy_object_type): Make extern.
* python/py-progspace.c (pspace_object_type): Make extern.
* python/py-signalevent.c (signal_event_object_type): Make extern.
* python/py-symtab.c (symtab_object_type, sal_object_type): Make extern.
* python/py-type.c (type_object_type, field_object_type)
(type_iterator_object_type): Make extern.
* python/python.c (python_extension_script_ops)
(python_extension_ops): Make extern.
* stap-probe.c (stap_probe_ops): Make extern.
