aboutsummaryrefslogtreecommitdiff
path: root/gdb/mi
AgeCommit message (Collapse)AuthorFilesLines
2023-07-07Remove unchecked casts to mi_interpTom Tromey3-27/+39
Simon noticed a crash that could be caused via new Python gdb.execute_mi function. Looking into this, I found a few unchecked casts to mi_interp, like: - struct mi_interp *mi = (struct mi_interp *) command_interp (); This patch replaces all such casts with safer variants. For -gdb-exit and mi_load_progress, I chose to have the functions simply not generate any output. It didn't seem useful to do so. Some casts I eliminated by adding a parameter to a function. Then, in mi_execute_command, I changed the code to use gdb::checked_static_cast. This is appropriate because this particular overload can only be called by the MI interpreter. There does not seem to be a very good way to test -gdb-exit. Regression tested on x86-64 Fedora 36.
2023-06-20Use unique_xmalloc_ptr for mi_parse::commandTom Tromey4-19/+19
This changes mi_parse::command to be a unique_xmalloc_ptr and fixes up all the uses. This avoids some manual memory management. std::string is not used here due to how the Python API works -- this approach avoids an extra copy there. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-06-20Use std::string for MI tokenTom Tromey4-24/+19
This changes the MI "token" to be a std::string, removing some manual memory management. It also makes current_token 'const' in order to support this change. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-06-12Transfer ownership of exception string to ada_catchpointTom Tromey1-2/+2
This changes the ada_catchpoint to require an rvalue ref, so that ownership of the exception string can be transferred to the catchpoint object.
2023-06-03[gdb] Fix typosTom de Vries1-1/+1
Fix a few typos: - implemention -> implementation - convertion(s) -> conversion(s) - backlashes -> backslashes - signoring -> ignoring - (un)ambigious -> (un)ambiguous - occured -> occurred - hidding -> hiding - temporarilly -> temporarily - immediatelly -> immediately - sillyness -> silliness - similiar -> similar - porkuser -> pokeuser - thats -> that - alway -> always - supercede -> supersede - accomodate -> accommodate - aquire -> acquire - priveleged -> privileged - priviliged -> privileged - priviledges -> privileges - privilige -> privilege - recieve -> receive - (p)refered -> (p)referred - succesfully -> successfully - successfuly -> successfully - responsability -> responsibility - wether -> whether - wich -> which - disasbleable -> disableable - descriminant -> discriminant - construcstor -> constructor - underlaying -> underlying - underyling -> underlying - structureal -> structural - appearences -> appearances - terciarily -> tertiarily - resgisters -> registers - reacheable -> reachable - likelyhood -> likelihood - intepreter -> interpreter - disassemly -> disassembly - covnersion -> conversion - conviently -> conveniently - atttribute -> attribute - struction -> struct - resonable -> reasonable - popupated -> populated - namespaxe -> namespace - intialize -> initialize - identifer(s) -> identifier(s) - expection -> exception - exectuted -> executed - dungerous -> dangerous - dissapear -> disappear - completly -> completely - (inter)changable -> (inter)changeable - beakpoint -> breakpoint - automativ -> automatic - alocating -> allocating - agressive -> aggressive - writting -> writing - reguires -> requires - registed -> registered - recuding -> reducing - opeartor -> operator - ommitted -> omitted - modifing -> modifying - intances -> instances - imbedded -> embedded - gdbaarch -> gdbarch - exection -> execution - direcive -> directive - demanged -> demangled - decidely -> decidedly - argments -> arguments - agrument -> argument - amespace -> namespace - targtet -> target - supress(ed) -> suppress(ed) - startum -> stratum - squence -> sequence - prompty -> prompt - overlow -> overflow - memember -> member - languge -> language - geneate -> generate - funcion -> function - exising -> existing - dinking -> syncing - destroh -> destroy - clenaed -> cleaned - changep -> changedp (name of variable) - arround -> around - aproach -> approach - whould -> would - symobl -> symbol - recuse -> recurse - outter -> outer - freeds -> frees - contex -> context Tested on x86_64-linux. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-05-31Improve MI -dprintf-insert documentationTom Tromey1-5/+5
I found the documentation for -dprintf-insert a bit unclear. It didn't mention the possibility of multiple arguments, and I also noticed that it implied that the format parameter is optional, which it is not. While looking into this I also noticed a few comments in the implementation that could also be improved. Then, I noticed a repeated call to strlen in a loop condition, so I fixed this up as well. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-05-30gdb: add interp::on_memory_changed methodSimon Marchi2-37/+23
Same idea as previous patches, but for memory_changed. Change-Id: Ic19f20c24d8a6431d4a89c5625e8ef4898f76e82
2023-05-30gdb: add interp::on_param_changed methodSimon Marchi2-24/+11
Same idea as previous patches, but for command_param_changed. Change-Id: I7c2196343423360da05f016f8ffa871c064092bb
2023-05-30gdb: add interp::on_breakpoint_modified methodSimon Marchi3-22/+9
Same idea as previous patches, but for breakpoint_modified. Change-Id: I4f0a9edea912de431e32451d74224b2022a7c328
2023-05-30gdb: add interp::on_breakpoint_deleted methodSimon Marchi2-21/+7
Same idea as previous patches, but for breakpoint_deleted. Change-Id: I59c231ce963491bb1eee1432ee1090138f09e19c
2023-05-30gdb: add interp::on_breakpoint_created methodSimon Marchi2-21/+8
Same idea as previous patches, but for breakpoint_created. Change-Id: I614113c924edc243590018b8fb3bf69cb62215ef
2023-05-30gdb: add interp::on_tsv_modified methodSimon Marchi2-27/+15
Same idea as previous patches, but for tsv_modified. Change-Id: I55454a2386d5450040b3a353909b26f389a43682
2023-05-30gdb: add interp::on_tsv_deleted methodSimon Marchi2-22/+11
Same idea as previous patches, but for tsv_deleted. Change-Id: I71b0502b493da7b6e293bee02aeca98de83d4b75
2023-05-30gdb: add interp::on_tsv_created methodSimon Marchi2-20/+9
Same idea as previous patches, but for tsv_created. Change-Id: I9c30ecfdbd78ca015d613f43a0c0aef6c7eb32b5
2023-05-30gdb: add interp::on_traceframe_changed methodSimon Marchi2-24/+12
Same idea as previous patches, but for traceframe_changed. Change-Id: Ia473f07d70d57b30aca0094d0e0585d7e0d95637
2023-05-30gdb: add interp::on_about_to_proceed methodSimon Marchi2-10/+4
Same idea as previous patches, but for about_to_proceed. We only need (and want, as far as the mi_interp implementation is concerned) to notify the interpreter that caused the proceed. Change-Id: Id259bca10dbc3d43d46607ff7b95243a9cbe2f89
2023-05-30gdb: add interp::on_solib_unloaded methodSimon Marchi2-26/+14
Same idea as previous patches, but for solib_unloaded. Change-Id: Iad847de93f0b38b5c90679a173d3beeaed7af6c5
2023-05-30gdb: add interp::on_solib_loaded methodSimon Marchi2-20/+10
Same idea as previous patches, but for solib_loaded Change-Id: I85edb0a4b377f4b2c39ffccf31cb75f38bae0f55
2023-05-30gdb: add interp::on_target_resumed methodSimon Marchi2-15/+6
Same idea as previous patches, but for target_resumed. Change-Id: I66fa28d1d41a1f3c4fb0d6a470137d493eac3c8c
2023-05-30gdb: add interp::on_record_changed methodSimon Marchi2-41/+24
Same idea as previous patches, but for record_changed Change-Id: I5eeeacd703af8401c315060514c94e8e6439cc40
2023-05-30gdb: add interp::on_inferior_removed methodSimon Marchi2-18/+7
Same idea as previous patches, but for inferior_removed. Change-Id: I7971840bbbdcfabf77e2ded7584830c9dfdd10d0
2023-05-30gdb: add interp::on_inferior_disappeared methodSimon Marchi2-22/+13
Same idea as previous patches, but for inferior_disappeared. For symmetry with on_inferior_appeared, I named this one on_inferior_disappeared, despite the observer being called inferior_exit. This is called when detaching an inferior, so I think that calling it "disappeared" is a bit less misleading (the observer should probably be renamed later). Change-Id: I372101586bc9454997953c1e540a2a6685f53ef6
2023-05-30gdb: add interp::on_inferior_appeared methodSimon Marchi2-18/+8
Same idea as previous patches, but for inferior_appeared. Change-Id: Ibe4feba34274549a886b1dfb5b3f8d59ae79e1b5
2023-05-30gdb: add interp::on_inferior_added methodSimon Marchi2-38/+9
Same idea as previous patches, but for inferior_added. mi_interp::init avoided using mi_inferior_added, since, as the comment used to say, it would notify all MI interpreters. Now, it's easy to only notify the new interpreter, so it's possible to just call the on_inferior_added method in mi_interp::init. Change-Id: I0eddbd5367217d1c982516982089913019ef309f
2023-05-30gdb: add interp::on_thread_exited methodSimon Marchi2-18/+8
Same idea as previous patches, but for thread_exited. Change-Id: I4be974cbe58cf635453fef503c2d77c82522cbd9
2023-05-30gdb: add interp::on_new_thread methodSimon Marchi2-18/+8
Same idea as previous patches, but for new_thread. Change-Id: Ib70ae3421b736fd69d86c4e7c708bec349aa256c
2023-05-30gdb: add interp::on_user_selected_context_changed methodSimon Marchi3-44/+23
Same as previous patches, but for user_selected_context_changed. Change-Id: I40de15be897671227d4bcf3e747f0fd595f0d5be
2023-05-30gdb: add interp::on_command_error methodSimon Marchi2-8/+4
Same idea as the previous patches, but for command_error. Change-Id: If6098225dd72fad8be13b3023b35bc8bc48efb9d
2023-05-30gdb: add interp::on_sync_execution_done methodSimon Marchi2-13/+4
Same as previous patches, but for sync_execution_done. Except that here, we only want to notify the interpreter that is executing the command, not all interpreters. Change-Id: I729c719447b5c5f29af65dbf6fed9132e2cd308b
2023-05-30gdb: add interp::on_no_history methodSimon Marchi2-37/+5
Same as previous patches, but for no_history. Change-Id: I06930fe7cb4082138c6c5496c5118fe4951c10da
2023-05-30gdb: add interp::on_exited methodSimon Marchi2-16/+5
Same as previous patch, but for exited. Remove the exited observable, since nothing uses it anymore, and we don't have anything coming that will use it. Change-Id: I358cbea0159af56752dfee7510d6a86191e722bb
2023-05-30gdb: add interp::on_signal_exited methodSimon Marchi2-16/+5
Same as previous patch, but for signal_exited. Remove the signal_exited observable, since nothing uses it anymore, and we don't have anything coming that will use it. Change-Id: I0dca1eab76338bf27be755786e3dad3241698b10
2023-05-30gdb: add interp::on_normal_stop methodSimon Marchi2-35/+17
Same idea as the previous patch, but for the normal_stop event. Change-Id: I4fc8ca8a51c63829dea390a2b6ce30b77f9fb863
2023-05-30gdb: add interp::on_signal_received methodSimon Marchi2-16/+6
Instead of having the interpreter code registering observers for the signal_received observable, add a "signal_received" virtual method to struct interp. Add a interps_notify_signal_received function that loops over all UIs and calls the signal_received method on the interpreter. Finally, add a notify_signal_received function that calls interps_notify_signal_received and then notifies the observers. Replace all existing notifications to the signal_received observers with calls to notify_signal_received. Before this patch, the CLI and MI code both register a signal_received observer. These observer go over all UIs, and, for those that have a interpreter of the right kind, print the stop notifiation. After this patch, we have just one "loop over all UIs", inside interps_notify_signal_received. Since the interp::on_signal_received method gets called once for each interpreter, the implementations only need to deal with the current interpreter (the "this" pointer). The motivation for this patch comes from a future patch, that makes the amdgpu code register an observer to print a warning after the CLI's signal stop message. Since the amdgpu and the CLI code both use observers, the order of the two messages is not stable, unless we define the priority using the observer dependency system. However, the approach of using virtual methods on the interpreters seems like a good change anyway, I think it's more straightforward and simple to understand than the current solution that uses observers. We are sure that the amdgpu message gets printed after the CLI message, since observers are notified after interpreters. Keep the signal_received, even if nothing uses if, because we will be using it in the upcoming amdgpu patch implementing the warning described above. Change-Id: I4d8614bb8f6e0717f4bfc2a59abded3702f23ac4
2023-05-29gdb/mi: fix ^running record with multiple MI interpretersSimon Marchi4-17/+19
I stumbled on the mi_proceeded and running_result_record_printed globals, which are shared by all MI interpreter instances (it's unlikely that people use multiple MI interpreter instances, but it's possible). After poking at it, I found this bug: 1. Start GDB in MI mode 2. Add a second MI interpreter with the new-ui command 3. Use -exec-run on the second interpreter This is the output I get on the first interpreter: =thread-group-added,id="i1" ~"Reading symbols from a.out...\n" ~"New UI allocated\n" (gdb) =thread-group-started,id="i1",pid="94718" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" And this is the output I get on the second intepreter: =thread-group-added,id="i1" (gdb) -exec-run =thread-group-started,id="i1",pid="94718" =thread-created,id="1",group-id="i1" *running,thread-id="all" The problem here is that the `^running` reply to the -exec-run command is printed on the wrong UI. It is printed on the first one, it should be printed on the second (the one on which we sent the -exec-run). What happens under the hood is that captured_mi_execute_command, while executing a command for the second intepreter, clears the running_result_record_printed and mi_proceeded globals. mi_about_to_proceed then sets mi_proceeded. Then, mi_on_resume_1 gets called for the first intepreter first. Since the !running_result_record_printed && mi_proceeded condition is true, it prints a ^running, and sets running_result_record_printed. When mi_on_resume_1 gets called for the second interpreter, running_result_record_printed is already set, so ^running is not printed there. It took me a while to understand the relationship between these two variables. I think that in the end, this is what we want to track: 1. When executing an MI command, take note if that command causes a "proceed". This is done in mi_about_to_proceed. 2. In mi_on_resume_1, if the command indeed caused a "proceed", we want to output a ^running record. And we want to remember that we did, because... 3. Back in captured_mi_execute_command, if we did not output a ^running, we want to output a ^done. Moving those two variables to the mi_interp struture appears to fix it. Only for the interpreter doing the -exec-run command does the running_result_record_printed flag get cleared, and therefore only or that one does the ^running record get printed. Add a new test for this, that does pretty much what the reproducer above shows. Without the fix, the test fails because mi_send_resuming_command_raw never sees the ^running record. Change-Id: I63ea30e6cb61a8e1dd5ef03377e6003381a9209b Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
2023-05-25Make MI commands const-correctTom Tromey16-187/+250
I've had this patch for a while now and figured I'd update it and send it. It changes MI commands to use a "const char * const" for their argv parameter. Regression tested on x86-64 Fedora 36. Acked-By: Simon Marchi <simon.marchi@efficios.com>
2023-05-23Implement gdb.execute_miTom Tromey2-0/+20
This adds a new Python function, gdb.execute_mi, that can be used to invoke an MI command but get the output as a Python object, rather than a string. This is done by implementing a new ui_out subclass that builds a Python object. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11688 Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-05-23Add second mi_parse constructorTom Tromey2-2/+107
This adds a second mi_parse constructor. This constructor takes a command name and vector of arguments, and does not do any escape processing. This also changes mi_parse::args to handle parse objects created this new way.
2023-05-23Introduce mi_parse helper methodsTom Tromey2-17/+61
This introduces some helper methods for mi_parse that handle some of the details of parsing. This approach lets us reuse them later.
2023-05-23Introduce "static constructor" for mi_parseTom Tromey3-19/+17
Change the mi_parse function to be a static method of mi_parse. This lets us remove the 'set_args' setter function.
2023-05-23Change mi_parse_argv to a methodTom Tromey3-9/+8
This changes mi_parse_argv to be a method of mi_parse. This is just a minor cleanup.
2023-05-23Use accessor for mi_parse::argsTom Tromey4-7/+17
This changes mi_parse::args to be a private member, retrieved via accessor. It also changes this member to be a std::string. This makes it simpler for a subsequent patch to implement different behavior for argument parsing.
2023-05-23Use member initializers in mi_parseTom Tromey2-31/+14
This changes mi_parse to use member initializers rather than a constructor. This is easier to follow.
2023-05-04Don't treat references to compound values as "simple".Gareth Rees4-19/+29
SUMMARY The '--simple-values' argument to '-stack-list-arguments' and similar GDB/MI commands does not take reference types into account, so that references to arbitrarily large structures are considered "simple" and printed. This means that the '--simple-values' argument cannot be used by IDEs when tracing the stack due to the time taken to print large structures passed by reference. DETAILS Various GDB/MI commands ('-stack-list-arguments', '-stack-list-locals', '-stack-list-variables' and so on) take a PRINT-VALUES argument which may be '--no-values' (0), '--all-values' (1) or '--simple-values' (2). In the '--simple-values' case, the command is supposed to print the name, type, and value of variables with simple types, and print only the name and type of variables with compound types. The '--simple-values' argument ought to be suitable for IDEs that need to update their user interface with the program's call stack every time the program stops. However, it does not take C++ reference types into account, and this makes the argument unsuitable for this purpose. For example, consider the following C++ program: struct s { int v[10]; }; int sum(const struct s &s) { int total = 0; for (int i = 0; i < 10; ++i) total += s.v[i]; return total; } int main(void) { struct s s = { { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } }; return sum(s); } If we start GDB in MI mode and continue to 'sum', the behaviour of '-stack-list-arguments' is as follows: (gdb) -stack-list-arguments --simple-values ^done,stack-args=[frame={level="0",args=[{name="s",type="const s &",value="@0x7fffffffe310: {v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}}"}]},frame={level="1",args=[]}] Note that the value of the argument 's' was printed, even though 's' is a reference to a structure, which is not a simple value. See https://github.com/microsoft/MIEngine/pull/673 for a case where this behaviour caused Microsoft to avoid the use of '--simple-values' in their MIEngine debug adapter, because it caused Visual Studio Code to take too long to refresh the call stack in the user interface. SOLUTIONS There are two ways we could fix this problem, depending on whether we consider the current behaviour to be a bug. 1. If the current behaviour is a bug, then we can update the behaviour of '--simple-values' so that it takes reference types into account: that is, a value is simple if it is neither an array, struct, or union, nor a reference to an array, struct or union. In this case we must add a feature to the '-list-features' command so that IDEs can detect that it is safe to use the '--simple-values' argument when refreshing the call stack. 2. If the current behaviour is not a bug, then we can add a new option for the PRINT-VALUES argument, for example, '--scalar-values' (3), that would be suitable for use by IDEs. In this case we must add a feature to the '-list-features' command so that IDEs can detect that the '--scalar-values' argument is available for use when refreshing the call stack. PATCH This patch implements solution (1) as I think the current behaviour of not printing structures, but printing references to structures, is contrary to reasonable expectation. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29554
2023-05-01gdb: move struct ui and related things to ui.{c,h}Simon Marchi2-1/+2
I'd like to move some things so they become methods on struct ui. But first, I think that struct ui and the related things are big enough to deserve their own file, instead of being scattered through top.{c,h} and event-top.c. Change-Id: I15594269ace61fd76ef80a7b58f51ff3ab6979bc
2023-05-01Remove evaluate_typeTom Tromey1-1/+1
Like evaluate_expression, evaluate_type is also just a simple wrapper. Removing it makes the code a little nicer.
2023-05-01Remove evaluate_expressionTom Tromey1-2/+2
evaluate_expression is just a little wrapper for a method on expression. Removing it also removes a lot of ugly (IMO) calls to get().
2023-04-29gdb: Fix building with latest libc++Manoj Gupta1-1/+1
Latest libc++[1] causes transitive include to <locale> when <mutex> or <thread> header is included. This causes gdb to not build[2] since <locale> defines isupper/islower etc. functions that are explicitly macroed-out in safe-ctype.h to prevent their use. Use the suggestion from libc++ to include <locale> internally when building in C++ mode to avoid build errors. Use safe-gdb-ctype.h as the include instead of "safe-ctype.h" to keep this isolated to gdb since rest of binutils does not seem to use much C++. [1]: https://reviews.llvm.org/D144331 [2]: https://issuetracker.google.com/issues/277967395
2023-04-29gdb/mi: check thread exists when creating thread-specific b/pAndrew Burgess1-0/+2
I noticed the following behaviour: $ gdb -q -i=mi /tmp/hello.x =thread-group-added,id="i1" =cmd-param-changed,param="print pretty",value="on" ~"Reading symbols from /tmp/hello.x...\n" (gdb) -break-insert -p 99 main ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000401198",func="main",file="/tmp/hello.c",fullname="/tmp/hello.c",line="18",thread-groups=["i1"],thread="99",times="0",original-location="main"} (gdb) info breakpoints &"info breakpoints\n" ~"Num Type Disp Enb Address What\n" ~"1 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18\n" &"../../src/gdb/thread.c:1434: internal-error: print_thread_id: Assertion `thr != nullptr' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable." &"\n" &"----- Backtrace -----\n" &"Backtrace unavailable\n" &"---------------------\n" &"\nThis is a bug, please report it." &" For instructions, see:\n" &"<https://www.gnu.org/software/gdb/bugs/>.\n\n" Aborted (core dumped) What we see here is that when using the MI a user can create thread-specific breakpoints for non-existent threads. Then if we try to use the CLI 'info breakpoints' command GDB throws an assertion. The assert is a result of the print_thread_id call when trying to build the 'stop only in thread xx.yy' line; print_thread_id requires a valid thread_info pointer, which we can't have for a non-existent thread. In contrast, when using the CLI we see this behaviour: $ gdb -q /tmp/hello.x Reading symbols from /tmp/hello.x... (gdb) break main thread 99 Unknown thread 99. (gdb) The CLI doesn't allow a breakpoint to be created for a non-existent thread. So the 'info breakpoints' command is always fine. Interestingly, the MI -break-info command doesn't crash, this is because the MI uses global thread-ids, and so never calls print_thread_id. However, GDB does support using CLI and MI in parallel, so we need to solve this problem. One option would be to change the CLI behaviour to allow printing breakpoints for non-existent threads. This would preserve the current MI behaviour. The other option is to pull the MI into line with the CLI and prevent breakpoints being created for non-existent threads. This is good for consistency, but is a breaking change for the MI. In the end I figured that it was probably better to retain the consistent CLI behaviour, and just made the MI reject requests to place a breakpoint on a non-existent thread. The only test we had that depended on the old behaviour was gdb.mi/mi-thread-specific-bp.exp, which was added by me in commit: commit 2fd9a436c8d24eb0af85ccb3a2fbdf9a9c679a6c Date: Fri Feb 17 10:48:06 2023 +0000 gdb: don't duplicate 'thread' field in MI breakpoint output I certainly didn't intend for this test to rely on this feature of the MI, so I propose to update this test to only create breakpoints for threads that exist. Actually, I've added a new test that checks the MI rejects creating a breakpoint for a non-existent thread, and I've also extended the test to run with the separate MI/CLI UIs, and then tested 'info breakpoints' to ensure this command doesn't crash. I've extended the documentation of the `-p` flag to explain the constraints better. I have also added a NEWS entry just in case someone runs into this issue, at least then they'll know this change in behaviour was intentional. One thing that I did wonder about while writing this patch, is whether we should treat requests like this, on both the MI and CLI, as another form of pending breakpoint, something like: (gdb) break foo thread 9 Thread 9 does not exist. Make breakpoint pending on future thread creation? (y or [n]) y Breakpoint 1 (foo thread 9) pending. (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y <PENDING> foo thread 9 Don't know if folk think that would be a useful idea or not? Either way, I think that would be a separate patch from this one. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-04-24gdb: remove end_stepping_range observableSimon Marchi1-20/+0
I noticed that this observable was never notified, which means we can probably safely remove it. The notification was removed in: commit 243a925328f8e3184b2356bee497181049c0174f Author: Pedro Alves <palves@redhat.com> Date: Wed Sep 9 18:23:24 2015 +0100 Replace "struct continuation" mechanism by something more extensible print_end_stepping_range_reason in turn becomes unused, so remote it as well. Change-Id: If5da5149276c282d2540097c8c4327ce0f70431a
generated by cgit v1.1 at 2024-11-17 09:10:11 +0000