aboutsummaryrefslogtreecommitdiff
path: root/gdb/interps.c
AgeCommit message (Collapse)AuthorFilesLines
2024-05-17Remove gdb_stdtargerrTom Tromey1-1/+0
This patch removes gdb_stdtargerr. There doesn't seem to be a need for this -- it is always the same as stdtarg, and (I believe) has been for many years. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-17Don't allow new-ui to start the TUITom Tromey1-1/+4
The TUI can't really work properly with new-ui, at least not as currently written. This patch changes new-ui to reject an attempt. Attempting to make a DAP ui this way is also now rejected. Regression tested on x86-64 Fedora 38. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29273 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-04-25gdb: remove gdbcmd.hSimon Marchi1-1/+1
Most files including gdbcmd.h currently rely on it to access things actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make things easy, replace all includes of gdbcmd.h with includes of cli/cli-cmds.h. This might lead to some unused includes of cli/cli-cmds.h, but it's harmless, and much faster than going through the 170 or so files by hand. Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f Approved-By: Tom Tromey <tom@tromey.com>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-02-05gdb: rename struct shobj -> struct solibSimon Marchi1-2/+2
`struct so_list` was recently renamed to `struct shobj` (in 3fe0dfd1604f ("gdb: rename struct so_list to shobj")). In hindsight, `solib` would have been a better name. We have solib.c, the implementations in solib-*.c, many functions with solib in their name, the solib_loaded / solib_unloaded observables, etc. Rename shobj to solib. Change-Id: I0af1c7a9b29bdda027e9af633f6d37e1cfcacd5d Approved-By: Tom Tromey <tom@tromey.com>
2024-01-31Fix AIX build break.Aditya Vidyadhar Kamath1-1/+0
A recent commit broke AIX build. The thread_local type defined functions were being considered a weak symbol and hence while creating the binary these symbols were not visible. This patch is a fix for the same.
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-11-21gdb: Replace gdb::optional with std::optionalLancelot Six1-1/+1
Since GDB now requires C++17, we don't need the internally maintained gdb::optional implementation. This patch does the following replacing: - gdb::optional -> std::optional - gdb::in_place -> std::in_place - #include "gdbsupport/gdb_optional.h" -> #include <optional> This change has mostly been done automatically. One exception is gdbsupport/thread-pool.* which did not use the gdb:: prefix as it already lives in the gdb namespace. Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-10-19gdb: rename struct so_list to shobjSimon Marchi1-2/+2
Now that so_list lists are implemented using intrusive_list, it doesn't really make sense for the element type to be named "_list". Rename to just `struct shobj` (`struct so` was deemed to be not greppable enough). Change-Id: I1063061901298bb40fee73bf0cce44cd12154c0e Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: replace some so_list parameters to use referencesSimon Marchi1-2/+2
A subsequent patch changes so_list to be linked using intrusive_list. Iterating an intrusive_list yields some references to the list elements. Convert some functions accepting so_list objects to take references, to make things easier and more natural. Add const where possible and convenient. Change-Id: Id5ab5339c3eb6432e809ad14782952d6a45806f3 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: make interps_notify work with referencesSimon Marchi1-3/+3
A subsequent patch changes the interp::on_solib_loaded and interp::on_solib_unloaded methods to take references. This highlighted that interps_notify did not work with reference parameters. Fix that by changing interps_notify's `args` arg to be a universal reference (&&). Change the type of the method to be auto-deduced as an additional template parameter, otherwise the signature of the callback function would never match: CXX interps.o /home/simark/src/binutils-gdb/gdb/interps.c: In function ‘void interps_notify_signal_received(gdb_signal)’: /home/simark/src/binutils-gdb/gdb/interps.c:378:18: error: no matching function for call to ‘interps_notify(void (interp::*)(gdb_signal), gdb_signal&)’ 378 | interps_notify (&interp::on_signal_received, sig); | ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/simark/src/binutils-gdb/gdb/interps.c:363:1: note: candidate: ‘template<class ... Args> void interps_notify(void (interp::*)(Args ...), Args&& ...)’ 363 | interps_notify (void (interp::*method) (Args...), Args&&... args) | ^~~~~~~~~~~~~~ /home/simark/src/binutils-gdb/gdb/interps.c:363:1: note: template argument deduction/substitution failed: /home/simark/src/binutils-gdb/gdb/interps.c:378:18: note: inconsistent parameter pack deduction with ‘gdb_signal’ and ‘gdb_signal&’ 378 | interps_notify (&interp::on_signal_received, sig); | ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change-Id: I0cd9378e24ef039f30f8e14f054f8d7fb539c838 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-09-12gdb/mi: remove warning about mi1Simon Marchi1-10/+0
Remove a warning about mi1. mi1 was removed in 975249ff4e26 ("Remove MI version 1"). It is no longer possible to reach this warning, since trying to use interpreter mi1 bails out before: $ ./gdb -nx -q --data-directory=data-directory -i mi1 Interpreter `mi1' unrecognized Change-Id: Ie43b21e01bca1407995150c729531a70ee662003 Approved-By: Tom Tromey <tom@tromey.com>
2023-09-07gdb: remove interp_supports_command_editingSimon Marchi1-8/+0
It is a trivial wrapper around the supports_command_editing method, remove it. Change-Id: I0fe3d7dc69601b3b89f82e055f7fe3d4af1becf7 Approved-By: Tom Tromey <tom@tromey.com>
2023-09-07gdb: remove interp_pre_command_loopSimon Marchi1-10/+0
It is a trivial wrapper around the pre_command_loop method, remove it. Change-Id: Idb2c61f9b68988528006a9a9b2b528f43781eef4 Approved-By: Tom Tromey <tom@tromey.com>
2023-08-23gdb: centralize "[Thread ...exited]" notificationsPedro Alves1-2/+4
Currently, each target backend is responsible for printing "[Thread ...exited]" before deleting a thread. This leads to unnecessary differences between targets, like e.g. with the remote target, we never print such messages, even though we do print "[New Thread ...]". E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we currently see: (gdb) c Continuing. ^C[New Thread 3850398.3887449] [New Thread 3850398.3887500] [New Thread 3850398.3887551] [New Thread 3850398.3887602] [New Thread 3850398.3887653] ... Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c (gdb) Above, we only see "New Thread" notifications, even though threads were deleted. After this patch, we'll see: (gdb) c Continuing. ^C[Thread 3558643.3577053 exited] [Thread 3558643.3577104 exited] [Thread 3558643.3577155 exited] [Thread 3558643.3579603 exited] ... [New Thread 3558643.3597415] [New Thread 3558643.3600015] [New Thread 3558643.3599965] ... Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c (gdb) q This commit fixes this by moving the thread exit printing to common code instead, triggered from within delete_thread (or rather, set_thread_exited). There's one wrinkle, though. While most targest want to print: [Thread ... exited] the Windows target wants to print: [Thread ... exited with code <exit_code>] ... and sometimes wants to suppress the notification for the main thread. To address that, this commits adds a delete_thread_with_code function, only used by that target (so far). This fix was originally posted as part of a larger series: https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/ But didn't really need to be part of that series. In order to get this fix merged sooner, I (Andrew Burgess) have rebased this commit outside of the original series. Any bugs introduced while splitting this patch out and rebasing, are entirely my own. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30129 Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
2023-05-30gdb: add interp::on_memory_changed methodSimon Marchi1-0/+9
Same idea as previous patches, but for memory_changed. Change-Id: Ic19f20c24d8a6431d4a89c5625e8ef4898f76e82
2023-05-30gdb: add interp::on_param_changed methodSimon Marchi1-0/+8
Same idea as previous patches, but for command_param_changed. Change-Id: I7c2196343423360da05f016f8ffa871c064092bb
2023-05-30gdb: add interp::on_breakpoint_modified methodSimon Marchi1-0/+8
Same idea as previous patches, but for breakpoint_modified. Change-Id: I4f0a9edea912de431e32451d74224b2022a7c328
2023-05-30gdb: add interp::on_breakpoint_deleted methodSimon Marchi1-0/+8
Same idea as previous patches, but for breakpoint_deleted. Change-Id: I59c231ce963491bb1eee1432ee1090138f09e19c
2023-05-30gdb: add interp::on_breakpoint_created methodSimon Marchi1-0/+8
Same idea as previous patches, but for breakpoint_created. Change-Id: I614113c924edc243590018b8fb3bf69cb62215ef
2023-05-30gdb: add interp::on_tsv_modified methodSimon Marchi1-0/+8
Same idea as previous patches, but for tsv_modified. Change-Id: I55454a2386d5450040b3a353909b26f389a43682
2023-05-30gdb: add interp::on_tsv_deleted methodSimon Marchi1-0/+8
Same idea as previous patches, but for tsv_deleted. Change-Id: I71b0502b493da7b6e293bee02aeca98de83d4b75
2023-05-30gdb: add interp::on_tsv_created methodSimon Marchi1-0/+8
Same idea as previous patches, but for tsv_created. Change-Id: I9c30ecfdbd78ca015d613f43a0c0aef6c7eb32b5
2023-05-30gdb: add interp::on_traceframe_changed methodSimon Marchi1-0/+8
Same idea as previous patches, but for traceframe_changed. Change-Id: Ia473f07d70d57b30aca0094d0e0585d7e0d95637
2023-05-30gdb: add interp::on_solib_unloaded methodSimon Marchi1-0/+8
Same idea as previous patches, but for solib_unloaded. Change-Id: Iad847de93f0b38b5c90679a173d3beeaed7af6c5
2023-05-30gdb: add interp::on_solib_loaded methodSimon Marchi1-0/+8
Same idea as previous patches, but for solib_loaded Change-Id: I85edb0a4b377f4b2c39ffccf31cb75f38bae0f55
2023-05-30gdb: add interp::on_target_resumed methodSimon Marchi1-0/+8
Same idea as previous patches, but for target_resumed. Change-Id: I66fa28d1d41a1f3c4fb0d6a470137d493eac3c8c
2023-05-30gdb: add interp::on_record_changed methodSimon Marchi1-0/+9
Same idea as previous patches, but for record_changed Change-Id: I5eeeacd703af8401c315060514c94e8e6439cc40
2023-05-30gdb: add interp::on_inferior_removed methodSimon Marchi1-0/+8
Same idea as previous patches, but for inferior_removed. Change-Id: I7971840bbbdcfabf77e2ded7584830c9dfdd10d0
2023-05-30gdb: add interp::on_inferior_disappeared methodSimon Marchi1-0/+8
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 Marchi1-0/+8
Same idea as previous patches, but for inferior_appeared. Change-Id: Ibe4feba34274549a886b1dfb5b3f8d59ae79e1b5
2023-05-30gdb: add interp::on_inferior_added methodSimon Marchi1-0/+8
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 Marchi1-0/+8
Same idea as previous patches, but for thread_exited. Change-Id: I4be974cbe58cf635453fef503c2d77c82522cbd9
2023-05-30gdb: add interp::on_new_thread methodSimon Marchi1-0/+8
Same idea as previous patches, but for new_thread. Change-Id: Ib70ae3421b736fd69d86c4e7c708bec349aa256c
2023-05-30gdb: add interp::on_user_selected_context_changed methodSimon Marchi1-0/+8
Same as previous patches, but for user_selected_context_changed. Change-Id: I40de15be897671227d4bcf3e747f0fd595f0d5be
2023-05-30gdb: add interp::on_no_history methodSimon Marchi1-0/+8
Same as previous patches, but for no_history. Change-Id: I06930fe7cb4082138c6c5496c5118fe4951c10da
2023-05-30gdb: add interp::on_exited methodSimon Marchi1-0/+8
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 Marchi1-0/+8
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 Marchi1-0/+8
Same idea as the previous patch, but for the normal_stop event. Change-Id: I4fc8ca8a51c63829dea390a2b6ce30b77f9fb863
2023-05-30gdb: add interp::on_signal_received methodSimon Marchi1-0/+23
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-01gdb: remove ui_interp_infoSimon Marchi1-71/+20
I don't think that having struct ui_interp_info separated from struct ui is very useful. As of today, it looks like an unnecessary indirection layer. Move the contents of ui_interp_info directly into struct ui, and update all users. Change-Id: I817ba6e047dbcc4ba15b666af184b40bfed7e521
2023-05-01gdb: store interps in an intrusive_listSimon Marchi1-12/+6
Use intrusive_list, instead of hand-made linked list. Change-Id: Idc857b40dfa3e3c35671045898331cca2c928097
2023-05-01gdb: move struct ui and related things to ui.{c,h}Simon Marchi1-1/+1
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-03-07gdb: make interp::m_name an `const char *`Simon Marchi1-5/+3
I realized that the memory for interp names does not need to be allocated. The name used to register interp factory functions is always a literal string, so has static storage duration. If we change interp_lookup to pass that name instead of the string that it receives as a parameter (which does not always have static storage duration), then interps can simply store pointers to the name. So, change interp_lookup to pass `factory.name` rather than `name`. Change interp::m_name to be a `const char *` rather than an std::string. Change-Id: I0474d1f7b3512e7d172ccd73018aea927def3188 Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-07gdb: make get_interp_info return a referenceSimon Marchi1-41/+43
get_interp_info and get_current_interp_info always return non-nullptr, so they can return a reference instead of a pointer. Since we don't need to copy it, make ui_interp_info non-copyiable, to avoid a copying it in a local variable, instead of getting a reference. Change-Id: I6d8dea92dc26a58ea340d04862db6b8d9cf906a0 Reviewed-By: Tom Tromey <tom@tromey.com>
2023-02-08Simplify interp::exec / interp_exec - let exceptions propagatePedro Alves1-13/+8
This patch implements a simplication that I suggested here: https://sourceware.org/pipermail/gdb-patches/2022-March/186320.html Currently, the interp::exec virtual method interface is such that subclass implementations must catch exceptions and then return them via normal function return. However, higher up the in chain, for the CLI we get to interpreter_exec_cmd, which does: for (i = 1; i < nrules; i++) { struct gdb_exception e = interp_exec (interp_to_use, prules[i]); if (e.reason < 0) { interp_set (old_interp, 0); error (_("error in command: \"%s\"."), prules[i]); } } and for MI we get to mi_cmd_interpreter_exec, which has: void mi_cmd_interpreter_exec (const char *command, char **argv, int argc) { ... for (i = 1; i < argc; i++) { struct gdb_exception e = interp_exec (interp_to_use, argv[i]); if (e.reason < 0) error ("%s", e.what ()); } } Note that if those errors are reached, we lose the original exception's error code. I can't see why we'd want that. And, I can't see why we need to have interp_exec catch the exception and return it via the normal return path. That's normally needed when we need to handle propagating exceptions across C code, like across readline or ncurses, but that's not the case here. It seems to me that we can simplify things by removing some try/catch-ing and just letting exceptions propagate normally. Note, the "error in command" error shown above, which only exists in the CLI interpreter-exec command, is only ever printed AFAICS if you run "interpreter-exec console" when the top level interpreter is already the console/tui. Like: (gdb) interpreter-exec console "foobar" Undefined command: "foobar". Try "help". error in command: "foobar". You won't see it with MI's "-interpreter-exec console" from a top level MI interpreter: (gdb) -interpreter-exec console "foobar" &"Undefined command: \"foobar\". Try \"help\".\n" ^error,msg="Undefined command: \"foobar\". Try \"help\"." (gdb) nor with MI's "-interpreter-exec mi" from a top level MI interpreter: (gdb) -interpreter-exec mi "-foobar" ^error,msg="Undefined MI command: foobar",code="undefined-command" ^done (gdb) in both these cases because MI's -interpreter-exec just does: error ("%s", e.what ()); You won't see it either when running an MI command with the CLI's "interpreter-exec mi": (gdb) interpreter-exec mi "-foobar" ^error,msg="Undefined MI command: foobar",code="undefined-command" (gdb) This last case is because MI's interp::exec implementation never returns an error: gdb_exception mi_interp::exec (const char *command) { mi_execute_command_wrapper (command); return gdb_exception (); } Thus I think that "error in command" error is pretty pointless, and since it simplifies things to not have it, the patch just removes it. The patch also ends up addressing an old FIXME. Change-Id: I5a6432a80496934ac7127594c53bf5221622e393 Approved-By: Tom Tromey <tromey@adacore.com> Approved-By: Kevin Buettner <kevinb@redhat.com>
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-11-05Deprecate MI version 1Tom Tromey1-0/+10
MI version 1 is long since obsolete. Rather than remove it immediately (though I did send a patch for that), instead let's deprecate it in GDB 13 and then remove it for GDB 14. This version of the patch incorporates Simon's warning change, and Luis' recommendation to mention the gdb versions here.
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-2/+1
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-06-22Use std::string for interpreter_pTom Tromey1-9/+2
The global interpreter_p is a manually-managed 'char *'. This patch changes it to be a std::string instead, and removes some erroneous comments.