aboutsummaryrefslogtreecommitdiff
path: root/gdb/breakpoint.h
AgeCommit message (Collapse)AuthorFilesLines
2022-07-28gdb/python: Add BreakpointLocation typeSimon Farre1-0/+5
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-17event_location -> location_specPedro Alves1-30/+32
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-05-20Rename base_breakpoint -> code_breakpointPedro Alves1-8/+8
Even after the previous patches reworking the inheritance of several breakpoint types, the present breakpoint hierarchy looks a bit surprising, as we have "breakpoint" as the superclass, and then "base_breakpoint" inherits from "breakpoint". Like so, simplified: breakpoint base_breakpoint ordinary_breakpoint internal_breakpoint momentary_breakpoint ada_catchpoint exception_catchpoint tracepoint watchpoint catchpoint exec_catchpoint ... The surprising part to me is having "base_breakpoint" being a subclass of "breakpoint". I'm just refering to naming here -- I mean, you'd expect that it would be the top level baseclass that would be called "base". Just flipping the names of breakpoint and base_breakpoint around wouldn't be super great for us, IMO, given we think of every type of *point as a breakpoint at the user visible level. E.g., "info breakpoints" shows watchpoints, tracepoints, etc. So it makes to call the top level class breakpoint. Instead, I propose renaming base_breakpoint to code_breakpoint. The previous patches made sure that all code breakpoints inherit from base_breakpoint, so it's fitting. Also, "code breakpoint" contrasts nicely with a watchpoint also being typically known as a "data breakpoint". After this commit, the resulting hierarchy looks like: breakpoint code_breakpoint ordinary_breakpoint internal_breakpoint momentary_breakpoint ada_catchpoint exception_catchpoint tracepoint watchpoint catchpoint exec_catchpoint ... ... which makes a lot more sense to me. I've left this patch as last in the series in case people want to bikeshed on the naming. "code" has a nice property that it's exactly as many letters as "base", so this patch didn't require any reindentation. :-) Change-Id: Id8dc06683a69fad80d88e674f65e826d6a4e3f66
2022-05-20Add/tweak intro comments of struct breakpoint and several subclassesPedro Alves1-6/+7
This tweaks the intro comments of the following classes: internal_breakpoint momentary_breakpoint breakpoint base_breakpoint watchpoint catchpoint Change-Id: If6b31f51ebbb81705fbe5b8435f60ab2c88a98c8
2022-05-20Move add_location(sal) to base_breakpointPedro Alves1-4/+4
After the previous patches, only base_breakpoint subclasses use add_location(sal), so we can move it to base_breakpoint (a.k.a. base class for code breakpoints). This requires a few casts here and there, but always at spots where you can see from context what the breakpoint's type actually is. I inlined new_single_step_breakpoint into its only caller exactly for this reason. I did try to propagate more use of base_breakpoint to avoid casts, but that turned out unwieldy for this patch. Change-Id: I49d959322b0fdce5a88a216bb44730fc5dd7c6f8
2022-05-20Move common bits of catchpoint/exception_catchpoint to breakpoint's ctorPedro Alves1-8/+2
Move common bits of catchpoint and exception_catchpoint to breakpoint's ctor, to avoid duplicating code. Change-Id: I3a115180f4d496426522f1d89a3875026aea3cf2
2022-05-20Make catchpoint inherit breakpoint, eliminate init_raw_breakpointPedro Alves1-6/+1
struct catchpoint's ctor currently calls init_raw_breakpoint, which is a bit weird, as that ctor-like function takes a sal argument, but catchpoints don't have code locations. Instead, make struct catchpoint's ctor add the catchpoint's dummy location using add_dummy_location. init_raw_breakpoint uses add_location under the hood, and with a dummy sal it would ultimately use the breakpoint's gdbarch for the location's gdbarch, so replace the references to loc->gdbarch (which is now NULL) in syscall_catchpoint to references to the catchpoint's gdbarch. struct catchpoint's ctor was the last user of init_raw_breakpoint, so this commit eliminates the latter. Since catchpoint locations aren't code locations, make struct catchpoint inherit struct breakpoint instead of base_breakpoint. This let's us delete the tracepoint::re_set override too. Change-Id: Ib428bf71efb09fdaf399c56e4372b0f41d9c5869
2022-05-20Make breakpoint_address_bits look at the location kindPedro Alves1-0/+1
Software watchpoints allocate a special dummy location using software_watchpoint_add_no_memory_location, and then breakpoint_address_bits checks whether the location is that special location to decide whether the location has a meaninful address to print. Introduce a new bp_loc_software_watchpoint location kind, and make breakpoint_address_bits use bl_address_is_meaningful instead, which returns false for bp_loc_other, which is in accordance with we document for bp_location::address: /* (... snip ...) Valid for all types except bp_loc_other. */ CORE_ADDR address = 0; Rename software_watchpoint_add_no_memory_location to add_dummy_location, and simplify it. This will be used by catchpoints too in a following patch. Note that neither "info breakpoints" nor "maint info breakpoints" actually prints the addresses of watchpoints, but I think it would be useful to do so in "maint info breakpoints". This approach let's us implement that in the future. Change-Id: I50e398f66ef618c31ffa662da755eaba6295aed7
2022-05-20Convert init_ada_exception_catchpoint to a ctorPedro Alves1-11/+8
Currently, init_ada_exception_catchpoint is defined in breakpoint.c, I presume so it can call the static describe_other_breakpoints function. I think this is a dependency inversion. init_ada_exception_catchpoint, being code specific to Ada catchpoints, should be in ada-lang.c, and describe_other_breakpoints, a core function, should be exported. And then, we can convert init_ada_exception_catchpoint to an ada_catchpoint ctor. Change-Id: I07695572dabc5a75d3d3740fd9b95db1529406a1
2022-05-20init_breakpoint_sal -> base_breakpoint::base_breakpointPedro Alves1-0/+16
This converts init_breakpoint_sal to a base_breakpoint constructor. It removes a use of init_raw_breakpoint. To avoid manually adding a bunch of parameters to new_breakpoint_from_type, and manually passing them down to the constructors of a number of different base_breakpoint subclasses, make new_breakpoint_from_type a variable template function. Change-Id: I4cc24133ac4c292f547289ec782fc78e5bbe2510
2022-05-20More breakpoint_ops parameter eliminationPedro Alves1-2/+1
Remove breakpoint_ops parameters from a few functions that don't need it. Change-Id: Ifcf5e1cc688184acbf5e19b8ea60138ebe63cf28
2022-05-20Make a few functions work with base_breakpoint instead of breakpointPedro Alves1-7/+2
This makes tracepoints inherit from base_breakpoint, since their locations are code locations. If we do that, then we can eliminate tracepoint::re_set and tracepoint::decode_location, as they are doing the same as the base_breakpoint implementations. With this, all breakpoint types created by new_breakpoint_from_type are code breakpoints, i.e., base_breakpoint subclasses, and thus we can make it return a base_breakpoint pointer. Finally, init_breakpoint_sal can take a base_breakpoint pointer as "self" pointer too. This will let us convert this function to a base_breakpoint ctor in a following patch. Change-Id: I3a4073ff1a4c865f525588095c18dc42b744cb54
2022-05-20Make structs breakpoint/base_breakpoint/catchpoint be abstractPedro Alves1-1/+5
You should never instanciate these types directly. Change-Id: I8086c74c415eadbd44924bb0ef20f34b5b97ee6f
2022-05-20add_location_to_breakpoint -> breakpoint::add_locationPedro Alves1-0/+3
Make add_location_to_breakpoint be a method of struct breakpoint. A patch later in the series will move this to base_breakpoint, but for now, it needs to be here. Change-Id: I5bdc2ec1a7c2d66f26f51bf6f6adc8384a90b129
2022-05-06Introduce catchpoint classTom Tromey1-8/+14
This introduces a catchpoint class that is used as the base class for all catchpoints. init_catchpoint is rewritten to be a constructor instead. This changes the hierarchy a little -- some catchpoints now inherit from base_breakpoint whereas previously they did not. This isn't a problem, as long as re_set is redefined in catchpoint.
2022-05-06Add initializers to tracepointTom Tromey1-5/+5
This adds some initializers to tracepoint. I think right now these may not be needed, due to obscure rules about zero initialization. However, this will change in the next patch, and anyway it is clearer to be explicit.
2022-05-06Remove init_raw_breakpoint_without_locationTom Tromey1-5/+19
This removes init_raw_breakpoint_without_location, replacing it with a constructor on 'breakpoint' itself. The subclasses and callers are all updated.
2022-05-06Disable copying for breakpointTom Tromey1-0/+3
It seems to me that breakpoint should use DISABLE_COPY_AND_ASSIGN. This patch does this.
2022-05-06Constify breakpoint::print_recreateTom Tromey1-3/+3
This constifies breakpoint::print_recreate.
2022-05-06Constify breakpoint::print_mentionTom Tromey1-3/+3
This constifies breakpoint::print_mention.
2022-05-06Constify breakpoint::print_oneTom Tromey1-2/+2
This constifies breakpoint::print_one.
2022-05-06Constify breakpoint::print_itTom Tromey1-2/+2
This constifies breakpoint::print_it. Doing this pointed out some code in ada-lang.c that can be simplified a little as well.
2022-05-06Move works_in_software_mode to watchpointTom Tromey1-6/+6
works_in_software_mode is only useful for watchpoints. This patch moves it from breakpoint to watchpoint, and changes it to return bool.
2022-05-06Boolify breakpoint::explains_signalTom Tromey1-3/+3
This changes breakpoint::explains_signal to return bool.
2022-05-06Remove breakpoint::opsTom Tromey1-3/+0
The breakpoint::ops field is set but never used. This removes it.
2022-05-06Change print_recreate_thread to a methodTom Tromey1-10/+11
This changes print_recreate_thread to be a method on breakpoint. This function is only used as a helper by print_recreate methods, so I thought this transformation made sense.
2022-05-02gdb: remove type_wanted parameter from a few functionsSimon Marchi1-2/+1
The type_wanted value, passed down to the create_sals_from_location callback, is never used. Remove it. Change-Id: Ic363ee13f6af593a3e875ff7fe46de130cdc190c
2022-04-29Constify breakpoint_opsTom Tromey1-1/+1
Now that all breakpoint_ops are statically initialized, they can all be made const.
2022-04-29Remove breakpoint ops initializationTom Tromey1-2/+0
initialize_breakpoint_ops does not do much any more, so remove it in favor of statically-initialize objects.
2022-04-29Remove vtable_breakpoint_opsTom Tromey1-3/+1
There's no need to have vtable_breakpoint_ops any more, so remove it in favor of base_breakpoint_ops.
2022-04-29Remove most fields from breakpoint_opsTom Tromey1-93/+0
At this point, all implementations of breakpoints use the vtable. So, we can now remove most function pointers from breakpoint_ops and switch to using methods directly in the callers. Only the two "static virtual" methods remain in breakpoint_ops.
2022-04-29Remove breakpoint_ops from init_catchpointTom Tromey1-4/+2
init_catchpoint is only ever passed a single breakpoint_ops pointer, so remove the parameter.
2022-04-29Remove breakpoint_ops from init_ada_exception_breakpointTom Tromey1-1/+0
init_ada_exception_breakpoint is only ever passed a single breakpoint_ops structure, so remove the parameter.
2022-04-29Add bp_static_marker_tracepointTom Tromey1-0/+2
Because the actual construction of a breakpoint is buried deep in create_breakpoint, at present it's necessary to have a new bp_ enumerator constant any time a new subclass is needed. Static marker tracepoints are one such case, so this patch introduces bp_static_marker_tracepoint and updates various spots to recognize it.
2022-04-29Convert dprintf to vtable opsTom Tromey1-1/+0
This converts dprintf to use vtable_breakpoint_ops.
2022-04-29Convert ordinary breakpoints to vtable opsTom Tromey1-1/+0
This converts "ordinary" breakpoint to use vtable_breakpoint_ops. Recall that an ordinary breakpoint is both the kind normally created by users, and also a base class used by other classes.
2022-04-29Convert base breakpoints to vtable opsTom Tromey1-0/+11
This converts base breakpoints to use vtable_breakpoint_ops.
2022-04-29Add some new subclasses of breakpointTom Tromey1-0/+7
This adds a few new subclasses of breakpoint. The inheritance hierarchy is chosen to reflect what's already present in initialize_breakpoint_ops -- it mirrors the way that the _ops structures are filled in. This patch also changes new_breakpoint_from_type to create the correct sublcass based on bptype. This is important due to the somewhat inverted way in which create_breakpoint works; and in particular later patches will change some of these entries.
2022-04-29Convert tracepoints to vtable opsTom Tromey1-2/+13
This converts tracepoints to use vtable_breakpoint_ops.
2022-04-29Convert watchpoints to vtable opsTom Tromey1-0/+16
This converts watchpoints and masked watchpoints. to use vtable_breakpoint_ops. For masked watchpoints, a new subclass must be introduced, and watch_command_1 is changed to create one.
2022-04-29Add a vtable-based breakpoint opsTom Tromey1-0/+113
This adds methods to struct breakpoint. Each method has a similar signature to a corresponding function in breakpoint_ops, with the exceptions of create_sals_from_location and create_breakpoints_sal, which can't be virtual methods on breakpoint -- they are only used during the construction of breakpoints. Then, this adds a new vtable_breakpoint_ops structure and populates it with functions that simply forward a call from breakpoint_ops to the corresponding virtual method. These are all done with lambdas, because they are just a stepping stone -- by the end of the series, this structure will be deleted.
2022-04-29Return bool from breakpoint_ops::print_oneTom Tromey1-2/+3
This changes breakpoint_ops::print_one to return bool, and updates all the implementations and the caller. The caller is changed so that a NULL check is no longer needed -- something that will be impossible with a real method.
2022-04-29Boolify print_solib_eventTom Tromey1-1/+1
Change print_solib_event to accept a bool parameter and update the callers.
2022-04-29Move "catch load" to a new fileTom Tromey1-0/+6
The "catch load" code is reasonably self-contained, and so this patch moves it out of breakpoint.c and into a new file, break-catch-load.c. One function from breakpoint.c, print_solib_event, now has to be exposed, but this seems pretty reasonable.
2022-03-21Watchpoint followed by catchpoint misreports watchpoint (PR gdb/28621)Pedro Alves1-3/+22
If GDB reports a watchpoint hit, and then the next event is not TARGET_WAITKIND_STOPPED, but instead some event for which there's a catchpoint, such that GDB calls bpstat_stop_status, GDB mistakenly thinks the watchpoint triggered. Vis, using foll-fork.c: (gdb) awatch v Hardware access (read/write) watchpoint 2: v (gdb) catch fork Catchpoint 3 (fork) (gdb) c Continuing. Hardware access (read/write) watchpoint 2: v Old value = 0 New value = 5 main () at gdb.base/foll-fork.c:16 16 pid = fork (); (gdb) Continuing. Hardware access (read/write) watchpoint 2: v <<<< <<<< these lines are spurious Value = 5 <<<< Catchpoint 3 (forked process 1712369), arch_fork (ctid=0x7ffff7fa4810) at arch-fork.h:49 49 arch-fork.h: No such file or directory. (gdb) The problem is that when we handle the fork event, nothing called watchpoints_triggered before calling bpstat_stop_status. Thus, each watchpoint's watchpoint_triggered field was still set to watch_triggered_yes from the previous (real) watchpoint stop. watchpoint_triggered is only current called in the handle_signal_stop path, when handling TARGET_WAITKIND_STOPPED. This fixes it by adding watchpoint_triggered calls in the other events paths that call bpstat_stop_status. But instead of adding them explicitly, it adds a new function bpstat_stop_status_nowatch that wraps bpstat_stop_status and calls watchpoint_triggered, and then replaces most calls to bpstat_stop_status with calls to bpstat_stop_status_nowatch. This required constifying watchpoints_triggered. New test included, which fails without the fix. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28621 Change-Id: I282b38c2eee428d25319af3bc842f9feafed461c
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-22gdb: pass more const target_waitstatus by referenceSimon Marchi1-5/+5
While working on target_waitstatus changes, I noticed a few places where const target_waitstatus objects could be passed by reference instead of by pointers. And in some cases, places where a target_waitstatus could be passed as const, but was not. Convert them as much as possible. Change-Id: Ied552d464be5d5b87489913b95f9720a5ad50c5a
2021-11-08gdb: remove bpstat typedef, rename bpstats to bpstatSimon Marchi1-25/+23
I don't find that the bpstat typedef, which hides a pointer, is particularly useful. In fact, it confused me many times, and I just see it as something to remember that adds cognitive load. Also, with C++, we might want to be able to pass bpstats objects by const-reference, not necessarily by pointer. So, remove the bpstat typedef and rename struct bpstats to bpstat (since it represents one bpstat, it makes sense that it is singular). Change-Id: I52e763b6e54ee666a9e045785f686d37b4f5f849
2021-10-20Use unique_xmalloc_ptr in breakpointTom Tromey1-3/+3
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 bp_locationTom Tromey1-2/+2
This changes struct bp_location to use a unique_xmalloc_ptr, removing a bit of manual memory management.