aboutsummaryrefslogtreecommitdiff
path: root/gdb/cli
AgeCommit message (Collapse)AuthorFilesLines
2023-06-20Use std::string in do_set_commandTom Tromey1-15/+7
do_set_command manually updates a string, only to copy it to a std::string and free the working copy. This patch changes this code to use std::string for everything, simplifying the code and removing a copy. Reviewed-by: John Baldwin <jhb@FreeBSD.org>
2023-06-09gdb: fix ASan failure after recent string changesAndrew Burgess1-1/+7
After this commit: commit baab375361c365afee2577c94cbbd3fdd443d6da Date: Tue Jul 13 14:44:27 2021 -0400 gdb: building inferior strings from within GDB It was pointed out that a new ASan failure had been introduced which was triggered by gdb.base/internal-string-values.exp: (gdb) PASS: gdb.base/internal-string-values.exp: test_setting: all langs: lang=ada: ptype "foo" print $_gdb_maint_setting("test-settings string") ================================================================= ==80377==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000068034 at pc 0x564785cba682 bp 0x7ffd20644620 sp 0x7ffd20644610 READ of size 1 at 0x603000068034 thread T0 #0 0x564785cba681 in find_command_name_length(char const*) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2129 #1 0x564785cbacb2 in lookup_cmd_1(char const**, cmd_list_element*, cmd_list_element**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, bool) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2186 #2 0x564785cbb539 in lookup_cmd_1(char const**, cmd_list_element*, cmd_list_element**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, bool) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2248 #3 0x564785cbbcf3 in lookup_cmd(char const**, cmd_list_element*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2339 #4 0x564785c82df2 in setting_cmd /tmp/src/binutils-gdb/gdb/cli/cli-cmds.c:2219 #5 0x564785c84274 in gdb_maint_setting_internal_fn /tmp/src/binutils-gdb/gdb/cli/cli-cmds.c:2348 #6 0x564788167b3b in call_internal_function(gdbarch*, language_defn const*, value*, int, value**) /tmp/src/binutils-gdb/gdb/value.c:2321 #7 0x5647854b6ebd in expr::ada_funcall_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:11254 #8 0x564786658266 in expression::evaluate(type*, noside) /tmp/src/binutils-gdb/gdb/eval.c:111 #9 0x5647871242d6 in process_print_command_args /tmp/src/binutils-gdb/gdb/printcmd.c:1322 #10 0x5647871244b3 in print_command_1 /tmp/src/binutils-gdb/gdb/printcmd.c:1335 #11 0x564787125384 in print_command /tmp/src/binutils-gdb/gdb/printcmd.c:1468 #12 0x564785caac44 in do_simple_func /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:95 #13 0x564785cc18f0 in cmd_func(cmd_list_element*, char const*, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2735 #14 0x564787c70c68 in execute_command(char const*, int) /tmp/src/binutils-gdb/gdb/top.c:574 #15 0x564786686180 in command_handler(char const*) /tmp/src/binutils-gdb/gdb/event-top.c:543 #16 0x56478668752f in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /tmp/src/binutils-gdb/gdb/event-top.c:779 #17 0x564787dcb29a in tui_command_line_handler /tmp/src/binutils-gdb/gdb/tui/tui-interp.c:104 #18 0x56478668443d in gdb_rl_callback_handler /tmp/src/binutils-gdb/gdb/event-top.c:250 #19 0x7f4efd506246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb) #20 0x564786683dea in gdb_rl_callback_read_char_wrapper_noexcept /tmp/src/binutils-gdb/gdb/event-top.c:192 #21 0x564786684042 in gdb_rl_callback_read_char_wrapper /tmp/src/binutils-gdb/gdb/event-top.c:225 #22 0x564787f1b119 in stdin_event_handler /tmp/src/binutils-gdb/gdb/ui.c:155 #23 0x56478862438d in handle_file_event /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:573 #24 0x564788624d23 in gdb_wait_for_event /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:694 #25 0x56478862297c in gdb_do_one_event(int) /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:264 #26 0x564786df99f0 in start_event_loop /tmp/src/binutils-gdb/gdb/main.c:412 #27 0x564786dfa069 in captured_command_loop /tmp/src/binutils-gdb/gdb/main.c:476 #28 0x564786dff61f in captured_main /tmp/src/binutils-gdb/gdb/main.c:1320 #29 0x564786dff75c in gdb_main(captured_main_args*) /tmp/src/binutils-gdb/gdb/main.c:1339 #30 0x564785381b6d in main /tmp/src/binutils-gdb/gdb/gdb.c:32 #31 0x7f4efbc3984f (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e) #32 0x7f4efbc39909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e) #33 0x564785381934 in _start (/tmp/build/binutils-gdb/gdb/gdb+0xabc5934) (BuildId: 90de353ac158646e7dab501b76a18a76628fca33) 0x603000068034 is located 0 bytes after 20-byte region [0x603000068020,0x603000068034) allocated by thread T0 here: #0 0x7f4efcee0cd1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x5647856265d8 in xcalloc /tmp/src/binutils-gdb/gdb/alloc.c:97 #2 0x564788610c6b in xzalloc(unsigned long) /tmp/src/binutils-gdb/gdbsupport/common-utils.cc:29 #3 0x56478815721a in value::allocate_contents(bool) /tmp/src/binutils-gdb/gdb/value.c:929 #4 0x564788157285 in value::allocate(type*, bool) /tmp/src/binutils-gdb/gdb/value.c:941 #5 0x56478815733a in value::allocate(type*) /tmp/src/binutils-gdb/gdb/value.c:951 #6 0x5647854ae81c in expr::ada_string_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:10675 #7 0x5647854b63b8 in expr::ada_funcall_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:11184 #8 0x564786658266 in expression::evaluate(type*, noside) /tmp/src/binutils-gdb/gdb/eval.c:111 #9 0x5647871242d6 in process_print_command_args /tmp/src/binutils-gdb/gdb/printcmd.c:1322 #10 0x5647871244b3 in print_command_1 /tmp/src/binutils-gdb/gdb/printcmd.c:1335 #11 0x564787125384 in print_command /tmp/src/binutils-gdb/gdb/printcmd.c:1468 #12 0x564785caac44 in do_simple_func /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:95 #13 0x564785cc18f0 in cmd_func(cmd_list_element*, char const*, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2735 #14 0x564787c70c68 in execute_command(char const*, int) /tmp/src/binutils-gdb/gdb/top.c:574 #15 0x564786686180 in command_handler(char const*) /tmp/src/binutils-gdb/gdb/event-top.c:543 #16 0x56478668752f in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /tmp/src/binutils-gdb/gdb/event-top.c:779 #17 0x564787dcb29a in tui_command_line_handler /tmp/src/binutils-gdb/gdb/tui/tui-interp.c:104 #18 0x56478668443d in gdb_rl_callback_handler /tmp/src/binutils-gdb/gdb/event-top.c:250 #19 0x7f4efd506246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb) The problem is in cli/cli-cmds.c, in the function setting_cmd, where we do this: const char *a0 = (const char *) argv[0]->contents ().data (); Here argv[0] is a value* which we know is either a TYPE_CODE_ARRAY or a TYPE_CODE_STRING. The problem is that the above line is casting the value contents directly to a C-string, i.e. one that is assumed to have a null-terminator at the end. After the above commit this can no longer be assumed to be true. A string value will be represented just as it would be in the current language, so for Ada and Fortran the string will be an array of characters with no null-terminator at the end. My proposed solution is to copy the string contents into a std::string object, and then use the std::string::c_str() value, this will ensure that a null-terminator has been added. I had a check through GDB at places TYPE_CODE_STRING was used and couldn't see any other obvious places where this type of assumption was being made, so hopefully this is the only offender. Running the above test with ASan compiled in no longer gives an error. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-06-05gdb: building inferior strings from within GDBAndrew Burgess1-14/+4
History Of This Patch ===================== This commit aims to address PR gdb/21699. There have now been a couple of attempts to fix this issue. Simon originally posted two patches back in 2021: https://sourceware.org/pipermail/gdb-patches/2021-July/180894.html https://sourceware.org/pipermail/gdb-patches/2021-July/180896.html Before Pedro then posted a version of his own: https://sourceware.org/pipermail/gdb-patches/2021-July/180970.html After this the conversation halted. Then in 2023 I (Andrew) also took a look at this bug and posted two versions: https://sourceware.org/pipermail/gdb-patches/2023-April/198570.html https://sourceware.org/pipermail/gdb-patches/2023-April/198680.html The approach taken in my first patch was pretty similar to what Simon originally posted back in 2021. My second attempt was only a slight variation on the first. Pedro then pointed out his older patch, and so we arrive at this patch. The GDB changes here are mostly Pedro's work, but updated by me (Andrew), any mistakes are mine. The tests here are a combinations of everyone's work, and the commit message is new, but copies bits from everyone's earlier work. Problem Description =================== Bug PR gdb/21699 makes the observation that using $_as_string with GDB's printf can cause GDB to print unexpected data from the inferior. The reproducer is pretty simple: #include <stddef.h> static char arena[100]; /* Override malloc() so value_coerce_to_target() gets a known pointer, and we know we"ll see an error if $_as_string() gives a string that isn't null terminated. */ void *malloc (size_t size) { memset (arena, 'x', sizeof (arena)); if (size > sizeof (arena)) return NULL; return arena; } int main () { return 0; } And then in a GDB session: $ gdb -q test Reading symbols from /tmp/test... (gdb) start Temporary breakpoint 1 at 0x4004c8: file test.c, line 17. Starting program: /tmp/test Temporary breakpoint 1, main () at test.c:17 17 return 0; (gdb) printf "%s\n", $_as_string("hello") "hello"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (gdb) quit The problem above is caused by how value_cstring is used within py-value.c, but once we understand the issue then it turns out that value_cstring is used in an unexpected way in many places within GDB. Within py-value.c we have a null-terminated C-style string. We then pass a pointer to this string, along with the length of this string (so not including the null-character) to value_cstring. In value_cstring GDB allocates an array value of the given character type, and copies in requested number of characters. However value_cstring does not add a null-character of its own. This means that the value created by calling value_cstring is only null-terminated if the null-character is included in the passed in length. In py-value.c this is not the case, and indeed, in most uses of value_cstring, this is not the case. When GDB tries to print one of these strings the value contents are pushed to the inferior, and then read back as a C-style string, that is, GDB reads inferior memory until it finds a null-terminator. For the py-value.c case, no null-terminator is pushed into the inferior, so GDB will continue reading inferior memory until a null-terminator is found, with unpredictable results. Patch Description ================= The first thing this patch does is better define what the arguments for the two function value_cstring and value_string should represent. The comments in the header file are updated to describe whether the length argument should, or should not, include a null-character. Also, the data argument is changed to type gdb_byte. The functions as they currently exist will handle wide-characters, in which case more than one 'char' would be needed for each character. As such using gdb_byte seems to make more sense. To avoid adding casts throughout GDB, I've also added an overload that still takes a 'char *', but asserts that the character type being used is of size '1'. The value_cstring function is now responsible for adding a null character at the end of the string value it creates. However, once we start looking at how value_cstring is used, we realise there's another, related, problem. Not every language's strings are null terminated. Fortran and Ada strings, for example, are just an array of characters, GDB already has the function value_string which can be used to create such values. Consider this example using current GDB: (gdb) set language ada (gdb) p $_gdb_setting("arch") $1 = (97, 117, 116, 111) (gdb) ptype $ type = array (1 .. 4) of char (gdb) p $_gdb_maint_setting("test-settings string") $2 = (0) (gdb) ptype $ type = array (1 .. 1) of char This shows two problems, first, the $_gdb_setting and $_gdb_maint_setting functions are calling value_cstring using the builtin_char character, rather than a language appropriate type. In the first call, the 'arch' case, the value_cstring call doesn't include the null character, so the returned array only contains the expected characters. But, in the $_gdb_maint_setting example we do end up including the null-character, even though this is not expected for Ada strings. This commit adds a new language method language_defn::value_string, this function takes a pointer and length and creates a language appropriate value that represents the string. For C, C++, etc this will be a null-terminated string (by calling value_cstring), and for Fortran and Ada this can be a bounded array of characters with no null terminator. Additionally, this new language_defn::value_string function is responsible for selecting a language appropriate character type. After this commit the only calls to value_cstring are from the C expression evaluator and from the default language_defn::value_string. And the only calls to value_string are from Fortan, Ada, and ObjectC related code. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21699 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Co-Authored-By: Pedro Alves <pedro@palves.net> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-06-05[gdb] Fix more typosTom de Vries1-2/+2
Fix some more typos: - distinquish -> distinguish - actualy -> actually - singe -> single - frash -> frame - chid -> child - dissassembler -> disassembler - uninitalized -> uninitialized - precontidion -> precondition - regsiters -> registers - marge -> merge - sate -> state - garanteed -> guaranteed - explictly -> explicitly - prefices (nonstandard plural) -> prefixes - bondary -> boundary - formated -> formatted - ithe -> the - arrav -> array - coresponding -> corresponding - owend -> owned - fials -> fails - diasm -> disasm - ture -> true - tpye -> type There's one code change, the name of macro SIG_CODE_BONDARY_FAULT changed to SIG_CODE_BOUNDARY_FAULT. Tested on x86_64-linux.
2023-05-30gdb: add interp::on_param_changed methodSimon Marchi1-6/+7
Same idea as previous patches, but for command_param_changed. Change-Id: I7c2196343423360da05f016f8ffa871c064092bb
2023-05-30gdb: add interp::on_user_selected_context_changed methodSimon Marchi2-29/+8
Same as previous patches, but for user_selected_context_changed. Change-Id: I40de15be897671227d4bcf3e747f0fd595f0d5be
2023-05-30gdb: add interp::on_command_error methodSimon Marchi2-10/+3
Same idea as the previous patches, but for command_error. Change-Id: If6098225dd72fad8be13b3023b35bc8bc48efb9d
2023-05-30gdb: add interp::on_sync_execution_done methodSimon Marchi2-10/+3
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-13/+4
Same as previous patches, but for no_history. Change-Id: I06930fe7cb4082138c6c5496c5118fe4951c10da
2023-05-30gdb: add interp::on_exited methodSimon Marchi2-13/+4
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-15/+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-16/+6
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-14/+5
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-12gdb: remove unnecessary call to std::string constructorSimon Marchi1-1/+1
I spotted this explicit call to std::string, which creates an unnecessary temporary extra std::string, while calling emplace_back. I'm not sure if it has any impact in an optimized build, maybe the compiler elides it. But still, it's unnecessary. Change-Id: I873337ea91db29ac06267aff8fc12dcf52824cac Approved-By: Tom Tromey <tom@tromey.com>
2023-05-12gdb: fix error message for $_gdb_maint_settingAndrew Burgess1-2/+10
I spotted this behaviour: (gdb) p $_gdb_maint_setting("xxx") First argument of $_gdb_maint_setting must be a valid setting of the 'show' command. Notice that GDB claims I need to use a setting from the 'show' command, which isn't correct for $_gdb_maint_setting, in this case I need to use a setting from 'maintenance show'. This same issue is present for $_gdb_maint_setting_str. This commit fixes this minor issue. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-05-01gdb: move struct ui and related things to ui.{c,h}Simon Marchi3-0/+3
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_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-28gdb: make deprecated_show_value_hack staticAndrew Burgess1-1/+1
The deprecated_show_value_hack function is now only used inside cli-setshow.c, so lets make the function static to discourage its use anywhere else. There should be no user visible changes after this commit Reviewed-By: Tom Tromey <tom@tromey.com>
2023-04-24gdb: remove end_stepping_range observableSimon Marchi1-17/+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
2023-04-02gdb: remove unused parameters in print_doc_of_command, apropos_cmdSimon Marchi3-11/+9
I noticed the prefix parameter was unused in print_doc_of_command. And when removing it, it becomes unused in apropos_cmd. Change-Id: Id72980b03fe091b22931e6b85945f412b274ed5e
2023-03-09gdb, gdbserver, gdbsupport: fix whitespace issuesSimon Marchi1-4/+4
Replace spaces with tabs in a bunch of places. Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
2023-02-15Add new "$_shell(CMD)" internal functionPedro Alves1-4/+92
For testing a following patch, I wanted a way to send a SIGINT to GDB from a breakpoint condition. And I didn't want to do it from a Python breakpoint or Python function, as I wanted to exercise non-Python code paths. So I thought I'd add a new $_shell internal function, that runs a command under the shell, and returns the exit code. With this, I could write: (gdb) b foo if $_shell("kill -SIGINT $gdb_pid") != 0 || <other condition> I think this is generally useful, hence I'm proposing it here. Here's the new function in action: (gdb) p $_shell("true") $1 = 0 (gdb) p $_shell("false") $2 = 1 (gdb) p $_shell("echo hello") hello $3 = 0 (gdb) p $_shell("foobar") bash: line 1: foobar: command not found $4 = 127 (gdb) help function _shell $_shell - execute a shell command and returns the result. Usage: $_shell (command) Returns the command's exit code: zero on success, non-zero otherwise. (gdb) NEWS and manual changes included. Approved-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Eli Zaretskii <eliz@gnu.org> Change-Id: I7e36d451ee6b428cbf41fded415ae2d6b4efaa4e
2023-02-13Remove deprecated_lval_hackTom Tromey1-1/+1
This removes deprecated_lval_hack and the VALUE_LVAL macro, replacing all uses with a call to value::lval. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn remaining value_contents functions into methodsTom Tromey2-3/+3
This turns the remaining value_contents functions -- value_contents, value_contents_all, value_contents_for_printing, and value_contents_for_printing_const -- into methods of value. It also converts the static functions require_not_optimized_out and require_available to be private methods. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_value into a static "constructor"Tom Tromey1-1/+1
This changes allocate_value to be a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_address and set_value_address functions into methodsTom Tromey1-1/+1
This changes the value_address and set_value_address functions to be methods of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_type into methodTom Tromey3-5/+5
This changes value_type to be a method of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-08Simplify interp::exec / interp_exec - let exceptions propagatePedro Alves1-35/+14
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-19GDB: Allow arbitrary keywords in integer set commandsMaciej W. Rozycki6-284/+521
Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-18GDB: Add references to erased args in cli-decode.cMaciej W. Rozycki1-11/+6
Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct within cmd_list_element") and commit 702991711a91 ("gdb: Have setter and getter callbacks for settings") and update inline documentation accordingly for `add_set_or_show_cmd' and `add_setshow_cmd_full_erased', documenting the `args' parameter and removing references to `var', `set_setting_func' and `get_setting_func'. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-18GDB: Add missing inline documentation for `add_setshow_cmd_full'Maciej W. Rozycki1-0/+12
Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct within cmd_list_element") and add missing description for `add_setshow_cmd_full'.
2023-01-18GDB: Correct inline documentation for `add_setshow_cmd_full_erased'Maciej W. Rozycki1-1/+1
Use proper English in the description of SET_LIST and SHOW_LIST.
2023-01-18GDB: Fix documentation for `theclass' parameters in cli-decode.cMaciej W. Rozycki1-11/+11
Rename CLASS to THECLASS in the documentation for `theclass' parameters throughout cli-decode.c, complementing commit fe978cb071b4 ("C++ keyword cleanliness, mostly auto-generated"). Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker18-18/+18
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-12-15gdb: remove static buffer in command_line_inputSimon Marchi2-10/+20
[I sent this earlier today, but I don't see it in the archives. Resending it through a different computer / SMTP.] The use of the static buffer in command_line_input is becoming problematic, as explained here [1]. In short, with this patch [2] that attempt to fix a post-hook bug, when running gdb.base/commands.exp, we hit a case where we read a "define" command line from a script file using command_command_line_input. The command line is stored in command_line_input's static buffer. Inside the define command's execution, we read the lines inside the define using command_line_input, which overwrites the define command, in command_line_input's static buffer. After the execution of the define command, execute_command does a command look up to see if a post-hook is registered. For that, it uses a now stale pointer that used to point to the define command, in the static buffer, causing a use-after-free. Note that the pointer in execute_command points to the dynamically-allocated buffer help by the static buffer in command_line_input, not to the static object itself, hence why we see a use-after-free. Fix that by removing the static buffer. I initially changed command_line_input and other related functions to return an std::string, which is the obvious but naive solution. The thing is that some callees don't need to return an allocated string, so this this an unnecessary pessimization. I changed it to passing in a reference to an std::string buffer, which the callee can use if it needs to return dynamically-allocated content. It fills the buffer and returns a pointers to the C string inside. The callees that don't need to return dynamically-allocated content simply don't use it. So, it started with modifying command_line_input as described above, all the other changes derive directly from that. One slightly shady thing is in handle_line_of_input, where we now pass a pointer to an std::string's internal buffer to readline's history_value function, which takes a `char *`. I'm pretty sure that this function does not modify the input string, because I was able to change it (with enough massaging) to take a `const char *`. A subtle change is that we now clear a UI's line buffer using a SCOPE_EXIT in command_line_handler, after executing the command. This was previously done by this line in handle_line_of_input: /* We have a complete command line now. Prepare for the next command, but leave ownership of memory to the buffer . */ cmd_line_buffer->used_size = 0; I think the new way is clearer. [1] https://inbox.sourceware.org/gdb-patches/becb8438-81ef-8ad8-cc42-fcbfaea8cddd@simark.ca/ [2] https://inbox.sourceware.org/gdb-patches/20221213112241.621889-1-jan.vrany@labware.com/ Change-Id: I8fc89b1c69870c7fc7ad9c1705724bd493596300 Reviewed-By: Tom Tromey <tom@tromey.com>
2022-11-30Rename fields of cli_interp_base::saved_output_filesTom Tromey2-11/+14
This renames the fields of cli_interp_base::saved_output_files, as requested by Simon. I tried to choose names that more obviously reflect what the field is used for. I also added a couple of comments. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-28Don't let gdb_stdlog use pagerTom Tromey2-10/+15
When using the "set logging" commands, cli_interp_base::set_logging will send gdb_stdlog output (among others) to the tee it makes for gdb_stdout. However, this has the side effect of also causing logging to use the pager. This is PR gdb/29787. This patch fixes the problem by keeping stderr and stdlog separate from stdout, preserving the rule that only gdb_stdout should page. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29787
2022-11-28Don't let tee_file own a streamTom Tromey2-5/+7
Right now, tee_file owns the second stream it writes to. This is done for the convenience of the users. In a subsequent patch, this will no longer be convenient, so this patch moves the responsibility for ownership to the users of tee_file.
2022-11-28Remove 'saved_output' globalTom Tromey2-30/+33
CLI redirect uses a global variable, 'saved_output'. However, globals are generally bad, and there is no need for this one -- it can be a member of cli_interp_base. This patch makes this change.
2022-11-28Fix crash in "document" commandTom Tromey1-0/+2
PR cli/29800 points out that "document" will now crash when the argument is an undefined command. This is a regression due to the "document user-defined aliases" patch. Approved-By: Joel Brobecker <brobecker@adacore.com> Reviewed-By: Philippe Waroquiers <philippe.waroquiers@skynet.be> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29800
2022-11-17Remove two obsolete declarationsTom Tromey1-4/+0
I happened to find a couple of obsolete declarations in cli-interp.h. This patch removes them. Tested by rebuilding.
2022-11-16gdb: add "set style tui-current-position on|off", default to offPedro Alves1-2/+2
As discussed at: https://sourceware.org/pipermail/gdb-patches/2020-June/169519.html this patch disables source and assembly code highlighting for the text highlighted by the TUI's current position indicator, and adds a command to enable it back.
2022-11-08[gdb/cli] Make quit really quit after remote connection closedTom de Vries1-1/+14
Consider a hello world a.out, started using gdbserver: ... $ gdbserver --once 127.0.0.1:2345 ./a.out Process ./a.out created; pid = 15743 Listening on port 2345 ... that we can connect to using gdb: ... $ gdb -ex "target remote 127.0.0.1:2345" Remote debugging using 127.0.0.1:2345 Reading /home/vries/a.out from remote target... ... 0x00007ffff7dd4550 in _start () from target:/lib64/ld-linux-x86-64.so.2 (gdb) ... After that, we can for instance quit with confirmation: ... (gdb) quit A debugging session is active. Inferior 1 [process 16691] will be killed. Quit anyway? (y or n) y $ ... Or, kill with confirmation and quit: ... (gdb) kill Kill the program being debugged? (y or n) y [Inferior 1 (process 16829) killed] (gdb) quit $ ... Or, monitor exit, kill with confirmation, and quit: ... (gdb) monitor exit (gdb) kill Kill the program being debugged? (y or n) y Remote connection closed (gdb) quit $ ... But when doing monitor exit followed by quit with confirmation, we get the gdb prompt back, requiring us to do quit once more: ... (gdb) monitor exit (gdb) quit A debugging session is active. Inferior 1 [process 16944] will be killed. Quit anyway? (y or n) y Remote connection closed (gdb) quit $ ... So, the first quit didn't quit. This happens as follows: - quit_command calls query_if_trace_running - a TARGET_CLOSE_ERROR is thrown - it's caught in remote_target::get_trace_status, but then rethrown because it's TARGET_CLOSE_ERROR - catch_command_errors catches the error, at which point the quit command has been aborted. The TARGET_CLOSE_ERROR is defined as: ... /* Target throwing an error has been closed. Current command should be aborted as the inferior state is no longer valid. */ TARGET_CLOSE_ERROR, ... so in a way this is expected behaviour. But aborting quit because the inferior state (which we've already confirmed we're not interested in) is no longer valid, and having to type quit again seems pointless. Furthermore, the purpose of not catching errors thrown by query_if_trace_running as per commit 2f9d54cfcef ("make -gdb-exit call disconnect_tracing too, and don't lose history if the target errors on "quit""), was to make sure that error (_("Not confirmed.") had effect. Fix this in quit_command by catching only the TARGET_CLOSE_ERROR exception during query_if_trace_running and reporting it: ... (gdb) monitor exit (gdb) quit A debugging session is active. Inferior 1 [process 19219] will be killed. Quit anyway? (y or n) y Remote connection closed $ ... Tested on x86_64-linux. PR server/15746 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15746 Approved-By: Tom Tromey <tom@tromey.com>
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-2/+2
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-14Use scoped_value_mark in more placesTom Tromey1-16/+16
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-1/+1
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-02gdb: disassembler opcode display formattingAndrew Burgess1-0/+6
This commit changes the format of 'disassemble /r' to match GNU objdump. Specifically, GDB will now display the instruction bytes in as 'objdump --wide --disassemble' does. Here is an example for RISC-V before this patch: (gdb) disassemble /r 0x0001018e,0x0001019e Dump of assembler code from 0x1018e to 0x1019e: 0x0001018e <call_me+66>: 03 26 84 fe lw a2,-24(s0) 0x00010192 <call_me+70>: 83 25 c4 fe lw a1,-20(s0) 0x00010196 <call_me+74>: 61 65 lui a0,0x18 0x00010198 <call_me+76>: 13 05 85 6a addi a0,a0,1704 0x0001019c <call_me+80>: f1 22 jal 0x10368 <printf> End of assembler dump. And here's an example after this patch: (gdb) disassemble /r 0x0001018e,0x0001019e Dump of assembler code from 0x1018e to 0x1019e: 0x0001018e <call_me+66>: fe842603 lw a2,-24(s0) 0x00010192 <call_me+70>: fec42583 lw a1,-20(s0) 0x00010196 <call_me+74>: 6561 lui a0,0x18 0x00010198 <call_me+76>: 6a850513 addi a0,a0,1704 0x0001019c <call_me+80>: 22f1 jal 0x10368 <printf> End of assembler dump. There are two differences here. First, the instruction bytes after the patch are grouped based on the size of the instruction, and are byte-swapped to little-endian order. Second, after the patch, GDB now uses the bytes-per-line hint from libopcodes to add whitespace padding after the opcode bytes, this means that in most cases the instructions are nicely aligned. It is still possible for a very long instruction to intrude into the disassembled text space. The next example is x86-64, before the patch: (gdb) disassemble /r main Dump of assembler code for function main: 0x0000000000401106 <+0>: 55 push %rbp 0x0000000000401107 <+1>: 48 89 e5 mov %rsp,%rbp 0x000000000040110a <+4>: c7 87 d8 00 00 00 01 00 00 00 movl $0x1,0xd8(%rdi) 0x0000000000401114 <+14>: b8 00 00 00 00 mov $0x0,%eax 0x0000000000401119 <+19>: 5d pop %rbp 0x000000000040111a <+20>: c3 ret End of assembler dump. And after the patch: (gdb) disassemble /r main Dump of assembler code for function main: 0x0000000000401106 <+0>: 55 push %rbp 0x0000000000401107 <+1>: 48 89 e5 mov %rsp,%rbp 0x000000000040110a <+4>: c7 87 d8 00 00 00 01 00 00 00 movl $0x1,0xd8(%rdi) 0x0000000000401114 <+14>: b8 00 00 00 00 mov $0x0,%eax 0x0000000000401119 <+19>: 5d pop %rbp 0x000000000040111a <+20>: c3 ret End of assembler dump. Most instructions are aligned, except for the very long instruction. Notice too that for x86-64 libopcodes doesn't request that GDB group the instruction bytes. This matches the behaviour of objdump. In case the user really wants the old behaviour, I have added a new modifier 'disassemble /b', this displays the instruction byte at a time. For x86-64, which never groups instruction bytes, /b and /r are equivalent, but for RISC-V, using /b gets the old layout back (except that the whitespace for alignment is still present). Consider our original RISC-V example, this time using /b: (gdb) disassemble /b 0x0001018e,0x0001019e Dump of assembler code from 0x1018e to 0x1019e: 0x0001018e <call_me+66>: 03 26 84 fe lw a2,-24(s0) 0x00010192 <call_me+70>: 83 25 c4 fe lw a1,-20(s0) 0x00010196 <call_me+74>: 61 65 lui a0,0x18 0x00010198 <call_me+76>: 13 05 85 6a addi a0,a0,1704 0x0001019c <call_me+80>: f1 22 jal 0x10368 <printf> End of assembler dump. Obviously, this patch is a potentially significant change to the behaviour or /r. I could have added /b with the new behaviour and left /r alone. However, personally, I feel the new behaviour is significantly better than the old, hence, I made /r be what I consider the "better" behaviour. The reason I prefer the new behaviour is that, when I use /r, I almost always want to manually decode the instruction for some reason, and having the bytes displayed in "instruction order" rather than memory order, just makes this easier. The 'record instruction-history' command also takes a /r modifier, and has been modified in the same way as disassemble; /r gets the new behaviour, and /b has been added to retain the old behaviour. Finally, the MI command -data-disassemble, is unchanged in behaviour, this command now requests the raw bytes of the instruction, which is equivalent to the /b modifier. This means that the MI output will remain backward compatible.
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-25Allow to document user-defined aliases.Philippe Waroquiers2-31/+69
Compared to the previous version, this version fixes the comments reported by Tom Tromey and ensures that the 'help some-user-documented-alias' shows the alias definition to ensure the user understands this is an alias even if specifically documented. When using 'help ALIASNAME', GDB shows the help of the aliased command. This is a good default behaviour. However, GDB alias command allows to define aliases with arguments possibly changing or tuning significantly the behaviour of the aliased command. In such a case, showing the help of the aliased command might not be ideal. This is particularly true when defining an alias as a set of nested 'with' followed by a last command to launch, such as: (gdb) alias pp10 = with print pretty -- with print elements 10 -- print Asking 'help pp10' shows the help of the 'with' command, which is not particularly useful: (gdb) help pp10 with, pp10, w alias pp10 = with print pretty -- with print elements 10 -- print Temporarily set SETTING to VALUE, run COMMAND, and restore SETTING. Usage: with SETTING [VALUE] [-- COMMAND] .... Such an alias can now be documented by the user: (gdb) document pp10 >Pretty printing an expressiong, printing 10 elements. >Usage: pp10 [PRINT-COMMAND-OPTIONS] EXP >See 'help print' for more information. >end (gdb) help pp10 alias pp10 = with print pretty -- with print elements 10 -- print Pretty printing an expressiong, printing 10 elements. Usage: pp10 [PRINT-COMMAND-OPTIONS] EXP See 'help print' for more information. (gdb) When a user-defined alias is documented specifically, help and apropos use the provided alias documentation instead of the documentation of the aliased command. Such a documented alias is also not shown anymore in the help of the aliased command, and the alias is not listed anymore in the help of the aliased command. In particular for cases such as pp10 example above, indicating that pp10 is an alias of the 'with' command is confusing.
2022-08-19Remove two initialization functionsTom Tromey2-9/+1
I noticed a couple of initialization functions that aren't really needed, and that currently require explicit calls in gdb_init. This patch removes these functions, simplifying gdb a little. Regression tested on x86-64 Fedora 34.
generated by cgit v1.1 at 2024-09-13 03:26:09 +0000