aboutsummaryrefslogtreecommitdiff
path: root/gdb/breakpoint.c
AgeCommit message (Collapse)AuthorFilesLines
2022-10-25[gdb] Rewrite RETHROW_ON_TARGET_CLOSE_ERROR into functionTom de Vries1-20/+25
Recent commit b2829fcf9b5 ("[gdb] Fix rethrow exception slicing in insert_bp_location") introduced macro RETHROW_ON_TARGET_CLOSE_ERROR. I wrote this as a macro in order to have the rethrowing throw be part of the same function as the catch, but as it turns out that's not necessary. Rewrite into a function. Tested on x86_64-linux.
2022-10-24[gdb] Fix rethrow exception slicing in insert_bp_locationTom de Vries1-7/+21
The preferred way of rethrowing an exception is by using throw without expression, because it avoids object slicing of the exception [1]. Fix this in insert_bp_location. Tested on x86_64-linux. [1] https://en.cppreference.com/w/cpp/language/throw Approved-By: Andrew Burgess <aburgess@redhat.com>
2022-10-20gdb: some int to bool conversion in breakpoint.cAndrew Burgess1-141/+135
Some int to bool conversion in breakpoint.c. I've only updated the function signatures of static functions, but I've updated some function local variables throughout the file. There should be no user visible changes after this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-10-20gdb: make use of scoped_restore in unduplicated_should_be_insertedAndrew Burgess1-7/+4
I noticed that we could make use of a scoped_restore in the function unduplicated_should_be_inserted. I've also converted the function return type from int to bool. This change shouldn't make any difference, as I don't think anything within should_be_inserted could throw an exception, but the change doesn't hurt, and will help keep us safe if anything ever changes in the future. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-10-20gdb: used scoped_restore_frame in update_watchpointAndrew Burgess1-12/+5
I was doing some int to bool cleanup in update_watchpoint, and I noticed a manual version of scoped_restore_selected_frame. As always when these things are done manually, there is the chance that, in an error case, we might leave the wrong frame selected. This commit updates things to use scoped_restore_selected_frame, and also converts a local variable from int to bool. The only user visible change after this commit is in the case where update_watchpoint throws an error - we should now correctly restore the previously selected frame. Otherwise, this commit should be invisible to the user. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-10-20gdb: make some bp_location arguments const in breakpoint.cAndrew Burgess1-14/+14
I spotted a few places where I could make some 'bp_location *' arguments constant in breakpoint.c. There should be no user visible changes after this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-10-19[gdb] Fix assert in handle_jit_eventTom de Vries1-1/+4
With the cc-with-tweaks.sh patch submitted here ( https://sourceware.org/pipermail/gdb-patches/2022-October/192586.html ) we run with: ... $ export STRIP_ARGS_STRIP_DEBUG=--strip-all $ make check RUNTESTFLAGS="gdb.base/jit-reader.exp \ --target_board cc-with-gnu-debuglink" ... into the following assert: ... (gdb) run ^M Starting program: jit-reader ^M gdb/jit.c:1247: internal-error: jit_event_handler: \ Assertion `jiter->jiter_data != nullptr' failed.^M ... Fix this by handling the jit_bp_sym.objfile->separate_debug_objfile_backlink != nullptr case in handle_jit_event. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29277
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-27/+14
Currently, every internal_error call must be passed __FILE__/__LINE__ explicitly, like: internal_error (__FILE__, __LINE__, "foo %d", var); The need to pass in explicit __FILE__/__LINE__ is there probably because the function predates widespread and portable variadic macros availability. We can use variadic macros nowadays, and in fact, we already use them in several places, including the related gdb_assert_not_reached. So this patch renames the internal_error function to something else, and then reimplements internal_error as a variadic macro that expands __FILE__/__LINE__ itself. The result is that we now should call internal_error like so: internal_error ("foo %d", var); Likewise for internal_warning. The patch adjusts all calls sites. 99% of the adjustments were done with a perl/sed script. The non-mechanical changes are in gdbsupport/errors.h, gdbsupport/gdb_assert.h, and gdb/gdbarch.py. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
2022-10-16Use checked_static_cast in more placesTom Tromey1-4/+5
I looked through all the uses of static_cast<... *> in gdb and converted many of them to checked_static_cast. I couldn't test a few of these changes.
2022-10-14Use scoped_value_mark in more placesTom Tromey1-15/+9
I looked at all the spots using value_mark, and converted all the straightforward ones to use scoped_value_mark instead. Regression tested on x86-64 Fedora 34.
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-9/+9
This changes GDB to use frame_info_ptr instead of frame_info * The substitution was done with multiple sequential `sed` commands: sed 's/^struct frame_info;/class frame_info_ptr;/' sed 's/struct frame_info \*/frame_info_ptr /g' - which left some issues in a few files, that were manually fixed. sed 's/\<frame_info \*/frame_info_ptr /g' sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace problems. The changed files were then manually checked and some 'sed' changes undone, some constructors and some gets were added, according to what made sense, and what Tromey originally did Co-Authored-By: Bruno Larsen <blarsen@redhat.com> Approved-by: Tom Tomey <tom@tromey.com>
2022-10-10Remove frame_id_eqTom Tromey1-1/+1
This replaces frame_id_eq with operator== and operator!=. I wrote this for a version of this series that I later abandoned; but since it simplifies the code, I left this patch in. Approved-by: Tom Tomey <tom@tromey.com>
2022-10-06gdb: add missing nullptr checks in bpstat_check_breakpoint_conditionsAndrew Burgess1-2/+2
Add a couple of missing nullptr checks in the function bpstat_check_breakpoint_conditions. No user visible change after this commit.
2022-10-06gdb: more infrun debug from breakpoint.cAndrew Burgess1-2/+24
This commit adds additional infrun debug from the breakpoint.c file. The new debug output all relates to breakpoint condition evaluation. There is already some infrun debug emitted from the breakpoint.c file, so hopefully, adding more will not be contentious. I think the functions being instrumented make sense as part of the infrun process, the inferior stops, evaluates the condition, and then either stops or continues. This new debug gives more insight into that process. I had to make the bp_location* argument to find_loc_num_by_location const, and add a declaration for find_loc_num_by_location. There should be no user visible changes unless they turn on debug output.
2022-10-04Remove decode_location_spec_defaultTom Tromey1-30/+15
This removes decode_location_spec_default, inlining it into its sole caller. Regression tested on x86-64 Fedora 34.
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi1-2/+2
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-08-31Use ui_out_redirect_pop in more placesTom Tromey1-11/+2
This changes ui_out_redirect_pop to also perform the redirection, and then updates several sites to use this, rather than explicit redirects.
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-1/+1
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-7/+0
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-30/+32
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-10/+8
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-1/+17
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-28Rewrite registry.hTom Tromey1-1/+1
This rewrites registry.h, removing all the macros and replacing it with relatively ordinary template classes. The result is less code than the previous setup. It replaces large macros with a relatively straightforward C++ class, and now manages its own cleanup. The existing type-safe "key" class is replaced with the equivalent template class. This approach ended up requiring relatively few changes to the users of the registry code in gdb -- code using the key system just required a small change to the key's declaration. All existing users of the old C-like API are now converted to use the type-safe API. This mostly involved changing explicit deletion functions to be an operator() in a deleter class. The old "save/free" two-phase process is removed, and replaced with a single "free" phase. No existing code used both phases. The old "free" callbacks took a parameter for the enclosing container object. However, this wasn't truly needed and is removed here as well.
2022-07-28gdb/python: Add BreakpointLocation typeSimon Farre1-0/+57
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-07-21gdb: select suitable thread for gdbarch_adjust_breakpoint_addressAndrew Burgess1-7/+20
The three targets that implement gdbarch_adjust_breakpoint_address are arm, frv, and mips. In each of these targets the adjust breakpoint address function does some combination of reading the symbol table, or reading memory at the location the breakpoint could be placed. The problem is that performing these actions requires that the current inferior and program space be the one in which the breakpoint will be placed, and this is not currently always the case. Consider a GDB session with multiple inferiors. One inferior might be a native target while another could be a remote target of a completely different architecture. Alternatively, if we consider ARM and AArch64, one native inferior might be AArch64, while a second native inferior could be ARM. In these cases it is possible, and valid, for a user to have one inferior selected, and place a breakpoint in the other inferior by placing a breakpoint on a particular symbol. If this happens, then currently, when gdbarch_adjust_breakpoint_address is called, the wrong inferior (and program space) will be selected, and memory reads, and symbol look ups, will not return the expected results, this could lead to breakpoints being placed in the wrong location. There are currently two places where gdbarch_adjust_breakpoint_address is called: 1. In infrun.c, in the function handle_step_into_function. In this case, I believe that the correct inferior and program space will already be selected as this is called as part of the stop event handling, so I don't think we need to worry about this case, and 2. In breakpoint.c, in the function adjust_breakpoint_address, which is itself called from code_breakpoint::add_location and watch_command_1. The watch_command_1 case I don't think we need to worry about, this is for when a local watch expression is created, which can only be in the currently selected inferior, so this case should be fine. The code_breakpoint::add_location case is the one that needs fixing, this is what allows a breakpoint to be created between inferiors. To fix the code_breakpoint::add_location case, I propose that we pass the "correct" program_space (i.e. the program space in which the breakpoint will be created) to the adjust_breakpoint_address function. Then in adjust_breakpoint_address we can make use of switch_to_program_space_and_thread to switch program_space and inferior before calling gdbarch_adjust_breakpoint_address. I discovered this issue while working on a later patch in this series. This later patch will detect when we cast the result of gdbarch_tdep to the wrong type. With this later patch in place I ran gdb.multi/multi-arch.exp on an AArch64 target. In this situation, two inferiors are created, an AArch64 inferior, and an ARM inferior. The test selected the AArch64 inferior and tries to create a breakpoint in the ARM inferior. As a result of this we end up in arm_adjust_breakpoint_address, which calls arm_pc_is_thumb. Before this commit the AArch64 inferior would be current. As a result, all of the checks in arm_pc_is_thumb would fail (they rely on reading symbols from the current program space), and so, at the end of arm_pc_is_thumb we would call arm_frame_is_thumb. However, remember, at this point the current inferior is the AArch64 inferior, so the current frame is an AArch64 frame. In arm_frame_is_thumb we call arm_psr_thumb_bit, which calls gdbarch_tdep and casts the result to arm_gdbarch_tdep. This is wrong, the tdep field is of type aarch64_gdbarch_tdep. After this we have undefined behaviour. With this patch in place, we will have switched to a thread in the ARM program space before calling arm_adjust_breakpoint_address. As a result, we now succeed in looking up the required symbols in arm_pc_is_thumb, and so we never call arm_frame_is_thumb. However, in the worst case scenario, if we did end up calling arm_frame_is_thumb, as the current inferior should now be the ARM inferior, the current frame should be an ARM frame, so we still should not hit undefined behaviour. I have added an assert to arm_frame_is_thumb.
2022-07-13Fix "until LINE" in main, when "until" runs into longjmpPedro Alves1-1/+1
With a test like this: 1 #include <dlfcn.h> 2 int 3 main () 4 { 5 dlsym (RTLD_DEFAULT, "FOO"); 6 return 0; 7 } and then "start" followed by "until 6", GDB currently incorrectly stops inside the runtime loader, instead of line 6. Vis: ... Temporary breakpoint 1, main () at until.c:5 4 { (gdb) until 6 0x00007ffff7f0a90d in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffdb00, operate=<optimized out>, args=0x7ffff7f0a90d <__GI__dl_catch_exception+109>) at dl-error-skeleton.c:206 206 dl-error-skeleton.c: No such file or directory. (gdb) The problem is related to longjmp handling -- dlsym internally longjmps on error. The testcase can be reduced to this: 1 #include <setjmp.h> 2 void func () { 3 jmp_buf buf; 4 if (setjmp (buf) == 0) 5 longjmp (buf, 1); 6 } 7 8 int main () { 9 func (); 10 return 0; /* until to here */ 11 } and then with "start" followed by "until 10", GDB currently incorrectly stops at line 4 (returning from setjmp), instead of line 10. The problem is that the BPSTAT_WHAT_CLEAR_LONGJMP_RESUME code in infrun.c fails to find the initiating frame, and so infrun thinks that the longjmp jumped somewhere outer to "until"'s originating frame. Here: case BPSTAT_WHAT_CLEAR_LONGJMP_RESUME: { struct frame_info *init_frame; /* There are several cases to consider. 1. The initiating frame no longer exists. In this case we must stop, because the exception or longjmp has gone too far. ... init_frame = frame_find_by_id (ecs->event_thread->initiating_frame); if (init_frame) // this is NULL! { ... } /* For Cases 1 and 2, remove the step-resume breakpoint, if it exists. */ delete_step_resume_breakpoint (ecs->event_thread); end_stepping_range (ecs); // case 1., so we stop. } The initiating frame is set by until_break_command -> set_longjmp_breakpoint. The initiating frame is supposed to be the frame that is selected when the command was issued, but until_break_command instead passes the frame id of the _caller_ frame by mistake. When the "until LINE" command is issued from main, the caller frame is the caller of main. When later infrun tries to find that frame by id, it fails to find it, because frame_find_by_id doesn't unwind past main. The bug is that we passed the caller frame's id to set_longjmp_breakpoint. We should have passed the selected frame's id instead. Change-Id: Iaae1af7cdddf296b7c5af82c3b5b7d9b66755b1c
2022-06-17Convert location_spec_to_string to a methodPedro Alves1-23/+15
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-17Convert location_spec_type to a methodPedro Alves1-4/+4
This converts location_spec_type to location_spec::type(). Change-Id: Iff4cbfafb1cf3d22adfa142ff939b4a148e52273
2022-06-17Convert location_spec_empty_p to a methodPedro Alves1-2/+1
This converts location_spec_empty_p to a method of location_spec, simplifying users, as they no longer have to use std::unique_ptr::get(). Change-Id: I83381a729896f12e1c5a1b4d6d4c2eb1eb6582ff
2022-06-17Eliminate copy_location_specPedro Alves1-5/+5
copy_location_spec is just a wrapper around location_spec::clone(), so remove it and call clone() directly. This simplifies users, as they no longer have to use std::unique_ptr::get(). Change-Id: I8ce8658589460b98888283b306b315a5b8f73976
2022-06-17Eliminate the two-level data structures behind location_specsPedro Alves1-28/+16
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-170/+178
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-25Show enabled locations with disabled breakpoint parent as "y-"Pedro Alves1-6/+31
Currently, breakpoint locations that are enabled while their parent breakpoint is disabled are displayed with "y" in the Enb colum of "info breakpoints": (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep n <MULTIPLE> 1.1 y 0x00000000000011b6 in ... 1.2 y 0x00000000000011c2 in ... 1.3 n 0x00000000000011ce in ... Such locations won't trigger a break, so to avoid confusion, show "y-" instead. For example: (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep n <MULTIPLE> 1.1 y- 0x00000000000011b6 in ... 1.2 y- 0x00000000000011c2 in ... 1.3 n 0x00000000000011ce in ... The "-" sign is inspired on how the TUI represents breakpoints on the left side of the source window, with "b-" for a disabled breakpoint. Change-Id: I9952313743c51bf21b4b380c72360ef7d4396a09
2022-05-20Rename base_breakpoint -> code_breakpointPedro Alves1-31/+31
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-20Make sure momentary breakpoints are always thread-specificPedro Alves1-37/+46
This adds a new ctor to momentary_breakpoints with a few parameters that are always necessary for momentary breakpoints. In particular, I noticed that set_std_terminate_breakpoint doesn't make the breakpoint be thread specific, which looks like a bug to me. The point of that breakpoint is to intercept std::terminate calls that happen as result of the called thread throwing an exception that won't be caught by the dummy frame. If some other thread calls std::terminate, IMO, it's no different from some other thread calling exit/_exit, for example. Change-Id: Ifc5ff4a6d6e58b8c4854d00b86725382d38a1a02
2022-05-20Momentary breakpoints should have no breakpoint numberPedro Alves1-1/+0
Momentary breakpoints have no breakpoint number, their breakpoint number should be always 0, to avoid constantly incrementing (or decrementing) the internal breakpoint count. Indeed, set_momentary_breakpoint installs the created breakpoint without a number. However, momentary_breakpoint_from_master incorrectly gives an internal breakpoint number to the new breakpoint. This commit fixes that. Change-Id: Iedcae5432cdf232db9e9a6e1a646d358abd34f95
2022-05-20Add/tweak intro comments of struct breakpoint and several subclassesPedro Alves1-2/+10
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-26/+19
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-6/+18
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-28/+3
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-37/+22
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-20Refactor momentary breakpoints, eliminate set_raw_breakpoint{,_without_location}Pedro Alves1-73/+24
This commit makes set_momentary_breakpoint allocate the breakpoint type without relying on set_raw_breakpoint, and similarly, momentary_breakpoint_from_master not rely on set_raw_breakpoint_without_location. This will let us convert init_raw_breakpoint to a ctor in a following patch. The comment about set_raw_breakpoint being used in gdbtk sources is stale. gdbtk no longer uses it. Change-Id: Ibbf77731e4b22e18ccebc1b5799bbec0aff28c8a
2022-05-20Refactor set_internal_breakpoint / internal_breakpoint ctorPedro Alves1-19/+18
This moves initialization of internal_breakpoint's breakpoint fields to internal_breakpoint's ctor, and stops using new_breakpoint_from_type for internal_breakpoint breakpoints. Change-Id: I898ed0565f47cb00e4429f1c6446e6f9a385a78d
2022-05-20Convert init_ada_exception_catchpoint to a ctorPedro Alves1-44/+2
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-122/+113
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-20Remove "internal" parameter from a couple functionsPedro Alves1-3/+3
None of init_breakpoint_sal, create_breakpoint_sal, and strace_marker_create_breakpoints_sal make use of their "internal" parameter, so remove it. Change-Id: I943f3bb44717ade7a7b7547edf8f3ff3c37da435
2022-05-20More breakpoint_ops parameter eliminationPedro Alves1-9/+7
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-24/+6
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-20ranged_breakpoint: move initialization to ctorPedro Alves1-8/+19
Move initialization of ranged_breakpoint's fields to its ctor. Change-Id: If7b842861f3cc6a429ea329d45598b5852283ba3