diff options
author | Pedro Alves <pedro@palves.net> | 2022-05-23 20:15:18 +0100 |
---|---|---|
committer | Pedro Alves <pedro@palves.net> | 2022-06-17 09:41:24 +0100 |
commit | 264f98902f27497f7494933628b0f5c4e117fe59 (patch) | |
tree | 7a56e489f4441c3132a4d2b0b636a64ace58cd7c /gdb/mi | |
parent | 14e283ff4e0656327179a5b69954796af3807b66 (diff) | |
download | gdb-264f98902f27497f7494933628b0f5c4e117fe59.zip gdb-264f98902f27497f7494933628b0f5c4e117fe59.tar.gz gdb-264f98902f27497f7494933628b0f5c4e117fe59.tar.bz2 |
event_location -> location_spec
Currently, GDB internally uses the term "location" for both the
location specification the user input (linespec, explicit location, or
an address location), and for actual resolved locations, like the
breakpoint locations, or the result of decoding a location spec to
SaLs. This is expecially confusing in the breakpoints module, as
struct breakpoint has these two fields:
breakpoint::location;
breakpoint::loc;
"location" is the location spec, and "loc" is the resolved locations.
And then, we have a method called "locations()", which returns the
resolved locations as range...
The location spec type is presently called event_location:
/* Location we used to set the breakpoint. */
event_location_up location;
and it is described like this:
/* The base class for all an event locations used to set a stop event
in the inferior. */
struct event_location
{
and even that is incorrect... Location specs are used for finding
actual locations in the program in scenarios that have nothing to do
with stop events. E.g., "list" works with location specs.
To clean all this confusion up, this patch renames "event_location" to
"location_spec" throughout, and then all the variables that hold a
location spec, they are renamed to include "spec" in their name, like
e.g., "location" -> "locspec". Similarly, functions that work with
location specs, and currently have just "location" in their name are
renamed to include "spec" in their name too.
Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca
Diffstat (limited to 'gdb/mi')
-rw-r--r-- | gdb/mi/mi-cmd-break.c | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/gdb/mi/mi-cmd-break.c b/gdb/mi/mi-cmd-break.c index d4a7562..dab0a47 100644 --- a/gdb/mi/mi-cmd-break.c +++ b/gdb/mi/mi-cmd-break.c @@ -179,7 +179,7 @@ mi_cmd_break_insert_1 (int dprintf, const char *command, char **argv, int argc) int tracepoint = 0; symbol_name_match_type match_type = symbol_name_match_type::WILD; enum bptype type_wanted; - event_location_up location; + location_spec_up locspec; const struct breakpoint_ops *ops; int is_explicit = 0; struct explicit_location explicit_loc; @@ -322,7 +322,7 @@ mi_cmd_break_insert_1 (int dprintf, const char *command, char **argv, int argc) A simulator or an emulator could conceivably implement fast regular non-jump based tracepoints. */ type_wanted = hardware ? bp_fast_tracepoint : bp_tracepoint; - ops = breakpoint_ops_for_event_location (nullptr, true); + ops = breakpoint_ops_for_location_spec (nullptr, true); } else if (dprintf) { @@ -348,17 +348,17 @@ mi_cmd_break_insert_1 (int dprintf, const char *command, char **argv, int argc) explicit_loc.func_name_match_type = match_type; - location = new_explicit_location (&explicit_loc); + locspec = new_explicit_location_spec (&explicit_loc); } else { - location = string_to_event_location_basic (&address, current_language, - match_type); + locspec = string_to_location_spec_basic (&address, current_language, + match_type); if (*address) error (_("Garbage '%s' at end of location"), address); } - create_breakpoint (get_current_arch (), location.get (), condition, thread, + create_breakpoint (get_current_arch (), locspec.get (), condition, thread, extra_string.c_str (), force_condition, 0 /* condition and thread are valid. */, |