aboutsummaryrefslogtreecommitdiff
path: root/gdb/top.c
AgeCommit message (Collapse)AuthorFilesLines
2025-12-04gdb: small white space fix in print_gdb_hintsAndrew Burgess1-1/+1
A small white space fix in print_gdb_hints. There should be no user visible changes after this commit. Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
2025-12-04gdb: remove some unnecessary code from print_gdb_hintsAndrew Burgess1-2/+0
I noticed some code in print_gdb_hints that is unused. I rolled a patch, but while I was doing that commit: commit 06e470d8fc0ae0e83fe0977fdf8c011998980891 Date: Sat Nov 29 15:48:55 2025 +0100 gdb: handle unlimited screen width case in print_gdb_hints was merged that deleted some of the code I'd spotted. All that's left is a 'return' that can be removed, there's nothing after the 'if' block, the function just returns. There should be no user visible changes after this commit. Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
2025-12-04gdb: handle unlimited screen width case in print_gdb_hintsPatrick Monnerat1-5/+4
This avoids a crash when this function is called while screen width is unlimited. In such a case (unconditionally occurring in insight), WIDTH is returned as a negative signed integer, so it has to be compared to another signed integer, not a size_t. Also remove an unused WIDTH-sized variable that may fail in the above case.
2025-11-28[gdb/build, c++20] Fix UTF-8 string literal usageTom de Vries1-7/+19
PR build/33675 reports a build breaker: ... top.c: In function ‘void box_one_message(ui_file*, std::string, int)’: top.c:1368:35: error: conditional expression between distinct pointer types \ ‘const char8_t*’ and ‘const char*’ lacks a cast 1368 | const char *wall = emojis_ok () ? u8"\u2503" : "|"; | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ ... The problem is that UTF-8 string literals have type: - const char[N] (until C++20), or - const char8_t[N] (since C++20) Fix this by assigning to variables: ... static const char bd_heavy_vertical[] = u8"\u2503"; ... and using the variables instead. Tested by rebuilding on x86_64-linux, and starting gdb and checking the welcome message box. Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33675
2025-11-27gdb: Make startup message more user friendlyGuinevere Larsen1-10/+107
Currently, on startup, GDB prints a lot of licensing information and then a few hints for new users. While there is an attempt to separate the hints from the rest of the text, my user testing showed that it is not good enough, and most unfamiliar users will just skip the information. Especially considering that the documentation link happens before the separation. This commit attempts to make the startup message more friendly to new users by visually separating the most important commands from the copyright. If there is enough space available, a box is printed containing the hints (either using unicode box drawing characters, if emojis are allowed, or using ascii). If there isn't space for a box, a simple line separator is printed. The code deems "enough space available" when there is enough space to print the documentation URL inside the box, since the other hints will be broken into multiple lines if necessary. Here are examples of the 2 possible startups, with enough space: +-----------------------------------------------------------------+ | Find the GDB manual online at: | | http://www.gnu.org/software/gdb/documentation/ | | For help, type "help". | | Type "apropos <word>" to search for commands related to "word". | +-----------------------------------------------------------------+ And with limited space: --------------------------------------------- Find the GDB manual documentation resources o nline at: <http://www.gnu.org/software/gdb/document ation/>. For help, type "help". Type "apropos word" to search for commands re lated to "word". Approved-By: Tom Tromey <tom@tromey.com>
2025-11-17[gdb] Fix '_ ("foo")'Tom de Vries1-1/+1
Our documented style [1] is to use '_("foo")', not '_ ("foo")'. Fix this in a few places. [1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Gettext_macro
2025-09-09Use gnulib c-ctype module in gdbTom Tromey1-1/+0
PR ada/33217 points out that gdb incorrectly calls the <ctype.h> functions. In particular, gdb feels free to pass a 'char' like: char *str = ...; ... isdigit (*str) This is incorrect as isdigit only accepts EOF and values that can be represented as 'unsigned char' -- that is, a cast is needed here to avoid undefined behavior when 'char' is signed and a character in the string might be sign-extended. (As an aside, I think this API seems obviously bad, but unfortunately this is what the standard says, and some systems check this.) Rather than adding casts everywhere, this changes all the code in gdb that uses any <ctype.h> API to instead call the corresponding c-ctype function. Now, c-ctype has some limitations compared to <ctype.h>. It works as if the C locale is in effect, so in theory some non-ASCII characters may be misclassified. This would only affect a subset of character sets, though, and in most places I think ASCII is sufficient -- for example the many places in gdb that check for whitespace. Furthermore, in practice most users are using UTF-8-based locales, where these functions aren't really informative for non-ASCII characters anyway; see the existing workarounds in gdb/c-support.h. Note that safe-ctype.h cannot be used because it causes conflicts with readline.h. And, we canot poison the <ctype.h> identifiers as this provokes errors from some libstdc++ headers. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33217 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-08-14gdb, gdbserver: update copyright years in copyright noticesSimon Marchi1-1/+1
The copyright notices printed by these programs still use year 2024. Update to 2025. It seems like a trivial patch to me, but I am posting it for review, in case there's something wrong in the new-year process that caused them to be missed, in which case we should address that too. Change-Id: I7d9541bb154b8000e66cfead4e4228e33c49f18b Approved-by: Kevin Buettner <kevinb@redhat.com>
2025-08-14gdb, configure: Add enable-binary-file-format option for configureGuinevere Larsen1-0/+5
GDB has support for many binary file formats, some which might be very unlikely to be found in some situations (such as the XCOFF format in an x86 system). This commit introduces the option for a user to choose which formats GDB will support at build configuration time. This is especially useful to avoid possible security concerns with readers that aren't expected to be used at all, as they are one of the simplest vectors for an attacker to try and hit GDB with. This change can also reduce the size of the final binary, if that is a concern. This commit adds a switch to the configure script allowing a user to only enable selected file formats, called --enable-binary-file-formats. The default behavior when the switch is omitted is to compile all file formats, keeping the original behavior of the script. At the time of this commit, the valid options for this option are: dbx, coff (which includes coff-pe), xcoff, mips, elf, macho and all. All is treated especially, activating all supported readers. A few targets may require specific binary file format support, as they directly call functions defined by the file reader. Specifically, windows targets require coff support, and rs6000 aix and lynx178 targets require xcoff support. Considering that those formats are the main - or only - one available in those targets, I believe it makes sense to re-enable those readers. If that happens, the script will emit the following warning: FOO is required to support one or more requested targets. Adding it Users aren't able to force the disabling of those formats, since GDB will not compile without those readers. Ideally we'd like to be able to disable even those formats, in case a user wants to build GDB only to examine remote files for example, but the current infrastructure for the file format readers doesn't allow us to do it. Mach-O and elf support are also dependent on BFD support being compiled in. In case one of those was requested and BFD does not support them, the following error is emitted: FOO was requested, but BFD does not support it. Finally, this configure switch is also printed by the "show configuration" command in GDB. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2025-08-05Do not include cleanups.h from common-defs.hTom Tromey1-0/+1
Most code doesn't use cleanups any more, so remove the include of cleanups.h from common-defs.h, and then only include that file where it is truly needed. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-06-26Change file initialization to use INIT_GDB_FILE macroTom Tromey1-3/+1
This patch introduces a new macro, INIT_GDB_FILE. This is used to replace the current "_initialize_" idiom when introducing a per-file initialization function. That is, rather than write: void _initialize_something (); void _initialize_something () { ... } ... now you would write: INIT_GDB_FILE (something) { ... } The macro handles both the declaration and definition of the function. The point of this approach is that it makes it harder to accidentally cause an initializer to be omitted; see commit 2711e475 ("Ensure cooked_index_entry self-tests are run"). Specifically, the regexp now used by make-init-c seems harder to trick. New in v2: un-did some erroneous changes made by the script. The bulk of this patch was written by script. Regression tested on x86-64 Fedora 41.
2025-06-02gdb: introduce a per-interpreter event servicing methodPatrick Monnerat1-2/+2
This allows an interpreter to override internal calls to gdb_do_one_event in case the former needs to handle alternate event sources. The default action is to call gdb_do_one_event and this is not overriden in current internal interpreters. However this feature allows to easily embed Tcl/Tk in insight that needs to concurrently handle Tcl events for GUI handling. In all cases, an interpreter event servicing method must call gdb_do_one_event at some point. All internal event servicing calls from gdb now direct to the interpreter-specific method rather than gdb_do_one_event itself.
2025-04-08Update copyright dates to include 2025Tom Tromey1-1/+1
This updates the copyright headers to include 2025. I did this by running gdb/copyright.py and then manually modifying a few files as noted by the script. Approved-By: Eli Zaretskii <eliz@gnu.org>
2025-04-03Many minor typo fixesTom Tromey1-1/+1
I ran codespell on gdb/*.[chyl] and fixed a bunch of simple typos. Most of what remains is trickier, i.e., spots where a somewhat natural name of something in the code is flagged as a typo. Reviewed-By: Tom de Vries <tdevries@suse.de>
2025-01-29Use command style in "help" commandTom Tromey1-4/+2
This changes the help command to use the new command style when displaying text like: List of "catch" subcommands: As a side effect, this mildly -- but not hugely -- cleans up some i18n issues in help_list. The header comment for that function is also changed to the gdb style. Finally, this function used to print something like: Type "help catch" followed by catch subcommand name for full documentation. The second "catch" here seems redundant to me, so this patch removes it.
2025-01-12Add an option with a color type.Andrei Pikas1-0/+14
Colors can be specified as "none" for terminal's default color, as a name of one of the eight standard colors of ISO/IEC 6429 "black", "red", "green", etc., as an RGB hexadecimal tripplet #RRGGBB for 24-bit TrueColor, or as an integer from 0 to 255. Integers 0 to 7 are the synonyms for the standard colors. Integers 8-15 are used for the so-called bright colors from the aixterm extended 16-color palette. Integers 16-255 are the indexes into xterm extended 256-color palette (usually 6x6x6 cube plus gray ramp). In general, 256-color palette is terminal dependent and sometimes can be changed with OSC 4 sequences, e.g. "\033]4;1;rgb:00/FF/00\033\\". It is the responsibility of the user to verify that the terminal supports the specified colors. PATCH v5 changes: documentation fixed. PATCH v6 changes: documentation fixed. PATCH v7 changes: rebase onto master and fixes after review. PATCH v8 changes: fixes after review.
2025-01-12Remove unused declaration and macrosTom Tromey1-4/+0
event-top.h declares the_prompts, but it is never defined. It's a leftover from some ancient refactoring. Similarly, top.c defines a few prompt-related macros, but these are unused. This patch removes these.
2024-12-20[gdb/cli] Don't prefill for operate-and-get-next of last commandTom de Vries1-6/+10
Consider operate-and-get-next [1] in bash: ... $ <echo 1>echo 1<enter> 1 $ <echo 2>echo 2<enter> 2 $ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o> 1 $ echo 2<Ctrl-o> 2 $ echo 1 ... So, typing Ctrl-o: - executes the recalled command, and - prefills the next one (which then can be executed again with Ctrl-o). We have the same functionality in gdb, but when recalling the last command from history with bash we have no prefill: ... $ <echo 1>echo 1<enter> 1 $ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o> 1 $ ... but with gdb do we have a prefill: ... (gdb) echo 1\n 1 (gdb) <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1\n<Ctrl-o> 1 (gdb) echo 1\n ... Following the principle of least surprise [2], I think gdb should do what bash does. Fix this by: - signalling this case in gdb_rl_operate_and_get_next using "operate_saved_history = -1", and - handling operate_saved_history == -1 in gdb_rl_operate_and_get_next_completion. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR cli/32485 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32485 [1] https://www.man7.org/linux/man-pages/man3/readline.3.html [2] https://en.wikipedia.org/wiki/Principle_of_least_astonishment
2024-12-12Introduce "command" stylingTom Tromey1-7/+9
This adds a new "command" style that is used when styling the name of a gdb command. Note that not every instance of a command name that is output by gdb is changed here. There is currently no way to style error() strings, and there is no way to mark up command help strings. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31747 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-11-12gdb/readline: add readline library version to 'show configuration'Andrew Burgess1-0/+10
When debugging readline issues I'd like an easy way to know (for sure) what version of readline GDB is using. This could also be useful when writing readline tests, knowing the precise readline version will allow us to know if we expect a test to pass or not. Add the readline library version to the output of the 'show configuration' command. Also include a suffix indicating if we are using the system readline, or the statically linked in readline. The information about static readline vs shared readline can be figured out from the configure command output, but having it repeated in the readline version line makes it super easy to grok within tests, and it's super cheap, so I don't see this as a problem.
2024-11-11Add setting to control frame language mismatch warningTom Tromey1-1/+1
A customer noted that there is no way to prevent the "current language does not match this frame" warning. This patch adds a new setting to allow this warning to be suppressed. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-08gdb: include --enable-targets in 'show configuration' outputAndrew Burgess1-0/+5
Include the value of configuration flag --enable-targets in the output of GDB command 'show configuration' and also in the output printed for 'gdb --configuration'. This will make it easier to see how GDB was built. No tests added or updated as we can't really check for a specific flag appearing or not appearing on the configuration output. But we do print the configuration within lib/gdb.exp to check which features are built into GDB, so if this change broke configuration printing then plenty of tests should stop working (they don't). Approved-By: Tom Tromey <tom@tromey.com>
2024-09-24[gdb] Eliminate catch(...) in execute_fn_to_stringTom de Vries1-12/+2
Remove duplicate code in execute_fn_to_string using SCOPE_EXIT. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-06-27gdb: add overloads of gdb_abspathAndrew Burgess1-1/+1
Add two overloads of gdb_abspath, one which takes std::string and one which takes gdb::unique_xmalloc_ptr<char>, then make use of these overloads throughout GDB and gdbserver. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-30gdb: remove unused includes in utils.hSimon Marchi1-0/+1
Remove some includes reported as unused by clangd. Add some includes in other files that were previously relying on the transitive include. Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e
2024-05-18Remove unnecessary block from execute_fn_to_ui_fileTom Tromey1-14/+12
I noticed that execute_fn_to_ui_file has an extra, unnecessary block. This patch removes it.
2024-05-17Remove gdb_stdtargerrTom Tromey1-2/+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-04-25gdb: remove gdbcmd.hSimon Marchi1-1/+0
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-04-25gdb: move execute function declarations from gdbcmd.h to top.hSimon Marchi1-6/+7
These functions are implemented in top.c, move their declarations to top.h. Change-Id: I8893ef91d955156a6530734fefe8002d78c3e5fc Approved-By: Tom Tromey <tom@tromey.com>
2024-04-16Remove excess whitespace from doc strings of some commandsEli Zaretskii1-1/+1
I've noticed that doc strings of some commands, like "set cwd" and "set inferior-tty", have some excess whitespace, which makes them display with unexpected indentation, at least in a Windows command prompt window. This patch fixes that. * gdb/linux-nat.c (_initialize_linux_nat): * gdb/riscv-tdep.c (riscv_insn): * gdb/top.c (quit_force): * gdb/infcmd.c (_initialize_infcmd): Remove excess whitespace.
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-03-25gdb: move more completion setup into completer.cAndrew Burgess1-3/+0
Move more setup of the readline global state relating to tab completion into completer.c out of top.c. Lots of the readline setup is done in init_main (top.c). This commit moves those bits of initialisation that relate to completion, and which are only set the one time, into completer.c. This does mean that readline initialisation is now done in multiple locations, some in init_main (top.c) and some in completer.c, but I think this is OK. The work done in init_main is the general readline setup. I think making static what can be made static, and having it all in one file, makes things easier to reason about. So I'm OK with having this split initialisation. The only completion related thing which is still setup in top.c is rl_completion_display_matches_hook. I've left this where it is for now as rl_completion_display_matches_hook is also updated in the tui code, and the display hook functions are not in completer.c anyway, so moving this initialisation to completer.c would not allow anything else to be made static. There should be no user visible changes after this commit.
2024-03-25gdb: fix bug where quote characters would become nullptrAndrew Burgess1-1/+0
In gdb_completion_word_break_characters_throw, after calling complete_line_internal, if the completion function chose to use a custom word point then we set rl_completer_quote_characters to NULL. However, nowhere do we set rl_completer_quote_characters back to its default value, which is setup in init_main (top.c). An example of something that uses a custom word point for its completion is 'thread apply all ...'. An example of something that relies on rl_completer_quote_characters would be completion of a quoted filename that contains white space. Consider this shell and GDB session. The <TAB> markers indicate where I've used tab to trigger completion: $ mkdir /tmp/aaa\ bbb $ touch /tmp/aaa\ bbb/xx\ 11 $ touch /tmp/aaa\ bbb/xx\ 22 $ gdb -q (gdb) file '/tmp/aaa bbb/xx<TAB><TAB> xx 11 xx 22 (gdb) thread apply all hel<TAB> (gdb) thread apply all help (gdb) file '/tmp/aaa bbb/xx<TAB><TAB> First I create a directory structure which uses white space within file and directory names. Then within GDB I use the 'file' command and use a single quote to quote the filename. When I tab complete GDB correctly offers the two files within the directory '/tmp/aaa bbb/'. This works because rl_completer_quote_characters contains the single quote, and so readline knows that it is trying to complete the string that starts after the single quote: /tmp/aaa bbb/xx Next I invoke the completer for the 'thread apply all' command, to do this I type 'thread apply all hel' and hit tab, this expands to the one completion 'thread apply all help'. We can run this command or not, it doesn't matter (there are no threads, so we'll get no output). Now I repeat the original 'file' completion. This time though I don't get offered any completions. The reason is that the 'thread apply all' completer set rl_completer_quote_characters to nullptr. Now, when readline tries to figure out the word to complete it doesn't see the single quote as the start of a quoted word, so instead readline falls back to the word break characters, and in this case spots the white space. As a result readline tries to complete the string 'bbb/xx' which obviously doesn't have any completions. By setting rl_completer_quote_characters each time completion is invoked this problem is resolved and the second 'file' command completes as expected. I've extended gdb.base/filename-completion.exp to also test with quoted filenames, and added a 'thread apply all' completion at the start to expose this bug. As setting of rl_completer_quote_characters is now all done in the completer.c file the function get_gdb_completer_quote_characters() could be made static. However, as this function is only used one time to initialise rl_completer_quote_characters, I've instead just deleted get_gdb_completer_quote_characters() and used gdb_completer_quote_characters directly.
2024-02-27Change finalize_values into a final cleanupTom Tromey1-6/+0
This removes finalize_values in favor of adding a new final cleanup. This is safe now that extension languages are explicitly shut down.
2024-02-27Add extension_language_ops::shutdownTom Tromey1-0/+2
Right now, Python is shut down via a final cleanup. However, it seems to me that it is better for extension languages to be shut down explicitly, after all the ordinary final cleanups are run. The main reason for this is that a subsequent patch adds another case like finalize_values; and rather than add a series of workarounds for Python shutdown, it seemed better to let these be done via final cleanups, and then have Python shutdown itself be the special case.
2024-01-31Fix AIX build break.Aditya Vidyadhar Kamath1-4/+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-2/+2
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.
2024-01-08Refactor complaint thread-safety approachTom Tromey1-1/+1
This patch changes the way complaint works in a background thread. The new approach requires installing a complaint interceptor in each worker, and then the resulting complaints are treated as one of the results of the computation. This change is needed for a subsequent patch, where installing a complaint interceptor around a parallel-for is no longer a viable approach.
2023-11-17gdb: pass address_space to target dcache functionsSimon Marchi1-1/+1
A simple refactor to make the reference to current_program_space bubble up one level. No behavior changes expected. Change-Id: I237cf2f45ae73c35bcb433ce40e3c03cef6b87e2
2023-10-05gdb/configure.ac: Add option --with-additional-debug-dirsThiago Jung Bauermann1-0/+6
If you want to install GDB in a custom prefix, have it look for debug info in that prefix but also in the distro's default location (typically, /usr/lib/debug) and run the GDB testsuite before doing "make install", you have a bit of a problem: Configuring GDB with '--prefix=$PREFIX' sets the GDB 'debug-file-directory' parameter to $PREFIX/lib/debug. Unfortunately this precludes GDB from looking for distro-installed debug info in /usr/lib/debug. For regular GDB use you could set debug-file-directory to $PREFIX:/usr/lib/debug in $PREFIX/etc/gdbinit so that GDB will look in both places, but if you want to run the testsuite then that doesn't help because in that case GDB runs with the '-nx' option. There's the configure option '--with-separate-debug-dir' to set the default value for 'debug-file-directory', but it accepts only one directory and not a list. I considered modifying it to accept a list, but it's not obvious how to do that because its value is also used by BFD, as well as processed for "relocatability". I thought it was simpler to add a new option to specify a list of additional directories that will be appended to the debug-file-directory setting. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2023-09-26Use string_file::release in some placesTom Tromey1-2/+2
I found a few spots like: string_file f; std::string x = f.string (); However, string_file::string returns a 'const std::string &'... so it seems to me that this must be copying the string (? I find it hard to reason about this in C++). This patch changes these spots to use release() instead, which moves the string. Reviewed-by: Keith Seitz <keiths@redhat.com> Reviewed-by: Lancelot Six <lancelot.six@amd.com>
2023-07-26[gdb/tui] Fix secondary promptTom de Vries1-0/+6
With CLI, a session defining a command looks like: ... (gdb) define foo Type commands for definition of "foo". End with a line saying just "end". >bar >end (gdb) ... With TUI however, we get the same secondary prompts, and type the same, but are left with: ... (gdb) define foo Type commands for definition of "foo". End with a line saying just "end". (gdb) ... Fix this by calling tui_inject_newline_into_command_window in gdb_readline_wrapper_line, as is done in tui_command_line_handler. Tested on x86_64-linux. PR tui/30636 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30636
2023-05-30[gdb] Mention --with/without-system-readline for --configurationTom de Vries1-0/+10
Simon reported that the new test-case gdb.tui/pr30056.exp fails with system readline. This is because the test-case requires a fix in readline that's present in our in-repo copy of readline, but most likely not in any system readline yet. Fix this by: - mentioning --with-system-readline or --without-system-readline in the configuration string. - adding a new proc with_system_readline that makes this information available in the testsuite. - using this in test-case gdb.tui/pr30056.exp to declare it unsupported for --with-system-readline. Tested on x86_64-linux. Reported-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-05-19gdb: fix post-hook execution for remote targetsJan Vrany1-1/+3
Commit b5661ff2 ("gdb: fix possible use-after-free when executing commands") attempted to fix possible use-after-free in case command redefines itself. Commit 37e5833d ("gdb: fix command lookup in execute_command ()") updated the previous fix to handle subcommands as well by using the original command string to lookup the command again after its execution. This fixed the test in gdb.base/define.exp but it turned out that it does not work (at least) for "target remote" and "target extended-remote". The problem is that the command buffer P passed to execute_command () gets overwritten in dont_repeat () while executing "target remote" command itself: #0 dont_repeat () at top.c:822 #1 0x000055555730982a in target_preopen (from_tty=1) at target.c:2483 #2 0x000055555711e911 in remote_target::open_1 (name=0x55555881c7fe ":1234", from_tty=1, extended_p=0) at remote.c:5946 #3 0x000055555711d577 in remote_target::open (name=0x55555881c7fe ":1234", from_tty=1) at remote.c:5272 #4 0x00005555573062f2 in open_target (args=0x55555881c7fe ":1234", from_tty=1, command=0x5555589d0490) at target.c:853 #5 0x0000555556ad22fa in cmd_func (cmd=0x5555589d0490, args=0x55555881c7fe ":1234", from_tty=1) at cli/cli-decode.c:2737 #6 0x00005555573487fd in execute_command (p=0x55555881c802 "4", from_tty=1) at top.c:688 Therefore the second call to lookup_cmd () at line 697 fails to find command because the original command string is gone. This commit addresses this particular problem by creating a *copy* of original command string for the sole purpose of using it after command execution to lookup the command again. It may not be the most efficient way but it's safer given that command buffer is shared and overwritten in hard-to-foresee situations. Tested on x86_64-linux. PR 30249 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30249 Approved-By: Tom Tromey <tom@tromey.com>
2023-05-01gdb: move struct ui and related things to ui.{c,h}Simon Marchi1-143/+6
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-30PR gdb/30219: Clear sync_quit_force_run in quit_forceKevin Buettner1-0/+8
PR 30219 shows an internal error due to a "Bad switch" in print_exception() in gdb/exceptions.c. The switch in question contains cases for RETURN_QUIT and RETURN_ERROR, but is missing a case for the recently added RETURN_FORCED_QUIT. This commit adds that case. Making the above change allows the errant test case to pass, but does not fix the underlying problem, which I'll describe shortly. Even though the addition of a case for RETURN_FORCED_QUIT isn't the actual fix, I still think it's important to add this case so that other situations which lead to print_exeption() being called won't generate that "Bad switch" internal error. In order to understand the underlying problem, please examine this portion of the backtrace from the bug report: 0x5576e4ff5780 print_exception /home/smarchi/src/binutils-gdb/gdb/exceptions.c:100 0x5576e4ff5930 exception_print(ui_file*, gdb_exception const&) /home/smarchi/src/binutils-gdb/gdb/exceptions.c:110 0x5576e6a896dd quit_force(int*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:1849 The real problem is in quit_force; here's the try/catch which eventually leads to the internal error: /* Get out of tfind mode, and kill or detach all inferiors. */ try { disconnect_tracing (); for (inferior *inf : all_inferiors ()) kill_or_detach (inf, from_tty); } catch (const gdb_exception &ex) { exception_print (gdb_stderr, ex); } While running the calls in the try-block, a QUIT check is being performed. This check finds that sync_quit_force_run is (still) set, causing a gdb_exception_forced_quit to be thrown. The exception gdb_exception_forced_quit is derived from gdb_exception, causing exception_print to be called. As shown by the backtrace, print_exception is then called, leading to the internal error. The actual fix, also implemented by this commit, is to clear sync_quit_force_run along with the quit flag. This will allow the various cleanup code, called by quit_force, to run without triggering a gdb_exception_forced_quit. (Though, if another SIGTERM is sent to the gdb process, these flags will be set again and a QUIT check in the cleanup code will detect it and throw the exception.) Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30219 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-09gdb, gdbserver, gdbsupport: fix whitespace issuesSimon Marchi1-1/+1
Replace spaces with tabs in a bunch of places. Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
2023-02-24Don't use struct buffer in top.cTom Tromey1-14/+8
This changes top.c to use std::string rather than struct buffer. Like the event-top.c change, this is not completely ideal in that it requires a copy of the string.
2023-02-21gdb: add --with-curses to --configuration outputPhilippe Blain1-0/+10
'gdb --configuration' does not mention if GDB was built with curses. Since b5075fb68d4 (Rename to allow_tui_tests, 2023-01-08) it does show --enable-tui (or --disable-tui), but one might want to know if GDB was built with curses independently of the availability of the TUI. Since configure.ac uses AC_SEARCH_LIBS to check for the curses library, we do not get an automatically defined HAVE_LIBCURSES symbol in config.in. We do have symbols defined by AC_CHECK_HEADERS (HAVE_CURSES_H, etc.) but it would be cumbersome to use those in print_gdb_configuration because we would have to check for all 6 symbols corresponding the 6 headers listed. This would also increase the maintenance burden if support for other variations of curses are added. Instead, define 'HAVE_LIBCURSES' ourselves by adding an 'action-if-found' argument to AC_SEARCH_LIBS, and use it in print_gdb_configuration. While at it, remove the condition on 'ac_cv_search_waddstr' and set 'curses_found' directly in 'action-if-found'. Change-Id: Id90e3d73990e169cee51bcc3e1d52072cfacd5b8 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13gdb: 'show config' shows --with[out]-amd-dbgapiLancelot SIX1-0/+10
Ensure that the "show configuration" command and the "--configuration" command line switch shows if GDB was built with the AMDGPU support or not. This will be used in a later patch in this series. Approved-By: Simon Marchi <simon.marchi@efficios.com>