aboutsummaryrefslogtreecommitdiff
path: root/gdb/breakpoint.h
AgeCommit message (Collapse)AuthorFilesLines
2023-01-10Convert say_where to method on code_breakpointTom Tromey1-0/+4
'say_where' is only useful (and only called for) code breakpoints, so convert it to be a protected method on code_breakpoint.
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-19Use bool in bpstatTom Tromey1-5/+6
This changes bpstat to use 'bool' rather than 'char', and updates the uses.
2022-11-19Show locno for 'multi location' breakpoint hit msg+conv var $_hit_bbnum ↵Philippe Waroquiers1-0/+14
$_hit_locno PR breakpoints/12464 This implements the request given in PR breakpoints/12464. Before this patch, when a breakpoint that has multiple locations is reached, GDB printed: Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5 This patch changes the message so that bkpt_print_id prints the precise encountered breakpoint: Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5 In mi mode, bkpt_print_id also (optionally) prints a new table field "locno": locno is printed when the breakpoint hit has more than one location. Note that according to the GDB user manual node 'GDB/MI Development and Front Ends', it is ok to add new fields without changing the MI version. Also, when a breakpoint is reached, the convenience variables $_hit_bpnum and $_hit_locno are set to the encountered breakpoint number and location number. $_hit_bpnum and $_hit_locno can a.o. be used in the command list of a breakpoint, to disable the specific encountered breakpoint, e.g. disable $_hit_bpnum.$_hit_locno In case the breakpoint has only one location, $_hit_locno is set to the value 1, so as to allow a command such as: disable $_hit_bpnum.$_hit_locno to disable the breakpoint even when the breakpoint has only one location. This also fixes a strange behaviour: when a breakpoint X has only one location, enable|disable X.1 is accepted but transforms the breakpoint in a multiple locations breakpoint having only one location. The changes in RFA v4 handle the comments of Tom Tromey: - Changed convenience var names from $bkptno/$locno to $_hit_bpnum/$_hit_locno. - updated the tests and user manual accordingly. User manual also explictly describes that $_hit_locno is set to 1 for a breakpoint with a single location. - The variable values are now set in bpstat_do_actions_1 so that they are set for silent breakpoints, and when several breakpoints are hit at the same time, that the variables are set to the printed breakpoint. The changes in RFA v3 handle the additional comments of Eli: GDB/NEW: - Use max 80-column - Use 'code location' instead of 'location'. - Fix typo $bkpno - Ensure that disable $bkptno and disable $bkptno.$locno have each their explanation inthe example - Reworded the 'breakpoint-hit' paragraph. gdb.texinfo: - Use 'code location' instead of 'location'. - Add a note to clarify the distinction between $bkptno and $bpnum. - Use @kbd instead of examples with only one command. Compared to RFA v1, the changes in v2 handle the comments given by Keith Seitz and Eli Zaretskii: - Use %s for the result of paddress - Use bkptno_numopt_re instead of 2 different -re cases - use C@t{++} - Add index entries for $bkptno and $locno - Added an example for "locno" in the mi interface - Added examples in the Break command manual.
2022-08-30gdb: update ranged_breakpoint::print_one_detail in commentsEnze Li1-1/+1
The print_one_detail_ranged_breakpoint has been renamed to ranged_breakpoint::print_one_detail in this commit: commit ec45bb676c9c69c30783bcf35ffdac8280f3b8bc Date: Sat Jan 15 16:34:51 2022 -0700 Convert ranged breakpoints to vtable ops So their comments should be updated as well.
2022-08-26gdb: change bpstat_print's kind parameter to target_waitkindSimon Marchi1-4/+3
Change from int to target_waitkind, which is really what is is. While at it, remove some outdated doc. The return value is described by a relatively self-describing enum, not a numerical value like the doc says. Change-Id: Id899c853a857c7891c45e5b1639024067d5b59cd
2022-08-13Move decode_location_spec to code_breakpointTom Tromey1-13/+10
breakpoint::decode_location_spec just asserts if called. It turned out to be relatively easy to remove this method from breakpoint and instead move the base implementation to code_breakpoint.
2022-08-13Change location_spec_to_sals to a methodTom Tromey1-0/+8
location_spec_to_sals is only ever called for code breakpoints, so make it a protected method there.
2022-08-13Change breakpoint_re_set_default to a methodTom Tromey1-0/+5
breakpoint_re_set_default is only ever called from breakpoint re_set methods, so make it a protected method on code_breakpoint.
2022-08-10gdb/mi: fix breakpoint script field outputSimon Marchi1-0/+5
The "script" field, output whenever information about a breakpoint with commands is output, uses wrong MI syntax. $ ./gdb -nx -q --data-directory=data-directory -x script -i mi =thread-group-added,id="i1" =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",original-location="main"} =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"} (gdb) -break-info ^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="18",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}]} (gdb) In both the =breakpoint-modified and -break-info output, we have: script={"aaa","bbb","ccc"} According to the output syntax [1], curly braces means tuple, and a tuple contains key=value pairs. This looks like it should be a list, but uses curly braces by mistake. This would make more sense: script=["aaa","bbb","ccc"] Fix it, keeping the backwards compatibility by introducing a new MI version (MI4), in exactly the same way as was done when fixing multi-locations breakpoint output in [2]. - Add a fix_breakpoint_script_output uiout flag. MI uiouts will use this flag if the version is >= 4. - Add a fix_breakpoint_script_output_globally variable and the -fix-breakpoint-script-output MI command to set it, if frontends want to use the fixed output for this without using the newer MI version. - When emitting the script field, use list instead of tuple, if we want the fixed output (depending on the two criteria above) - [1] https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax [2] https://gitlab.com/gnutools/binutils-gdb/-/commit/b4be1b0648608a2578bbed39841c8ee411773edd Change-Id: I7113c6892832c8d6805badb06ce42496677e2242 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24285
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.