aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-breakpoint.c
AgeCommit message (Collapse)AuthorFilesLines
2023-05-25gdb: remove breakpoint_pointer_iteratorSimon Marchi1-2/+2
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>
2023-05-25gdb: remove bp_location_pointer_iteratorSimon Marchi1-2/+2
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>
2023-05-05gdb/python: add mechanism to manage Python initialization functionsAndrew Burgess1-2/+5
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.
2023-02-28gdb: fix mi breakpoint-deleted notifications for thread-specific b/pAndrew Burgess1-0/+3
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 49fa26b0411d, but the commit message offers no clues to why this approach was taken, and the original email thread offers no insights either[2]. There are no test regressions after making this change, so I'm hopeful that this is going to be fine. [2] https://sourceware.org/pipermail/gdb-patches/2013-September/106493.html The Complication ---------------- Of course, it couldn't be that simple. The script gdb.python/py-finish-breakpoint.exp had some regressions during testing. The problem was with the FinishBreakpoint.out_of_scope callback implementation. This callback is supposed to trigger whenever the FinishBreakpoint goes out of scope; and this includes when the thread for the breakpoint exits. The problem I ran into is the Python FinishBreakpoint implementation. Specifically, after this change I was loosing some of the out_of_scope calls. The problem is that the out_of_scope call (of which I'm interested) is triggered from the inferior_exit observer. Before my change the observers were called in this order: thread_exit inferior_exit breakpoint_deleted The inferior_exit would trigger the out_of_scope call. After my change the breakpoint_deleted notification (for thread-specific breakpoints) occurs earlier, as soon as the thread-exits, so now the order is: thread_exit breakpoint_deleted inferior_exit Currently, after the breakpoint_deleted call the Python object associated with the breakpoint is released, so, when we get to the inferior_exit observer, there's no longer a Python object to call the out_of_scope method on. My solution is to follow the model for how bpfinishpy_pre_stop_hook and bpfinishpy_post_stop_hook are called, this is done from gdbpy_breakpoint_cond_says_stop in py-breakpoint.c. I've now added a new bpfinishpy_pre_delete_hook gdbpy_breakpoint_deleted in py-breakpoint.c, and from this new hook function I check and where needed call the out_of_scope method. With this fix in place I now see the gdb.python/py-finish-breakpoint.exp test fully passing again. Testing ------- Tested on x86-64/Linux with unix, native-gdbserver, and native-extended-gdbserver boards. New tests added to covers all the cases I've discussed above. Approved-By: Pedro Alves <pedro@palves.net>
2023-02-12gdb: use -1 for breakpoint::task default valueAndrew Burgess1-3/+3
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>
2023-02-12gdb: only allow one of thread or task on breakpoints or watchpointsAndrew Burgess1-0/+14
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>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
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.
2022-12-15gdb: remove static buffer in command_line_inputSimon Marchi1-1/+1
[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>
2022-12-07Remove unnecessary xstrdup from bppy_initTom Tromey1-6/+4
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.
2022-10-20gdb/python: break more dependencies between gdbpy_initialize_* functionsAndrew Burgess1-2/+21
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.
2022-08-31Use ui_out_redirect_pop in more placesTom Tromey1-3/+1
This changes ui_out_redirect_pop to also perform the redirection, and then updates several sites to use this, rather than explicit redirects.
2022-07-28gdb/python: Add BreakpointLocation typeSimon Farre1-0/+316
PR python/18385 v7: This version addresses the issues pointed out by Tom. Added nullchecks for Python object creations. Changed from using PyLong_FromLong to the gdb_py-versions. Re-factored some code to make it look more cohesive. Also added the more safe Python reference count decrement PY_XDECREF, even though the BreakpointLocation type is never instantiated by the user (explicitly documented in the docs) decrementing < 0 is made impossible with the safe call. Tom pointed out that using the policy class explicitly to decrement a reference counted object was not the way to go, so this has instead been wrapped in a ref_ptr that handles that for us in blocpy_dealloc. Moved macro from py-internal to py-breakpoint.c. Renamed section at the bottom of commit message "Patch Description". v6: This version addresses the points Pedro gave in review to this patch. Added the attributes `function`, `fullname` and `thread_groups` as per request by Pedro with the argument that it more resembles the output of the MI-command "-break-list". Added documentation for these attributes. Cleaned up left overs from copy+paste in test suite, removed hard coding of line numbers where possible. Refactored some code to use more c++-y style range for loops wrt to breakpoint locations. Changed terminology, naming was very inconsistent. Used a variety of "parent", "owner". Now "owner" is the only term used, and the field in the gdb_breakpoint_location_object now also called "owner". v5: Changes in response to review by Tom Tromey: - Replaced manual INCREF/DECREF calls with gdbpy_ref ptrs in places where possible. - Fixed non-gdb style conforming formatting - Get parent of bploc increases ref count of parent. - moved bploc Python definition to py-breakpoint.c The INCREF of self in bppy_get_locations is due to the individual locations holding a reference to it's owner. This is decremented at de-alloc time. The reason why this needs to be here is, if the user writes for instance; py loc = gdb.breakpoints()[X].locations[Y] The breakpoint owner object is immediately going out of scope (GC'd/dealloced), and the location object requires it to be alive for as long as it is alive. Thanks for your review, Tom! v4: Fixed remaining doc issues as per request by Eli. v3: Rewritten commit message, shortened + reworded, added tests. Patch Description Currently, the Python API lacks the ability to query breakpoints for their installed locations, and subsequently, can't query any information about them, or enable/disable individual locations. This patch solves this by adding Python type gdb.BreakpointLocation. The type is never instantiated by the user of the Python API directly, but is produced by the gdb.Breakpoint.locations attribute returning a list of gdb.BreakpointLocation. gdb.Breakpoint.locations: The attribute for retrieving the currently installed breakpoint locations for gdb.Breakpoint. Matches behavior of the "info breakpoints" command in that it only returns the last known or currently inserted breakpoint locations. BreakpointLocation contains 7 attributes 6 read-only attributes: owner: location owner's Python companion object source: file path and line number tuple: (string, long) / None address: installed address of the location function: function name where location was set fullname: fullname where location was set thread_groups: thread groups (inferiors) where location was set. 1 writeable attribute: enabled: get/set enable/disable this location (bool) Access/calls to these, can all throw Python exceptions (documented in the online documentation), and that's due to the nature of how breakpoint locations can be invalidated "behind the scenes", either by them being removed from the original breakpoint or changed, like for instance when a new symbol file is loaded, at which point all breakpoint locations are re-created by GDB. Therefore this patch has chosen to be non-intrusive: it's up to the Python user to re-request the locations if they become invalid. Also there's event handlers that handle new object files etc, if a Python user is storing breakpoint locations in some larger state they've built up, refreshing the locations is easy and it only comes with runtime overhead when the Python user wants to use them. gdb.BreakpointLocation Python type struct "gdbpy_breakpoint_location_object" is found in python-internal.h Its definition, layout, methods and functions are found in the same file as gdb.Breakpoint (py-breakpoint.c) 1 change was also made to breakpoint.h/c to make it possible to enable and disable a bp_location* specifically, without having its LOC_NUM, as this number also can change arbitrarily behind the scenes. Updated docs & news file as per request. Testsuite: tests the .source attribute and the disabling of individual locations. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385 Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0
2022-06-17Convert location_spec_to_string to a methodPedro Alves1-1/+1
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
2022-06-17Eliminate the two-level data structures behind location_specsPedro Alves1-9/+12
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
2022-06-17event_location -> location_specPedro Alves1-10/+10
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
2022-03-29Unify gdb printf functionsTom Tromey1-1/+1
Now that filtered and unfiltered output can be treated identically, we can unify the printf family of functions. This is done under the name "gdb_printf". Most of this patch was written by script.
2022-03-23gdb/python: remove Python 2/3 compatibility macrosSimon Marchi1-6/+6
New in this version: - Rebase on master, fix a few more issues that appeared. python-internal.h contains a number of macros that helped make the code work with both Python 2 and 3. Remove them and adjust the code to use the Python 3 functions. Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d
2022-01-26Change how Python architecture and language are handledTom Tromey1-13/+6
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.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
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.
2021-11-16gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptrAndrew Burgess1-1/+1
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.
2021-10-20Use unique_xmalloc_ptr in breakpointTom Tromey1-1/+1
This changes struct breakpoint to use unique_xmalloc_ptr in a couple of spots, removing a bit of manual memory management.
2021-10-20Use unique_xmalloc_ptr in watchpointTom Tromey1-1/+1
This changes struct watchpoint to use unique_xmalloc_ptr in a couple of places, removing a bit of manual memory management.
2021-06-25gdb/python: allow for catchpoint type breakpoints in pythonAndrew Burgess1-1/+5
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.
2021-05-27gdb: remove iterate_over_breakpoints functionSimon Marchi1-16/+11
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
2021-05-09gdb/py: add some debugging to py-breakpoint.cAndrew Burgess1-3/+56
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'.
2021-04-24gdbsupport, gdb: give names to observersSimon Marchi1-3/+6
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
2021-04-21gdb/breakpoint: add a 'force_condition' parameter to 'create_breakpoint'Tankut Baris Aktemur1-1/+1
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.
2021-01-21Add Python support for hardware breakpointsHannes Domani1-2/+6
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.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
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.
2020-10-27gdb/breakpoint: add flags to 'condition' and 'break' commands to force conditionTankut Baris Aktemur1-1/+1
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.
2020-09-15Don't use PyInt_FromLongTom Tromey1-6/+6
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.
2020-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-12-09Fix scripted probe breakpointsGeorge Barrett1-1/+4
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.
2019-11-14Fix python gdbpy_breakpoint_object leak.Philippe Waroquiers1-1/+1
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.
2019-10-15Change iterate_over_breakpoints to take a function_viewChristian Biesinger1-6/+9
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
2019-07-09"catch catch/throw/rethrow", breakpoint -> catchpointPedro Alves1-7/+1
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 2a8be20359dba9cc684fd3ffa222d985399f3b18 Commit: Tom Tromey <tom@tromey.com> CommitDate: Sat Oct 6 22:17:45 2018 -0600 Fix Python gdb.Breakpoint.location crash because now "catch throw" catchpoints hit the if (obj->bp->type != bp_breakpoint) Py_RETURN_NONE; check above, and, adjusts the testcase to no longer expect to see the catchpoint in the gdb.breakpoints() list. (Note: might make sense to do the same to Ada exception catchpoints.) gdb/ChangeLog: 2019-07-09 Pedro Alves <palves@redhat.com> * break-catch-throw.c (print_one_exception_catchpoint): Skip the "addr" field. (allocate_location_exception_catchpoint): New. (handle_gnu_v3_exceptions): Don't reset 'type' to bp_breakpoint. (initialize_throw_catchpoint_ops): Install allocate_location_exception_catchpoint as allocate_location method. * breakpoint.c (bpstat_what) <bp_catch>: Set action to BPSTAT_WHAT_SINGLE if not stopping and the location's type is not bp_loc_other. (breakpoint_address_is_meaningful): Delete. (bl_address_is_meaningful): New. (breakpoint_locations_match): Adjust comment. (bp_location_from_bp_type): New, factored out of... (bp_location::bp_location(breakpoint *)): ... this. (bp_location::bp_location(breakpoint *, bp_loc_type)): New, factored out of... (bp_location::bp_location(breakpoint *)): ... this. Reimplement. (bp_loc_is_permanent): Use bl_address_is_meaningful instead of breakpoint_address_is_meaningful. (bp_locations_compare): Adjust comment. (update_global_location_list): Use bl_address_is_meaningful instead of breakpoint_address_is_meaningful. * breakpoint.h (bp_location::bp_location(breakpoint *)): New explicit. (bp_location::bp_location(breakpoint *, bp_loc_type)): Declare. * python/py-breakpoint.c (bppy_get_location): No longer check whether location is null. gdb/doc/ChangeLog: 2019-07-09 Pedro Alves <palves@redhat.com> * gdb.texinfo (C++ Exception GDB/MI Catchpoint Commands): Adjust examples to show type=catchpoint instead of type=breakpoint and an address. gdb/testsuite/ChangeLog: 2019-07-09 Pedro Alves <palves@redhat.com> * gdb.cp/catch-multi-stdlib.exp: Adjust expected "info breakpoints" output. * gdb.cp/exception.exp: Adjust expected "info breakpoints" output. * gdb.python/py-breakpoint.exp: No longer expect that "catch throw" creates breakpoint. * gdb.mi/mi-catch-cpp-exceptions.exp (setup_catchpoint): Expect 'type="catchpoint"'.
2019-06-10Use gdbpy_enter in py-breakpoint.cTom Tromey1-10/+8
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.
2019-04-25Make exception handling more efficientTom Tromey1-4/+4
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.
2019-04-25Remove exception_noneTom Tromey1-2/+2
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.
2019-04-08Rename gdb exception typesTom Tromey1-8/+8
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.
2019-04-08Rewrite TRY/CATCHTom Tromey1-24/+16
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.
2019-02-27Remove Python 2.4 and 2.5 supportTom Tromey1-6/+2
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.
2019-01-02Style improvements in gdb/pythonTom Tromey1-1/+1
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.
2019-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
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.
2018-12-27Use gdbpy_convert_exception in a few more spotsTom Tromey1-3/+1
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.
2018-11-04Return gdbpy_ref from some Python string functionsTom Tromey1-4/+4
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.
2018-10-06Fix Python gdb.Breakpoint.location crashTom Tromey1-1/+6
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.
2018-07-22Simple unused variable removalsTom Tromey1-1/+0
This patch holds all the straightforward unused variable deletions. gdb/ChangeLog 2018-07-22 Tom Tromey <tom@tromey.com> * guile/scm-value.c (gdbscm_value_call): Remove unused variables. * guile/scm-math.c (vlscm_unop_gdbthrow, vlscm_binop_gdbthrow) (vlscm_convert_typed_value_from_scheme): Remove unused variable. * buildsym-legacy.c (get_macro_table): Remove unused variable. * stack.c (frame_apply_level_command): Remove unused variable. * tic6x-tdep.c (tic6x_push_dummy_call): Remove unused variable. * sparc64-tdep.c (adi_examine_command): Remove unused variable. * rs6000-lynx178-tdep.c (rs6000_lynx178_push_dummy_call): Remove unused variable. * nios2-tdep.c (nios2_push_dummy_call): Remove unused variable. * mep-tdep.c (mep_push_dummy_call): Remove unused variable. * ada-lang.c (ada_lookup_symbol_list_worker): Remove unused variable. * amd64-tdep.c (amd64_supply_xsave): Remove unused variable. * arm-tdep.c (arm_record_data_proc_misc_ld_str): Remove unused variable. * breakpoint.c (check_no_tracepoint_commands, update_watchpoint): Remove unused variable. * cli/cli-script.c (recurse_read_control_structure): Remove unused variable. * common/tdesc.c (print_xml_feature::visit): Remove unused variable. * compile/compile-object-load.c (store_regs): Remove unused variables. * complaints.c (clear_complaints): Remove unused variable. * corelow.c (core_target_open): Remove unused variable. * fbsd-tdep.c (fbsd_core_info_proc_status): Remove unused variable. * guile/scm-frame.c (gdbscm_frame_read_var): Remove unused variable. * guile/scm-symtab.c (stscm_print_sal_smob): Remove unused variable. * guile/scm-type.c (gdbscm_field_baseclass_p): Remove unused variable. * guile/scm-utils.c (gdbscm_parse_function_args): Remove unused variable. * hppa-tdep.c (hppa_stub_frame_unwind_cache): Remove unused variable. * ia64-tdep.c (examine_prologue): Remove unused variable. * infcall.c (run_inferior_call): Remove unused variable. * inferior.c (exit_inferior): Remove unused variable. * infrun.c (infrun_thread_ptid_changed): Remove unused variable. * linespec.c (decode_line_2): Remove unused variable. * linux-nat.c (super_close): Remove. * linux-tdep.c (linux_info_proc): Remove unused variable. * mi/mi-main.c (mi_execute_command): Remove unused variable. * microblaze-linux-tdep.c (microblaze_linux_sigtramp_cache): Remove unused variable. * parse.c (find_minsym_type_and_address): Remove unused variable. * printcmd.c (info_symbol_command, printf_floating): Remove unused variable. * python/py-breakpoint.c (bppy_set_commands): Remove unused variable. * python/py-unwind.c (unwind_infopy_dealloc): Remove unused variables. * record-btrace.c (record_btrace_target::store_registers): Remove unused variable. (cmd_show_record_btrace_cpu): Remove unused variable. * riscv-tdep.c (riscv_register_reggroup_p) (riscv_push_dummy_call, riscv_return_value): Remove unused variable. * rust-exp.y (literal): Remove unused variable. * rust-lang.c (rust_evaluate_subexp) <OP_RUST_ARARAY>: Remove unused variable. <STRUCTOP_ANONYMOUS>: Likewise. * s390-linux-tdep.c (s390_linux_init_abi_31) (s390_linux_init_abi_64): Remove unused variable. * ser-ming2.c (ser_windows_read_prim, pipe_select_thread) (file_select_thread, net_windows_open, _initialize_ser_windows): Remove unused variables. * symtab.c (find_pc_sect_line): Remove unused variable. * target-memory.c (compute_garbled_blocks): Remove unused variable. (target_write_memory_blocks): Remove unused variable. * target.c (target_stack::unpush): Remove unused variables. * tracepoint.c (start_tracing, all_tracepoint_actions) (merge_uploaded_trace_state_variables) (print_one_static_tracepoint_marker): Remove unused variable. * unittests/basic_string_view/element_access/char/1.cc (test01): Remove unused variable. * windows-nat.c (windows_continue, windows_add_all_dlls) (do_initial_windows_stuff, windows_nat_target::create_inferior): Remove unused variables.
2018-05-04Allow breakpoint commands to be set from PythonTom Tromey1-1/+44
This changes the Python API so that breakpoint commands can be set by writing to the "commands" attribute. ChangeLog 2018-05-04 Tom Tromey <tom@tromey.com> PR python/22731: * NEWS: Mention that breakpoint commands are writable. * python/py-breakpoint.c (bppy_set_commands): New function. (breakpoint_object_getset) <"commands">: Use it. doc/ChangeLog 2018-05-04 Tom Tromey <tom@tromey.com> PR python/22731: * python.texi (Breakpoints In Python): Mention that "commands" is writable. testsuite/ChangeLog 2018-05-04 Tom Tromey <tom@tromey.com> PR python/22731: * gdb.python/py-breakpoint.exp: Test setting breakpoint commands.
2018-03-19Convert observers to C++Tom Tromey1-4/+4
This converts observers from using a special source-generating script to be plain C++. This version of the patch takes advantage of C++11 by using std::function and variadic templates; incorporates Pedro's patches; and renames the header file to "observable.h" (this change eliminates the need for a clean rebuild). Note that Pedro's patches used a template lambda in tui-hooks.c, but this failed to compile on some buildbot instances (presumably due to differing C++ versions); I replaced this with an ordinary template function. Regression tested on the buildbot. gdb/ChangeLog 2018-03-19 Pedro Alves <palves@redhat.com> Tom Tromey <tom@tromey.com> * unittests/observable-selftests.c: New file. * common/observable.h: New file. * observable.h: New file. * ada-lang.c, ada-tasks.c, agent.c, aix-thread.c, annotate.c, arm-tdep.c, auto-load.c, auxv.c, break-catch-syscall.c, breakpoint.c, bsd-uthread.c, cli/cli-interp.c, cli/cli-setshow.c, corefile.c, dummy-frame.c, event-loop.c, event-top.c, exec.c, extension.c, frame.c, gdbarch.c, guile/scm-breakpoint.c, infcall.c, infcmd.c, inferior.c, inflow.c, infrun.c, jit.c, linux-tdep.c, linux-thread-db.c, m68klinux-tdep.c, mi/mi-cmd-break.c, mi/mi-interp.c, mi/mi-main.c, objfiles.c, ppc-linux-nat.c, ppc-linux-tdep.c, printcmd.c, procfs.c, python/py-breakpoint.c, python/py-finishbreakpoint.c, python/py-inferior.c, python/py-unwind.c, ravenscar-thread.c, record-btrace.c, record-full.c, record.c, regcache.c, remote.c, riscv-tdep.c, sol-thread.c, solib-aix.c, solib-spu.c, solib.c, spu-multiarch.c, spu-tdep.c, stack.c, symfile-mem.c, symfile.c, symtab.c, thread.c, top.c, tracepoint.c, tui/tui-hooks.c, tui/tui-interp.c, valops.c: Update all users. * tui/tui-hooks.c (tui_bp_created_observer) (tui_bp_deleted_observer, tui_bp_modified_observer) (tui_inferior_exit_observer, tui_before_prompt_observer) (tui_normal_stop_observer, tui_register_changed_observer): Remove. (tui_observers_token): New global. (attach_or_detach, tui_attach_detach_observers): New functions. (tui_install_hooks, tui_remove_hooks): Use tui_attach_detach_observers. * record-btrace.c (record_btrace_thread_observer): Remove. (record_btrace_thread_observer_token): New global. * observer.sh: Remove. * observer.c: Rename to observable.c. * observable.c (namespace gdb_observers): Define new objects. (observer_debug): Move into gdb_observers namespace. (struct observer, struct observer_list, xalloc_observer_list_node) (xfree_observer_list_node, generic_observer_attach) (generic_observer_detach, generic_observer_notify): Remove. (_initialize_observer): Update. Don't include observer.inc. * Makefile.in (generated_files): Remove observer.h, observer.inc. (clean mostlyclean): Likewise. (observer.h, observer.inc): Remove targets. (SUBDIR_UNITTESTS_SRCS): Add observable-selftests.c. (COMMON_SFILES): Use observable.c, not observer.c. * .gitignore: Remove observer.h. gdb/doc/ChangeLog 2018-03-19 Tom Tromey <tom@tromey.com> * observer.texi: Remove. gdb/testsuite/ChangeLog 2018-03-19 Tom Tromey <tom@tromey.com> * gdb.gdb/observer.exp: Remove.
generated by cgit v1.1 at 2025-04-02 15:38:01 +0000