b4cf88da83fbbceecdec7ad4e1addddfe2c2b76d
140 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Tom Tromey
|
bcafd1c19e |
Use gdb::checked_static_cast for watchpoints
This replaces some casts to 'watchpoint *' with checked_static_cast. In one spot, an unnecessary block is also removed. Approved-By: Simon Marchi <simon.marchi@efficios.com> |
||
 Andrew Burgess
|
b080fe54fb |
gdb: add inferior-specific breakpoints
This commit extends the breakpoint mechanism to allow for inferior specific breakpoints (but not watchpoints in this commit). As GDB gains better support for multiple connections, and so for running multiple (possibly unrelated) inferiors, then it is not hard to imagine that a user might wish to create breakpoints that apply to any thread in a single inferior. To achieve this currently, the user would need to create a condition possibly making use of the $_inferior convenience variable, which, though functional, isn't the most user friendly. This commit adds a new 'inferior' keyword that allows for the creation of inferior specific breakpoints. Inferior specific breakpoints are automatically deleted when the associated inferior is removed from GDB, this is similar to how thread-specific breakpoints are deleted when the associated thread is deleted. Watchpoints are already per-program-space, which in most cases mean watchpoints are already inferior specific. There is a small window where inferior-specific watchpoints might make sense, which is after a vfork, when two processes are sharing the same address space. However, I'm leaving that as an exercise for another day. For now, attempting to use the inferior keyword with a watchpoint will give an error, like this: (gdb) watch a8 inferior 1 Cannot use 'inferior' keyword with watchpoints A final note on the implementation: currently, inferior specific breakpoints, like thread-specific breakpoints, are inserted into every inferior, GDB then checks once the inferior stops if we are in the correct thread or inferior, and resumes automatically if we stopped in the wrong thread/inferior. An obvious optimisation here is to only insert breakpoint locations into the specific program space (which mostly means inferior) that contains either the inferior or thread we are interested in. This would reduce the number times GDB has to stop and then resume again in a multi-inferior setup. I have a series on the mailing list[1] that implements this optimisation for thread-specific breakpoints. Once this series has landed I'll update that series to also handle inferior specific breakpoints in the same way. For now, inferior specific breakpoints are just slightly less optimal, but this is no different to thread-specific breakpoints in a multi-inferior debug session, so I don't see this as a huge problem. [1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/ |
||
 Matheus Branco Borella
|
bb2bd584f3 |
gdb: add __repr__() implementation to a few Python types
Only a few types in the Python API currently have __repr__()
implementations. This patch adds a few more of them. specifically: it
adds __repr__() implementations to gdb.Symbol, gdb.Architecture,
gdb.Block, gdb.Breakpoint, gdb.BreakpointLocation, and gdb.Type.
This makes it easier to play around the GDB Python API in the Python
interpreter session invoked with the 'pi' command in GDB, giving more
easily accessible tipe information to users.
An example of how this would look like:
(gdb) pi
>> gdb.lookup_type("char")
<gdb.Type code=TYPE_CODE_INT name=char>
>> gdb.lookup_global_symbol("main")
<gdb.Symbol print_name=main>
The gdb.Block.__repr__() method shows the first 5 symbols from the
block, and then a message to show how many more were elided (if any).
|
||
 Simon Marchi
|
a1decfc1df |
gdb: remove breakpoint_pointer_iterator
Remove the breakpoint_pointer_iterator layer. Adjust all users of all_breakpoints and all_tracepoints to use references instead of pointers. Change-Id: I376826f812117cee1e6b199c384a10376973af5d Reviewed-By: Andrew Burgess <aburgess@redhat.com> |
||
|
Simon Marchi
|
b00b30b298 |
gdb: remove bp_location_pointer_iterator
Remove the bp_location_pointer_iterator layer. Adjust all users of breakpoint::locations to use references instead of pointers. Change-Id: Iceed34f5e0f5790a9cf44736aa658be6d1ba1afa Reviewed-By: Andrew Burgess <aburgess@redhat.com> |
||
|
Andrew Burgess
|
3965bff5b9 |
gdb/python: add mechanism to manage Python initialization functions
Currently, when we add a new python sub-system to GDB, e.g. py-inferior.c, we end up having to create a new function like gdbpy_initialize_inferior, which then has to be called from the function do_start_initialization in python.c. In some cases (py-micmd.c and py-tui.c), we have two functions gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called from finalize_python which is also in python.c. This commit proposes a mechanism to manage these initialization and finalization calls, this means that adding a new Python subsystem will no longer require changes to python.c or python-internal.h, instead, the initialization and finalization functions will be registered directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c. The initialization and finalization functions are managed through a new class gdbpy_initialize_file in python-internal.h. This class contains a single global vector of all the initialization and finalization functions. In each Python sub-system we create a new gdbpy_initialize_file object, the object constructor takes care of registering the two callback functions. Now from python.c we can call static functions on the gdbpy_initialize_file class which take care of walking the callback list and invoking each callback in turn. To slightly simplify the Python sub-system files I added a new macro GDBPY_INITIALIZE_FILE, which hides the need to create an object. We can now just do this: GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers); One possible problem with this change is that there is now no guaranteed ordering of how the various sub-systems are initialized (or finalized). To try and avoid dependencies creeping in I have added a use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is the same environment variable used in the generated init.c file. Just like with init.c, when this environment variable is set we reverse the list of Python initialization (and finalization) functions. As there is already a test that starts GDB with the environment variable set then this should offer some level of protection against dependencies creeping in - though for full protection I guess we'd need to run all gdb.python/*.exp tests with the variable set. I have tested this patch with the environment variable set, and saw no regressions, so I think we are fine right now. One other change of note was for gdbpy_initialize_gdb_readline, this function previously returned void. In order to make this function have the correct signature I've updated its return type to int, and we now return 0 to indicate success. All of the other initialize (and finalize) functions have been made static within their respective sub-system files. There should be no user visible changes after this commit. |
||
|
Andrew Burgess
|
2968b79fca |
gdb: fix mi breakpoint-deleted notifications for thread-specific b/p
Background
----------
When a thread-specific breakpoint is deleted as a result of the
specific thread exiting the function remove_threaded_breakpoints is
called which sets the disposition of the breakpoint to
disp_del_at_next_stop and sets the breakpoint number to 0. Setting
the breakpoint number to zero has the effect of hiding the breakpoint
from the user. We also print a message indicating that the breakpoint
has been deleted.
It was brought to my attention during a review of another patch[1]
that setting a breakpoints number to zero will suppress the MI
breakpoint-deleted notification for that breakpoint, and indeed, this
can be seen to be true, in delete_breakpoint, if the breakpoint number
is zero, then GDB will not notify the breakpoint_deleted observer.
It seems wrong that a user created, thread-specific breakpoint, will
have a =breakpoint-created notification, but will not have a
=breakpoint-deleted notification. I suspect that this is a bug.
[1] https://sourceware.org/pipermail/gdb-patches/2023-February/196560.html
The First Problem
-----------------
During my initial testing I wanted to see how GDB handled the
breakpoint after it's number was set to zero. To do this I created
the testcase gdb.threads/thread-bp-deleted.exp. This test creates a
worker thread, which immediately exits. After the worker thread has
exited the main thread spins in a loop.
In GDB I break once the worker thread has been created and place a
thread-specific breakpoint, then use 'continue&' to resume the
inferior in non-stop mode. The worker thread then exits, but the main
thread never stops - instead it sits in the spin. I then tried to use
'maint info breakpoints' to see what GDB thought of the
thread-specific breakpoint.
Unfortunately, GDB crashed like this:
(gdb) continue&
Continuing.
(gdb) [Thread 0x7ffff7c5d700 (LWP 1202458) exited]
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
maint info breakpoints
... snip some output ...
Fatal signal: Segmentation fault
----- Backtrace -----
0x5ffb62 gdb_internal_backtrace_1
../../src/gdb/bt-utils.c:122
0x5ffc05 _Z22gdb_internal_backtracev
../../src/gdb/bt-utils.c:168
0x89965e handle_fatal_signal
../../src/gdb/event-top.c:964
0x8997ca handle_sigsegv
../../src/gdb/event-top.c:1037
0x7f96f5971b1f ???
/usr/src/debug/glibc-2.30-2-gd74461fa34/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xe602b0 _Z15print_thread_idP11thread_info
../../src/gdb/thread.c:1439
0x5b3d05 print_one_breakpoint_location
../../src/gdb/breakpoint.c:6542
0x5b462e print_one_breakpoint
../../src/gdb/breakpoint.c:6702
0x5b5354 breakpoint_1
../../src/gdb/breakpoint.c:6924
0x5b58b8 maintenance_info_breakpoints
../../src/gdb/breakpoint.c:7009
... etc ...
As the thread-specific breakpoint is set to disp_del_at_next_stop, and
GDB hasn't stopped yet, then the breakpoint still exists in the global
breakpoint list.
The breakpoint will not show in 'info breakpoints' as its number is
zero, but it will show in 'maint info breakpoints'.
As GDB prints the breakpoint, the thread-id for the breakpoint is
printed as part of the 'stop only in thread ...' line. Printing the
thread-id involves calling find_thread_global_id to convert the global
thread-id into a thread_info*. Then calling print_thread_id to
convert the thread_info* into a string.
The problem is that find_thread_global_id returns nullptr as the
thread for the thread-specific breakpoint has exited. The
print_thread_id assumes it will be passed a non-nullptr. As a result
GDB crashes.
In this commit I've added an assert to print_thread_id (gdb/thread.c)
to check that the pointed passed in is not nullptr. This assert would
have triggered in the above case before GDB crashed.
MI Notifications: The Dangers Of Changing A Breakpoint's Number
---------------------------------------------------------------
Currently the delete_breakpoint function doesn't trigger the
breakpoint_deleted observer for any breakpoint with the number zero.
There is a comment explaining why this is the case in the code; it's
something about watchpoints. But I did consider just removing the 'is
the number zero' guard and always triggering the breakpoint_deleted
observer, figuring that I'd then fix the watchpoint issue some other
way.
But I realised this wasn't going to be good enough. When the MI
notification was delivered the number would be zero, so any frontend
parsing the notifications would not be able to match
=breakpoint-deleted notification to the earlier =breakpoint-created
notification.
What this means is that, at the point the breakpoint_deleted observer
is called, the breakpoint's number must be correct.
MI Notifications: The Dangers Of Delaying Deletion
--------------------------------------------------
The test I used to expose the above crash also brought another problem
to my attention. In the above test we used 'continue&' to resume,
after which a thread exited, but the inferior didn't stop. Recreating
the same test in the MI looks like this:
-break-insert -p 2 main
^done,bkpt={number="2",type="breakpoint",disp="keep",...<snip>...}
(gdb)
-exec-continue
^running
*running,thread-id="all"
(gdb)
~"[Thread 0x7ffff7c5d700 (LWP 987038) exited]\n"
=thread-exited,id="2",group-id="i1"
~"Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.\n"
At this point the we have a single thread left, which is still
running:
-thread-info
^done,threads=[{id="1",target-id="Thread 0x7ffff7c5eb80 (LWP 987035)",name="thread-bp-delet",state="running",core="4"}],current-thread-id="1"
(gdb)
Notice that we got the =thread-exited notification from GDB as soon as
the thread exited. We also saw the CLI line from GDB, the line
explaining that breakpoint 2 was deleted. But, as expected, we didn't
see the =breakpoint-deleted notification.
I say "as expected" because the number was set to zero. But, even if
the number was not set to zero we still wouldn't see the
notification. The MI notification is driven by the breakpoint_deleted
observer, which is only called when we actually delete the breakpoint,
which is only done the next time GDB stops.
Now, maybe this is fine. The notification is delivered a little
late. But remember, by setting the number to zero the breakpoint will
be hidden from the user, for example, the breakpoint is removed from
the MI's -break-info command output.
This means that GDB is in a position where the breakpoint doesn't show
up in the breakpoint table, but a =breakpoint-deleted notification has
not yet been sent out. This doesn't seem right to me.
What this means is that, when the thread exits, we should immediately
be sending out the =breakpoint-deleted notification. We should not
wait for GDB to next stop before sending the notification.
The Solution
------------
My proposed solution is this; in remove_threaded_breakpoints, instead
of setting the disposition to disp_del_at_next_stop and setting the
number to zero, we now just call delete_breakpoint directly.
The notification will now be sent out immediately; as soon as the
thread exits.
As the number has not changed when delete_breakpoint is called, the
notification will have the correct number.
And as the breakpoint is immediately removed from the breakpoint list,
we no longer need to worry about 'maint info breakpoints' trying to
print the thread-id for an exited thread.
My only concern is that calling delete_breakpoint directly seems so
obvious that I wonder why the original patch (that added
remove_threaded_breakpoints) didn't take this approach. This code was
added in commit
|
||
|
Andrew Burgess
|
2ecee23675 |
gdb: use -1 for breakpoint::task default value
Within the breakpoint struct we have two fields ::thread and ::task which are used for thread or task specific breakpoints. When a breakpoint doesn't have a specific thread or task then these fields have the values -1 and 0 respectively. There's no particular reason (as far as I can tell) why these two "default" values are different, and I find the difference a little confusing. Long term I'd like to potentially fold these two fields into a single field, but that isn't what this commit does. What this commit does is switch to using -1 as the "default" value for both fields, this means that the default for breakpoint::task has changed from 0 to -1. I've updated all the code I can find that relied on the value of 0, and I see no test regressions, especially in gdb.ada/tasks.exp, which still fully passes. There should be no user visible changes after this commit. Approved-By: Pedro Alves <pedro@palves.net> |
||
|
Andrew Burgess
|
0a9ccb9dd7 |
gdb: only allow one of thread or task on breakpoints or watchpoints
After this mailing list posting: https://sourceware.org/pipermail/gdb-patches/2023-February/196607.html it seems to me that in practice an Ada task maps 1:1 with a GDB thread, and so it doesn't really make sense to allow uses to give both a thread and a task within a single breakpoint or watchpoint condition. This commit updates GDB so that the user will get an error if both are specified. I've added new tests to cover the CLI as well as the Python and Guile APIs. For the Python and Guile testing, as far as I can tell, this was the first testing for this corner of the APIs, so I ended up adding more than just a single test. For documentation I've added a NEWS entry, but I've not added anything to the docs themselves. Currently we document the commands with a thread-id or task-id as distinct command, e.g.: 'break LOCSPEC task TASKNO' 'break LOCSPEC task TASKNO if ...' 'break LOCSPEC thread THREAD-ID' 'break LOCSPEC thread THREAD-ID if ...' As such, I don't believe there is any indication that combining 'task' and 'thread' would be expected to work; it seems clear to me in the above that those four options are all distinct commands. I think the NEWS entry is enough that if someone is combining these keywords (it's not clear what the expected behaviour would be in this case) then they can figure out that this was a deliberate change in GDB, but for a new user, the manual doesn't suggest combining them is OK, and any future attempt to combine them will give an error. Approved-By: Pedro Alves <pedro@palves.net> |
||
 Joel Brobecker
|
213516ef31 |
Update copyright year range in header of all files managed by GDB
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. |
||
 Simon Marchi
|
f8631e5e04 |
gdb: remove static buffer in command_line_input
[I sent this earlier today, but I don't see it in the archives.
Resending it through a different computer / SMTP.]
The use of the static buffer in command_line_input is becoming
problematic, as explained here [1]. In short, with this patch [2] that
attempt to fix a post-hook bug, when running gdb.base/commands.exp, we
hit a case where we read a "define" command line from a script file
using command_command_line_input. The command line is stored in
command_line_input's static buffer. Inside the define command's
execution, we read the lines inside the define using command_line_input,
which overwrites the define command, in command_line_input's static
buffer. After the execution of the define command, execute_command does
a command look up to see if a post-hook is registered. For that, it
uses a now stale pointer that used to point to the define command, in
the static buffer, causing a use-after-free. Note that the pointer in
execute_command points to the dynamically-allocated buffer help by the
static buffer in command_line_input, not to the static object itself,
hence why we see a use-after-free.
Fix that by removing the static buffer. I initially changed
command_line_input and other related functions to return an std::string,
which is the obvious but naive solution. The thing is that some callees
don't need to return an allocated string, so this this an unnecessary
pessimization. I changed it to passing in a reference to an std::string
buffer, which the callee can use if it needs to return
dynamically-allocated content. It fills the buffer and returns a
pointers to the C string inside. The callees that don't need to return
dynamically-allocated content simply don't use it.
So, it started with modifying command_line_input as described above, all
the other changes derive directly from that.
One slightly shady thing is in handle_line_of_input, where we now pass a
pointer to an std::string's internal buffer to readline's history_value
function, which takes a `char *`. I'm pretty sure that this function
does not modify the input string, because I was able to change it (with
enough massaging) to take a `const char *`.
A subtle change is that we now clear a UI's line buffer using a
SCOPE_EXIT in command_line_handler, after executing the command.
This was previously done by this line in handle_line_of_input:
/* We have a complete command line now. Prepare for the next
command, but leave ownership of memory to the buffer . */
cmd_line_buffer->used_size = 0;
I think the new way is clearer.
[1] https://inbox.sourceware.org/gdb-patches/becb8438-81ef-8ad8-cc42-fcbfaea8cddd@simark.ca/
[2] https://inbox.sourceware.org/gdb-patches/20221213112241.621889-1-jan.vrany@labware.com/
Change-Id: I8fc89b1c69870c7fc7ad9c1705724bd493596300
Reviewed-By: Tom Tromey <tom@tromey.com>
|
||
|
Tom Tromey
|
3567f2bd66 |
Remove unnecessary xstrdup from bppy_init
I saw that bppy_init used a non-const "char *". Fixing this revealed that the xstrdup here was also unnecessary, so this patch removes it. |
||
|
Andrew Burgess
|
8a3b17063e |
gdb/python: break more dependencies between gdbpy_initialize_* functions
In a later commit in this series I will propose removing all of the explicit gdbpy_initialize_* calls from python.c and replace these calls with a more generic mechanism. One of the side effects of this generic mechanism is that the order in which the various Python sub-systems within GDB are initialized is no longer guaranteed. On the whole I don't think this matters, most of the sub-systems are independent of each other, though testing did reveal a few places where we did have dependencies, though I don't think those dependencies were explicitly documented in comment anywhere. This commit is similar to the previous one, and fixes the second dependency issue that I found. In this case the finish_breakpoint_object_type uses the breakpoint_object_type as its tp_base, this means that breakpoint_object_type must have been initialized with a call to PyType_Ready before finish_breakpoint_object_type can be initialized. Previously we depended on the ordering of calls to gdbpy_initialize_breakpoints and gdbpy_initialize_finishbreakpoints in python.c. After this commit a new function gdbpy_breakpoint_init_breakpoint_type exists, this function ensures that breakpoint_object_type has been initialized, and can be called from any gdbpy_initialize_* function. I feel that this change makes the dependency explicit, which I think is a good thing. There should be no user visible changes after this commit. |
||
|
Tom Tromey
|
992aeed80b |
Use ui_out_redirect_pop in more places
This changes ui_out_redirect_pop to also perform the redirection, and then updates several sites to use this, rather than explicit redirects. |
||
 Simon Farre
|
e5213e2c85 |
gdb/python: Add BreakpointLocation type
PR python/18385 v7: This version addresses the issues pointed out by Tom. Added nullchecks for Python object creations. Changed from using PyLong_FromLong to the gdb_py-versions. Re-factored some code to make it look more cohesive. Also added the more safe Python reference count decrement PY_XDECREF, even though the BreakpointLocation type is never instantiated by the user (explicitly documented in the docs) decrementing < 0 is made impossible with the safe call. Tom pointed out that using the policy class explicitly to decrement a reference counted object was not the way to go, so this has instead been wrapped in a ref_ptr that handles that for us in blocpy_dealloc. Moved macro from py-internal to py-breakpoint.c. Renamed section at the bottom of commit message "Patch Description". v6: This version addresses the points Pedro gave in review to this patch. Added the attributes `function`, `fullname` and `thread_groups` as per request by Pedro with the argument that it more resembles the output of the MI-command "-break-list". Added documentation for these attributes. Cleaned up left overs from copy+paste in test suite, removed hard coding of line numbers where possible. Refactored some code to use more c++-y style range for loops wrt to breakpoint locations. Changed terminology, naming was very inconsistent. Used a variety of "parent", "owner". Now "owner" is the only term used, and the field in the gdb_breakpoint_location_object now also called "owner". v5: Changes in response to review by Tom Tromey: - Replaced manual INCREF/DECREF calls with gdbpy_ref ptrs in places where possible. - Fixed non-gdb style conforming formatting - Get parent of bploc increases ref count of parent. - moved bploc Python definition to py-breakpoint.c The INCREF of self in bppy_get_locations is due to the individual locations holding a reference to it's owner. This is decremented at de-alloc time. The reason why this needs to be here is, if the user writes for instance; py loc = gdb.breakpoints()[X].locations[Y] The breakpoint owner object is immediately going out of scope (GC'd/dealloced), and the location object requires it to be alive for as long as it is alive. Thanks for your review, Tom! v4: Fixed remaining doc issues as per request by Eli. v3: Rewritten commit message, shortened + reworded, added tests. Patch Description Currently, the Python API lacks the ability to query breakpoints for their installed locations, and subsequently, can't query any information about them, or enable/disable individual locations. This patch solves this by adding Python type gdb.BreakpointLocation. The type is never instantiated by the user of the Python API directly, but is produced by the gdb.Breakpoint.locations attribute returning a list of gdb.BreakpointLocation. gdb.Breakpoint.locations: The attribute for retrieving the currently installed breakpoint locations for gdb.Breakpoint. Matches behavior of the "info breakpoints" command in that it only returns the last known or currently inserted breakpoint locations. BreakpointLocation contains 7 attributes 6 read-only attributes: owner: location owner's Python companion object source: file path and line number tuple: (string, long) / None address: installed address of the location function: function name where location was set fullname: fullname where location was set thread_groups: thread groups (inferiors) where location was set. 1 writeable attribute: enabled: get/set enable/disable this location (bool) Access/calls to these, can all throw Python exceptions (documented in the online documentation), and that's due to the nature of how breakpoint locations can be invalidated "behind the scenes", either by them being removed from the original breakpoint or changed, like for instance when a new symbol file is loaded, at which point all breakpoint locations are re-created by GDB. Therefore this patch has chosen to be non-intrusive: it's up to the Python user to re-request the locations if they become invalid. Also there's event handlers that handle new object files etc, if a Python user is storing breakpoint locations in some larger state they've built up, refreshing the locations is easy and it only comes with runtime overhead when the Python user wants to use them. gdb.BreakpointLocation Python type struct "gdbpy_breakpoint_location_object" is found in python-internal.h Its definition, layout, methods and functions are found in the same file as gdb.Breakpoint (py-breakpoint.c) 1 change was also made to breakpoint.h/c to make it possible to enable and disable a bp_location* specifically, without having its LOC_NUM, as this number also can change arbitrarily behind the scenes. Updated docs & news file as per request. Testsuite: tests the .source attribute and the disabling of individual locations. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385 Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0 |
||
 Pedro Alves
|
709438c75a |
Convert location_spec_to_string to a method
This converts location_spec_to_string to a method of location_spec, simplifying the code using it, as it no longer has to use std::unique_ptr::get(). Change-Id: I621bdad8ea084470a2724163f614578caf8f2dd5 |
||
|
Pedro Alves
|
40d97ee21f |
Eliminate the two-level data structures behind location_specs
Currently, there's the location_spec hierarchy, and then some
location_spec subclasses have their own struct type holding all their
data fields.
I.e., there is this:
location_spec
explicit_location_spec
linespec_location_spec
address_location_spec
probe_location_spec
and then these separate types:
explicit_location
linespec_location
where:
explicit_location_spec
has-a explicit_location
linespec_location_spec
has-a linespec_location
This patch eliminates explicit_location and linespec_location,
inlining their members in the corresponding location_spec type.
The location_spec subclasses were the ones currently defined in
location.c, so they are moved to the header. Since the definitions of
the classes are now visible, we no longer need location_spec_deleter.
Some constructors that are used for cloning location_specs, like:
explicit explicit_location_spec (const struct explicit_location *loc)
... were converted to proper copy ctors.
In the process, initialize_explicit_location is eliminated, and some
functions that returned the "data type behind a locspec", like
get_linespec_location are converted to downcast functions, like
as_linespec_location_spec.
Change-Id: Ia31ccef9382b25a52b00fa878c8df9b8cf2a6c5a
|
||
|
Pedro Alves
|
264f98902f |
event_location -> location_spec
Currently, GDB internally uses the term "location" for both the
location specification the user input (linespec, explicit location, or
an address location), and for actual resolved locations, like the
breakpoint locations, or the result of decoding a location spec to
SaLs. This is expecially confusing in the breakpoints module, as
struct breakpoint has these two fields:
breakpoint::location;
breakpoint::loc;
"location" is the location spec, and "loc" is the resolved locations.
And then, we have a method called "locations()", which returns the
resolved locations as range...
The location spec type is presently called event_location:
/* Location we used to set the breakpoint. */
event_location_up location;
and it is described like this:
/* The base class for all an event locations used to set a stop event
in the inferior. */
struct event_location
{
and even that is incorrect... Location specs are used for finding
actual locations in the program in scenarios that have nothing to do
with stop events. E.g., "list" works with location specs.
To clean all this confusion up, this patch renames "event_location" to
"location_spec" throughout, and then all the variables that hold a
location spec, they are renamed to include "spec" in their name, like
e.g., "location" -> "locspec". Similarly, functions that work with
location specs, and currently have just "location" in their name are
renamed to include "spec" in their name too.
Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca
|
||
 Tom Tromey
|
6cb06a8cda |
Unify gdb printf functions
Now that filtered and unfiltered output can be treated identically, we can unify the printf family of functions. This is done under the name "gdb_printf". Most of this patch was written by script. |
||
|
Simon Marchi
|
5aee458796 |
gdb/python: remove Python 2/3 compatibility macros
New in this version: - Rebase on master, fix a few more issues that appeared. python-internal.h contains a number of macros that helped make the code work with both Python 2 and 3. Remove them and adjust the code to use the Python 3 functions. Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d |
||
|
Tom Tromey
|
1da5d0e664 |
Change how Python architecture and language are handled
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.
|
||
|
Joel Brobecker
|
4a94e36819 |
Automatic Copyright Year update after running gdb/copyright.py
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. |
||
|
Andrew Burgess
|
8579fd136a |
gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr
The motivation is to reduce the number of places where unmanaged pointers are returned from allocation type routines. All of the callers are updated. There should be no user visible changes after this commit. |
||
|
Tom Tromey
|
6f781ee300 |
Use unique_xmalloc_ptr in breakpoint
This changes struct breakpoint to use unique_xmalloc_ptr in a couple of spots, removing a bit of manual memory management. |
||
|
Tom Tromey
|
a4c50be3d6 |
Use unique_xmalloc_ptr in watchpoint
This changes struct watchpoint to use unique_xmalloc_ptr in a couple of places, removing a bit of manual memory management. |
||
 Andrew Burgess
|
6b95f5ad96 |
gdb/python: allow for catchpoint type breakpoints in python
This commit adds initial support for catchpoints to the python breakpoint API. This commit adds a BP_CATCHPOINT constant which corresponds to GDB's internal bp_catchpoint. The new constant is documented in the manual. The user can't create breakpoints with type BP_CATCHPOINT after this commit, but breakpoints that already exist, obtained with the `gdb.breakpoints` function, can now have this type. Additionally, when a stop event is reported for hitting a catchpoint, GDB will now report a BreakpointEvent with the attached breakpoint being of type BP_CATCHPOINT - previously GDB would report a generic StopEvent in this situation. gdb/ChangeLog: * NEWS: Mention Python BP_CATCHPOINT feature. * python/py-breakpoint.c (pybp_codes): Add bp_catchpoint support. (bppy_init): Likewise. (gdbpy_breakpoint_created): Likewise. gdb/doc/ChangeLog: * python.texinfo (Breakpoints In Python): Add BP_CATCHPOINT description. gdb/testsuite/ChangeLog: * gdb.python/py-breakpoint.c (do_throw): New function. (main): Call do_throw. * gdb.python/py-breakpoint.exp (test_catchpoints): New proc. |
||
|
Simon Marchi
|
240edef62f |
gdb: remove iterate_over_breakpoints function
Now that we have range functions that let us use ranged for loops, we can remove iterate_over_breakpoints in favor of those, which are easier to read and write. This requires exposing the declaration of all_breakpoints and all_breakpoints_safe in breakpoint.h, as well as the supporting types. Change some users of iterate_over_breakpoints to use all_breakpoints, when they don't need to delete the breakpoint, and all_breakpoints_safe otherwise. gdb/ChangeLog: * breakpoint.h (iterate_over_breakpoints): Remove. Update callers to use all_breakpoints or all_breakpoints_safe. (breakpoint_range, all_breakpoints, breakpoint_safe_range, all_breakpoints_safe): Move here. * breakpoint.c (all_breakpoints, all_breakpoints_safe): Make non-static. (iterate_over_breakpoints): Remove. * python/py-finishbreakpoint.c (bpfinishpy_detect_out_scope_cb): Return void. * python/py-breakpoint.c (build_bp_list): Add comment, reverse return value logic. * guile/scm-breakpoint.c (bpscm_build_bp_list): Return void. Change-Id: Idde764a1f577de0423e4f2444a7d5cdb01ba5e48 |
||
|
Andrew Burgess
|
75140e3b75 |
gdb/py: add some debugging to py-breakpoint.c
Adds some new debugging to python/py-breakpoint.c. gdb/ChangeLog: * python/py-breakpoint.c (pybp_debug): New static global. (show_pybp_debug): New function. (pybp_debug_printf): Define. (PYBP_SCOPED_DEBUG_ENTER_EXIT): Define. (gdbpy_breakpoint_created): Add some debugging. (gdbpy_breakpoint_deleted): Likewise. (gdbpy_breakpoint_modified): Likewise. (_initialize_py_breakpoint): New function. gdb/doc/ChangeLog: * python.texinfo (Python Commands): Document 'set debug py-breakpoint' and 'show debug py-breakpoint'. |
||
|
Simon Marchi
|
c90e7d6352 |
gdbsupport, gdb: give names to observers
Give a name to each observer, this will help produce more meaningful debug message. gdbsupport/ChangeLog: * observable.h (class observable) <struct observer> <observer>: Add name parameter. <name>: New field. <attach>: Add name parameter, update all callers. Change-Id: Ie0cc4664925215b8d2b09e026011b7803549fba0 |
||
 Tankut Baris Aktemur
|
10a636ccb4 |
gdb/breakpoint: add a 'force_condition' parameter to 'create_breakpoint'
The 'create_breakpoint' function takes a 'parse_extra' argument that
determines whether the condition, thread, and force-condition
specifiers should be parsed from the extra string or be used from the
function arguments. However, for the case when 'parse_extra' is
false, there is no way to pass the force-condition specifier. This
patch adds it as a new argument.
Also, in the case when parse_extra is false, the current behavior is
as if the condition is being forced. This is a bug. The default
behavior should reject the breakpoint. See below for a demo of this
incorrect behavior. (The MI command '-break-insert' uses the
'create_breakpoint' function with parse_extra=0.)
$ gdb -q --interpreter=mi3 /tmp/simple
=thread-group-added,id="i1"
=cmd-param-changed,param="history save",value="on"
=cmd-param-changed,param="auto-load safe-path",value="/"
~"Reading symbols from /tmp/simple...\n"
(gdb)
-break-insert -c junk -f main
&"warning: failed to validate condition at location 1, disabling:\n "
&"No symbol \"junk\" in current context.\n"
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="junk",times="0",original-location="main",locations=[{number="1.1",enabled="N",addr="0x000000000000114e",func="main",file="/tmp/simple.c",fullname="/tmp/simple.c",line="2",thread-groups=["i1"]}]}
(gdb)
break main if junk
&"break main if junk\n"
&"No symbol \"junk\" in current context.\n"
^error,msg="No symbol \"junk\" in current context."
(gdb)
break main -force-condition if junk
&"break main -force-condition if junk\n"
~"Note: breakpoint 1 also set at pc 0x114e.\n"
&"warning: failed to validate condition at location 1, disabling:\n "
&"No symbol \"junk\" in current context.\n"
~"Breakpoint 2 at 0x114e: file /tmp/simple.c, line 2.\n"
=breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="junk",times="0",original-location="main",locations=[{number="2.1",enabled="N",addr="0x000000000000114e",func="main",file="/tmp/simple.c",fullname="/tmp/simple.c",line="2",thread-groups=["i1"]}]}
^done
(gdb)
After applying this patch, we get the behavior below:
(gdb)
-break-insert -c junk -f main
^error,msg="No symbol \"junk\" in current context."
This restores the behavior that is present in the existing releases.
gdb/ChangeLog:
2021-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.h (create_breakpoint): Add a new parameter,
'force_condition'.
* breakpoint.c (create_breakpoint): Use the 'force_condition'
argument when 'parse_extra' is false to check if the condition
is invalid at all of the breakpoint locations.
Update the users below.
(break_command_1)
(dprintf_command)
(trace_command)
(ftrace_command)
(strace_command)
(create_tracepoint_from_upload): Update.
* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Update.
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Update.
* python/py-breakpoint.c (bppy_init): Update.
* python/py-finishbreakpoint.c (bpfinishpy_init): Update.
gdb/testsuite/ChangeLog:
2021-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/mi-break.exp: Extend with checks for invalid breakpoint
conditions.
|
||
 Hannes Domani
|
325d39e4e0 |
Add Python support for hardware breakpoints
This allows the creation of hardware breakpoints in Python with gdb.Breakpoint(type=gdb.BP_HARDWARE_BREAKPOINT) And they are included in the sequence returned by gdb.breakpoints(). gdb/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * python/py-breakpoint.c (bppy_get_location): Handle bp_hardware_breakpoint. (bppy_init): Likewise. (gdbpy_breakpoint_created): Likewise. gdb/doc/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * python.texi (Breakpoints In Python): Document gdb.BP_HARDWARE_BREAKPOINT. gdb/testsuite/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * gdb.python/py-breakpoint.exp: Add tests for hardware breakpoints. |
||
|
Joel Brobecker
|
3666a04883 |
Update copyright year range in all GDB files
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.
|
||
|
Tankut Baris Aktemur
|
733d554a46 |
gdb/breakpoint: add flags to 'condition' and 'break' commands to force condition
The previous patch made it possible to define a condition if it's
valid at some locations. If the condition is invalid at all of the
locations, it's rejected. However, there may be cases where the user
knows the condition *will* be valid at a location in the future,
e.g. due to a shared library load.
To make it possible that such condition can be defined, this patch
adds an optional '-force' flag to the 'condition' command, and,
respectively, a '-force-condition' flag to the 'break'command. When
the force flag is passed, the condition is not rejected even when it
is invalid for all the current locations (note that all the locations
would be internally disabled in this case).
For instance:
(gdb) break test.c:5
Breakpoint 1 at 0x1155: file test.c, line 5.
(gdb) cond 1 foo == 42
No symbol "foo" in current context.
Defining the condition was not possible because 'foo' is not
available. The user can override this behavior with the '-force'
flag:
(gdb) cond -force 1 foo == 42
warning: failed to validate condition at location 1.1, disabling:
No symbol "foo" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if foo == 42
1.1 N 0x0000000000001155 in main at test.c:5
Now the condition is accepted, but the location is automatically
disabled. If a future location has a context in which 'foo' is
available, that location would be enabled.
For the 'break' command, -force-condition has the same result:
(gdb) break test.c:5 -force-condition if foo == 42
warning: failed to validate condition at location 0x1169, disabling:
No symbol "foo" in current context.
Breakpoint 1 at 0x1169: file test.c, line 5.
gdb/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.h (set_breakpoint_condition): Add a new bool parameter.
* breakpoint.c: Update the help text of the 'condition' and 'break'
commands.
(set_breakpoint_condition): Take a new bool parameter
to control whether condition definition should be forced even when
the condition expression is invalid in all of the current locations.
(condition_command): Update the call to 'set_breakpoint_condition'.
(find_condition_and_thread): Take the "-force-condition" flag into
account.
* linespec.c (linespec_keywords): Add "-force-condition" as an
element.
(FORCE_KEYWORD_INDEX): New #define.
(linespec_lexer_lex_keyword): Update to consider "-force-condition"
as a keyword.
* ada-lang.c (create_ada_exception_catchpoint): Ditto.
* guile/scm-breakpoint.c (gdbscm_set_breakpoint_condition_x): Ditto.
* python/py-breakpoint.c (bppy_set_condition): Ditto.
* NEWS: Mention the changes to the 'break' and 'condition' commands.
gdb/testsuite/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-multi-context.exp: Expand to test forcing
the condition.
* gdb.linespec/cpcompletion.exp: Update to consider the
'-force-condition' keyword.
* gdb.linespec/explicit.exp: Ditto.
* lib/completion-support.exp: Ditto.
gdb/doc/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (Set Breaks): Document the '-force-condition' flag
of the 'break'command.
* gdb.texinfo (Conditions): Document the '-force' flag of the
'condition' command.
|
||
|
Tom Tromey
|
47f0e2ff7f |
Don't use PyInt_FromLong
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. |
||
|
Joel Brobecker
|
b811d2c292 |
Update copyright year range in all GDB files.
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
||
 George Barrett
|
bac7c5cf92 |
Fix scripted probe breakpoints
The documentation for make-breakpoint from the Guile API and the `spec' variant of the gdb.Breakpoint constructor from the Python API state that the format acceptable for location strings is the same as that accepted by the break command. However, using the -probe qualifier at the beginning of the location string causes a GDB internal error as it attempts to decode a probe location in the wrong code path. Without this functionality, there doesn't appear to be another way to set breakpoints on probe points from Python or Guile scripts. This patch introduces a new helper function that returns a breakpoint_ops instance appropriate for a parsed location and updates the Guile and Python bindings to use said function, rather than the current hard-coded use of bkpt_breakpoint_ops. Since this logic is duplicated in the handling of the `break' and `trace' commands, those are also updated to call into the new helper function. gdb/ChangeLog: 2019-12-10 George Barrett <bob@bob131.so> Fix scripted probe breakpoints. * breakpoint.c (tracepoint_probe_breakpoint_ops): Move declaration forward. (breakpoint_ops_for_event_location_type) (breakpoint_ops_for_event_location): Add function definitions. (break_command_1, trace_command): Use breakpoint_ops_for_event_location. * breakpoint.h (breakpoint_ops_for_event_location): Add function declarations. * guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Use breakpoint_ops_for_event_location. * python/py-breakpoint.c (bppy_init): Use breakpoint_ops_for_event_location. gdb/testsuite/ChangeLog: 2019-12-10 George Barrett <bob@bob131.so> Test scripted probe breakpoints. * gdb.guile/scm-breakpoint.c (main): Add probe point. * gdb.python/py-breakpoint.c (main): Likewise. * gdb.guile/scm-breakpoint.exp (test_bkpt_probe): Add probe specifier test. * gdb.python/py-breakpoint.exp (test_bkpt_probe): Likewise. |
||
 Philippe Waroquiers
|
bd454f8baf |
Fix python gdbpy_breakpoint_object leak.
valgrind reports a leak when a breakpoint is created then deleted: ==1313== 40 bytes in 1 blocks are definitely lost in loss record 1,115 of 8,596 ==1313== at 0x4835753: malloc (vg_replace_malloc.c:307) ==1313== by 0x6E05BC: _PyObject_New (object.c:255) ==1313== by 0x470E4B: gdbpy_breakpoint_created(breakpoint*) (py-breakpoint.c:1023) ==1313== by 0x2946D9: operator() (std_function.h:687) ==1313== by 0x2946D9: notify (observable.h:106) ==1313== by 0x2946D9: install_breakpoint(int, std::unique_ptr<breakpoint, std::default_delete<breakpoint> >&&, int) (breakpoint.c:8136) ==1313== by 0x295BCA: create_breakpoint_sal (breakpoint.c:8878) ==1313== by 0x295BCA: create_breakpoints_sal (breakpoint.c:8919) ==1313== by 0x295BCA: create_breakpoints_sal_default (breakpoint.c:13671) ... The leak is due to a superfluous Py_INCREF when the python object is allocated inside gdbpy_breakpoint_created, when the python object is allocated locally: this object has already a refcount of 1, and the only reference is the reference from the C breakpoint object. The Py_INCREF is however needed when the python object was created from python: the python object was stored in bppy_pending_object, and gdbpy_breakpoint_created creates a new reference to this object. Solve the leak by calling 'Py_INCREF (newbp);' only in the bppy_pending_object case. Regression tested on debian/amd64 natively and under valgrind on centos/amd64. Before the patch, 795 tests have a definite leak. After the patch, 197 have a definite leak. Thanks to Tom, that helped on irc with the python refcount logic. gdb/ChangeLog 2019-11-14 Philippe Waroquiers <philippe.waroquiers@skynet.be> * python/py-finishbreakpoint.c (gdbpy_breakpoint_created): only call Py_INCREF (newbp) in the bppy_pending_object case. |
||
 Christian Biesinger
|
95da600f40 |
Change iterate_over_breakpoints to take a function_view
This allows callers to pass in capturing lambdas. Also changes the return type to bool. gdb/ChangeLog: 2019-10-15 Christian Biesinger <cbiesinger@google.com> * breakpoint.c (iterate_over_breakpoints): Change function pointer to a gdb::function_view and return value to bool. * breakpoint.h (iterate_over_breakpoints): Likewise. * dummy-frame.c (pop_dummy_frame_bpt): Update. (pop_dummy_frame): Update. * guile/scm-breakpoint.c (bpscm_build_bp_list): Update. (gdbscm_breakpoints): Update. * python/py-breakpoint.c (build_bp_list): Update. (gdbpy_breakpoints): Update. * python/py-finishbreakpoint.c (bpfinishpy_detect_out_scope_cb): Update. (bpfinishpy_handle_stop): Update. (bpfinishpy_handle_exit): Update. * solib-svr4.c (svr4_update_solib_event_breakpoint): Update. (svr4_update_solib_event_breakpoints): Update. Change-Id: Ia9de4deecae562a70a40f5cd49f5a74d64570251 |
||
 Pedro Alves
|
cb1e4e32c2 |
"catch catch/throw/rethrow", breakpoint -> catchpoint
Currently, with:
(gdb) catch catch
Catchpoint 1 (catch)
(gdb) catch throw
Catchpoint 2 (throw)
(gdb) catch rethrow
Catchpoint 3 (rethrow)
You get:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000b122af exception catch
2 breakpoint keep y 0x0000000000b1288d exception throw
3 breakpoint keep y 0x0000000000b12931 exception rethrow
I think it doesn't make much sense usability-wise, to show a
catchpoint as a breakpoint. The fact that GDB sets a breakpoint at
some magic address in the C++ run time is an implementation detail,
IMO. And as seen in the previous patch, such a catchpoint can end up
with more than one location/address even, so showing a single address
isn't entirely accurate.
This commit hides the addresses from view, and makes GDB show
"catchpoint" for type as well:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 catchpoint keep y exception catch
2 catchpoint keep y exception throw
3 catchpoint keep y exception rethrow
This comment in the code seems telling:
/* We need to reset 'type' in order for code in breakpoint.c to do
the right thing. */
cp->type = bp_breakpoint;
It kind of suggests that the reason catchpoints end up shown as
breakpoints was that it was easier to implement them that way, rather
than a desired property.
This commit fixes things up to make it possible to have bp_catch
breakpoints have software/hardware breakpoint locations, thus
eliminating the need for that hack:
- redo breakpoint_address_is_meaningful in terms of the location's
type rather than breakpoint type.
- teach bpstat_what about stepping over the catchpoint locations.
- install a allocate_location method for "catch catch/throw/rethrow",
one that forces the location type.
Note that this also reverts the gdb hunk from:
commit
|
||
|
Tom Tromey
|
25ce02ee7b |
Use gdbpy_enter in py-breakpoint.c
A few spots in py-breakpoint.c acquire the GIL manually. However, because these spots generate events, and because events are expected to be arbitrary gdb-flavored Python code, it's important to use gdbpy_enter instead, in order to ensure that the other gdb-related Python globals are set correctly. This patch makes this change. Tested on x86-64 Fedora 29. gdb/ChangeLog 2019-06-10 Tom Tromey <tom@tromey.com> * python/py-breakpoint.c (gdbpy_breakpoint_created) (gdbpy_breakpoint_deleted, gdbpy_breakpoint_modified): Use gdbpy_enter. |
||
|
Tom Tromey
|
94aeb44b00 |
Make exception handling more efficient
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. |
||
|
Tom Tromey
|
cc06b66897 |
Remove exception_none
Now that gdb_exception has a constructor, there's no need for exception_none. This patch removes it. gdb/ChangeLog 2019-04-25 Tom Tromey <tromey@adacore.com> * xml-support.c (gdb_xml_parser::gdb_xml_parser): Update. * python/py-value.c (valpy_getitem, valpy_nonzero): Update. * python/py-inferior.c (infpy_write_memory, infpy_search_memory): Update. * python/py-breakpoint.c (bppy_set_condition, bppy_set_commands): Update. * mi/mi-interp.c (mi_interp::exec): Update. * linespec.c (parse_linespec): Update. * infcall.c (run_inferior_call): Update. * guile/scm-value.c (gdbscm_value_to_lazy_string): Update. * guile/scm-symbol.c (gdbscm_lookup_symbol) (gdbscm_lookup_global_symbol): Update. * guile/scm-param.c (gdbscm_parameter_value): Update. * guile/scm-frame.c (gdbscm_frame_read_register) (gdbscm_frame_read_var): Update. * guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Update. * exec.c (try_open_exec_file): Update. * event-top.c (gdb_rl_callback_read_char_wrapper_noexcept) (gdb_rl_callback_handler): Update. * common/common-exceptions.h (exception_none): Don't declare. * common/common-exceptions.c (exception_none): Don't define. (struct catcher) <exception>: Update. * cli/cli-interp.c (safe_execute_command): Update. * breakpoint.c (insert_bp_location, location_to_sals): Update. |
||
|
Tom Tromey
|
230d2906b9 |
Rename gdb exception types
This renames the gdb exception types. The old types were only needed due to the macros in common-exception.h that are now gone. The intermediate layer of gdb_exception_RETURN_MASK_ALL did not seem needed, so this patch removes it entirely. gdb/ChangeLog 2019-04-08 Tom Tromey <tom@tromey.com> * common/common-exceptions.h (gdb_exception_RETURN_MASK_ALL): Remove. (gdb_exception_error): Rename from gdb_exception_RETURN_MASK_ERROR. (gdb_exception_quit): Rename from gdb_exception_RETURN_MASK_QUIT. (gdb_quit_bad_alloc): Update. * aarch64-tdep.c: Update. * ada-lang.c: Update. * ada-typeprint.c: Update. * ada-valprint.c: Update. * amd64-tdep.c: Update. * arch-utils.c: Update. * break-catch-throw.c: Update. * breakpoint.c: Update. * btrace.c: Update. * c-varobj.c: Update. * cli/cli-cmds.c: Update. * cli/cli-interp.c: Update. * cli/cli-script.c: Update. * common/common-exceptions.c: Update. * common/new-op.c: Update. * common/selftest.c: Update. * compile/compile-c-symbols.c: Update. * compile/compile-cplus-symbols.c: Update. * compile/compile-object-load.c: Update. * compile/compile-object-run.c: Update. * completer.c: Update. * corelow.c: Update. * cp-abi.c: Update. * cp-support.c: Update. * cp-valprint.c: Update. * darwin-nat.c: Update. * disasm-selftests.c: Update. * dtrace-probe.c: Update. * dwarf-index-cache.c: Update. * dwarf-index-write.c: Update. * dwarf2-frame-tailcall.c: Update. * dwarf2-frame.c: Update. * dwarf2loc.c: Update. * dwarf2read.c: Update. * eval.c: Update. * event-loop.c: Update. * event-top.c: Update. * exec.c: Update. * f-valprint.c: Update. * fbsd-tdep.c: Update. * frame-unwind.c: Update. * frame.c: Update. * gdbtypes.c: Update. * gnu-v3-abi.c: Update. * guile/guile-internal.h: Update. * guile/scm-block.c: Update. * guile/scm-breakpoint.c: Update. * guile/scm-cmd.c: Update. * guile/scm-disasm.c: Update. * guile/scm-frame.c: Update. * guile/scm-lazy-string.c: Update. * guile/scm-math.c: Update. * guile/scm-param.c: Update. * guile/scm-ports.c: Update. * guile/scm-pretty-print.c: Update. * guile/scm-symbol.c: Update. * guile/scm-symtab.c: Update. * guile/scm-type.c: Update. * guile/scm-value.c: Update. * i386-linux-tdep.c: Update. * i386-tdep.c: Update. * inf-loop.c: Update. * infcall.c: Update. * infcmd.c: Update. * infrun.c: Update. * jit.c: Update. * language.c: Update. * linespec.c: Update. * linux-fork.c: Update. * linux-nat.c: Update. * linux-tdep.c: Update. * linux-thread-db.c: Update. * main.c: Update. * mi/mi-cmd-break.c: Update. * mi/mi-cmd-stack.c: Update. * mi/mi-interp.c: Update. * mi/mi-main.c: Update. * objc-lang.c: Update. * p-valprint.c: Update. * parse.c: Update. * ppc-linux-tdep.c: Update. * printcmd.c: Update. * python/py-arch.c: Update. * python/py-breakpoint.c: Update. * python/py-cmd.c: Update. * python/py-finishbreakpoint.c: Update. * python/py-frame.c: Update. * python/py-framefilter.c: Update. * python/py-gdb-readline.c: Update. * python/py-inferior.c: Update. * python/py-infthread.c: Update. * python/py-lazy-string.c: Update. * python/py-linetable.c: Update. * python/py-objfile.c: Update. * python/py-param.c: Update. * python/py-prettyprint.c: Update. * python/py-progspace.c: Update. * python/py-record-btrace.c: Update. * python/py-record.c: Update. * python/py-symbol.c: Update. * python/py-type.c: Update. * python/py-unwind.c: Update. * python/py-utils.c: Update. * python/py-value.c: Update. * python/python.c: Update. * record-btrace.c: Update. * record-full.c: Update. * remote-fileio.c: Update. * remote.c: Update. * riscv-tdep.c: Update. * rs6000-aix-tdep.c: Update. * rs6000-tdep.c: Update. * rust-exp.y: Update. * rust-lang.c: Update. * s390-tdep.c: Update. * selftest-arch.c: Update. * solib-dsbt.c: Update. * solib-frv.c: Update. * solib-spu.c: Update. * solib-svr4.c: Update. * solib.c: Update. * sparc64-linux-tdep.c: Update. * stack.c: Update. * symfile-mem.c: Update. * symmisc.c: Update. * target.c: Update. * thread.c: Update. * top.c: Update. * tracefile-tfile.c: Update. * tui/tui.c: Update. * typeprint.c: Update. * unittests/cli-utils-selftests.c: Update. * unittests/parse-connection-spec-selftests.c: Update. * valops.c: Update. * valprint.c: Update. * value.c: Update. * varobj.c: Update. * windows-nat.c: Update. * x86-linux-nat.c: Update. * xml-support.c: Update. gdb/gdbserver/ChangeLog 2019-04-08 Tom Tromey <tom@tromey.com> * gdbreplay.c: Update. * linux-low.c: Update. * server.c: Update. |
||
|
Tom Tromey
|
a70b814420 |
Rewrite TRY/CATCH
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. |
||
|
Tom Tromey
|
6c28e44a35 |
Remove Python 2.4 and 2.5 support
This removes all the remainings spots I could find that work around issues in Python 2.4 and 2.5. I don't have a good way to test that Python 2.6 still works. Tested by the buildbot. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround. gdb/testsuite/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * lib/gdb.exp (skip_python_tests_prompt): Don't check for Python 2.4. * gdb.python/py-finish-breakpoint.exp: Remove Python 2.4 workaround. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround. |
||
|
Tom Tromey
|
8833fbf05c |
Style improvements in gdb/python
This fixes a few minor style issues I found in gdb/python: some unnecessary casts, the removal of an unnecessary local variable, and one instance of incorrect formatting. Tested by rebuilding and re-running gdb.python. gdb/ChangeLog 2019-01-02 Tom Tromey <tom@tromey.com> * python/py-inferior.c (gdbpy_initialize_inferior): Fix indentation. * python/py-frame.c (frapy_older): Remove cast. (frapy_newer): Likewise. * python/py-breakpoint.c (local_setattro): Remove cast. * python/py-arch.c (archpy_name): Remove local variable. * python/py-type.c (gdbpy_lookup_type): Remove cast. |
||
|
Joel Brobecker
|
42a4f53d2b |
Update copyright year range in all GDB files.
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. |
||
|
Tom Tromey
|
ec9c2750b7 |
Use gdbpy_convert_exception in a few more spots
I noticed a few places were converting a gdb exception to a Python exception "by hand". It's better to use the existing gdbpy_convert_exception helper function, as this handles memory errors correctly, and in the future may be enhanced in other ways. gdb/ChangeLog 2018-12-27 Tom Tromey <tom@tromey.com> * python/py-value.c (convert_value_from_python): Use gdbpy_convert_exception. * python/py-param.c (parmpy_init): Use gdbpy_convert_exception. * python/py-cmd.c (cmdpy_init): Use gdbpy_convert_exception. * python/py-breakpoint.c (bppy_init): Use gdbpy_convert_exception. |
||
|
Tom Tromey
|
833d985d1c |
Return gdbpy_ref from some Python string functions
This changes python_string_to_unicode, python_string_to_target_python_string, and host_string_to_python_string to return gdbpy_ref. gdb/ChangeLog 2018-11-04 Tom Tromey <tom@tromey.com> * python/python.c (gdbpy_parameter_value): Update. * python/python-internal.h (python_string_to_unicode) (python_string_to_target_python_string) (host_string_to_python_string): Return gdbpy_ref. * python/py-utils.c (python_string_to_unicode) (unicode_to_encoded_python_string) (unicode_to_target_python_string) (python_string_to_target_string) (python_string_to_target_python_string): Return gdbpy_ref. (python_string_to_host_string): Update. (host_string_to_python_string): Return gdbpy_ref. * python/py-symtab.c (stpy_get_filename, stpy_get_producer) (stpy_fullname): Update. * python/py-progspace.c (pspy_get_filename, pspy_solib_name): Update. * python/py-prettyprint.c (print_string_repr): Update. * python/py-objfile.c (objfpy_get_filename, objfpy_get_username) (objfpy_get_build_id): Update. * python/py-breakpoint.c (bppy_get_location) (bppy_get_expression, bppy_get_condition, bppy_get_commands): Update. |
||
|
Tom Tromey
|
2a8be20359 |
Fix Python gdb.Breakpoint.location crash
I noticed today that gdb.Breakpoint.location will crash when applied to a catchpoint made with "catch throw". The bug is that "catch throw" makes a breakpoint that is of type bp_breakpoint, but which does not have a location. Regression tested on x86-64 Fedora 28. gdb/ChangeLog 2018-10-06 Tom Tromey <tom@tromey.com> * python/py-breakpoint.c (bppy_get_location): Handle a bp_breakpoint without a location. gdb/testsuite/ChangeLog 2018-10-06 Tom Tromey <tom@tromey.com> * gdb.python/py-breakpoint.exp (check_last_event): Check location of a "throw" catchpoint. |