aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
5 hoursgdb: fix --args handling when inferior argument have dashHEADmasterAndrew Burgess1-0/+13
After the commit: commit e5e76451fa82e0bc00599af96382b361c3d6ac32 Date: Fri Oct 22 07:19:29 2021 +0000 gdb/gdbserver: add a '--no-escape-args' command line option Inferior argument handling on the GDB command line was broken: $ gdb --args /bin/ls --foo ./gdb/gdb: unrecognized option '--foo' ./gdb/gdb: `--args' specified but no program specified Before the above patch the definition of the '--args' argument in the long_options array (in captured_main_1) was such that the getopt_long_only call would directly set the 'set_args' variable to true if '--args' was seen. This meant that, immediately after the getopt_long_only call, we could inspect set_args and break out of the argument processing loop if needed. After the above patch '--args' (and the new '--no-escape-args') no longer set set_args directly via the getopt_long_only call. Instead the getopt_long_only call returns an OPT_* enum value, which we then use in the following switch statement in order to set the set_args variable. What this means is that, immediately after the getopt_long_only call, set_args no longer (immediately) indicates if --args was seen. After the switch statement, when set_args has been updated, we go around the argument processing loop again and call getopt_long_only once more. This extra getopt_long_only call will, if it finds another argument that starts with a dash, update the global optind to point to this option. At this point things have gone wrong, GDB has now lost track of the argument containing the program name the user wanted us to start. This leads to GDB exiting with the above error. The solution is to move the check of set_args to either before the getopt_long_only call, or to after the switch statement. I chose to move it earlier as this keeps all the loop exiting checks near the beginning. I've added more tests that cover this issue. Approved-By: Luis Machado <luis.machado.foss@gmail.com> Tested-By: Luis Machado <luis.machado.foss@gmail.com>
9 hours[gdb/testsuite, tclint] Fix gdb.adaTom de Vries17-28/+28
Running tclint on the test-cases in gdb.ada shows a few problems. Fix these. Tested on x86_64-linux.
9 hours[gdb/testsuite, tclint] Fix gdb.asmTom de Vries1-15/+15
Running tclint on the test-cases in gdb.asm shows a few problems. Fix these. Tested on x86_64-linux.
9 hours[gdb/testsuite, tclint] Fix gdb.disasmTom de Vries2-7/+7
Running tclint on the test-cases in gdb.disasm shows a few problems. Fix these. Tested on x86_64-linux.
9 hours[gdb/testsuite, tclint] Fix gdb.goTom de Vries4-6/+6
Running tclint on the test-cases in gdb.go shows a few problems. Fix these. Tested on x86_64-linux.
9 hours[gdb/testsuite, tclint] Fix gdb.gdbTom de Vries2-6/+6
Running tclint on the test-cases in gdb.gdb shows a few problems. Fix these. Tested on x86_64-linux.
9 hours[gdb/testsuite, tclint] Fix gdb.dlangTom de Vries4-4/+4
Running tclint on the test-cases in gdb.dlang shows a few problems. Fix these. Tested on x86_64-linux.
9 hours[gdb/testsuite, tclint] Fix gdb.ctfTom de Vries1-3/+3
Running tclint on the test-cases in gdb.ctf shows a few problems. Fix these. Tested on x86_64-linux.
9 hours[gdb/testsuite, tclint] Fix gdb.server some moreTom de Vries1-2/+2
Running tclint on the test-cases in gdb.server shows a few problems. Fix these. Tested on x86_64-linux.
9 hours[gdb/testsuite, tclint] Fix gdb.debuginfodTom de Vries1-2/+2
Running tclint on the test-cases in gdb.debuginfod shows a few problems. Fix these. Tested on x86_64-linux.
9 hours[gdb/testsuite, tclint] Fix gdb.linespecTom de Vries7-9/+9
Running tclint on the test-cases in gdb.linespec shows a few problems. Fix these. Tested on x86_64-linux.
9 hours[gdb/testsuite, tclint] Fix gdb.multiTom de Vries5-12/+12
Running tclint on the test-cases in gdb.multi shows a few problems. Fix these. Tested on x86_64-linux.
18 hours[gdb/testsuite] Remove more uses of "eval"Tom de Vries6-11/+10
Remove some more uses of the Tcl "eval" proc. In most cases the {*} "splat" expansion is used instead. The exceptions are: - gdb.base/inferior-args.exp where we rewrite: set cmd [format "lappend item \{ '%c' '\\%c' \}" 34 34] eval $cmd into: lappend item [format { '%c' '\%c' } 34 34] - reset_vars in lib/check-test-names.exp where we simply drop an unnecessary eval Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
23 hoursTreat attributes as code in DWARF assemblerTom Tromey186-4200/+4281
The DWARF assembler treats the 'children' of a DIE as plain Tcl code, evaluating it in the parent context. I don't recall why, but when I wrote this code, I didn't do the same thing for the attributes. Instead, there I implemented a special syntax. I was looking at this today and wondered why I didn't just use ordinary evaluation as well. This patch implements this idea. Attributes are now evaluated as plain code. This is a bit less "magical", is slightly shorter due to lack of braces, and most importantly now allows comments in the attributes section. Note that some [subst {}] calls had to be added. This could be fixed by changing DWARF expressions to also be plain Tcl code. I think that would be a good idea, but I didn't want to tack it on here. This patch requires the full ("DW_AT_...") name for attributes. I did this to avoid any possibility of name clashes. I've long considered that my original decision to allow short names for tags and attributes was a mistake. It's worth noting that many existing tests already used the long names here. Most of this patch was written by script. The main changes are in dwarf.exp, but as noted, there were some minor fixups needed in some tests. Also, after committing, 'git show' indicated some whitespace issues, so I've gone through and "tabified" some things, which is why the patch might be otherwise larger than it should be. (This was discussed a bit during the v1 submission.) v1 was here: https://inbox.sourceware.org/gdb-patches/20250530183845.2179955-1-tromey@adacore.com/ In v2 I've rebased and fixed up various tests that either changed or were added since v1. Regression tested on x86-64 Fedora 41. Approved-By: Simon Marchi <simon.marchi@efficios.com>
27 hoursFix gdb.base/gcorebg.exp and --program-prefixPedro Alves1-2/+2
When GDB is configured with --program-prefix, we see: Running /home/pedro/gdb/src/gdb/testsuite/gdb.base/gcorebg.exp ... FAIL: gdb.base/gcorebg.exp: detached=detached: Spawned gcore finished FAIL: gdb.base/gcorebg.exp: detached=detached: Core file generated by gcore FAIL: gdb.base/gcorebg.exp: detached=standard: Spawned gcore finished FAIL: gdb.base/gcorebg.exp: detached=standard: Core file generated by gcore The problem is here (with --program-prefix=prefix-), from gdb.log: gcore: GDB binary (/home/pedro/gdb/build-program-prefix/gdb/testsuite/../../gdb/prefix-gdb) not found FAIL: gdb.base/gcorebg.exp: detached=detached: Spawned gcore finished That is gcore (the script, not the GDB command) trying to run the installed GDB: if [ ! -f "$binary_path/@GDB_TRANSFORM_NAME@" ]; then echo "gcore: GDB binary (${binary_path}/@GDB_TRANSFORM_NAME@) not found" exit 1 fi ... "$binary_path/@GDB_TRANSFORM_NAME@" </dev/null \ ... When running the testsuite with the just-built GDB, the GDB binary is 'gdb', not @GDB_TRANSFORM_NAME@. Fix this by adding a new '-g gdb" option to the 'gcore' script, that lets you override the GDB binary gcore runs, and then making gdb.base/gcorebg.exp pass it to gcore. The GDB binary we're testing is always in the $GDB global. This is similar to how it is already possible to specify GDB's data directory with an option to gcore, and then gdb.base/gcorebg.exp uses it. NEWS and documentation changes included. Approved-by: Kevin Buettner <kevinb@redhat.com> Change-Id: I6c60fba8768618eeba8d8d03b131dc756b57ee78
27 hoursFix nested gdb_caching_proc with argsPedro Alves3-25/+21
Commit d09eba07 ("Make get_compiler_info use gdb_caching_proc") regressed some tests when you run them in isolation (as this depends on the order the gdb_caching_proc procs' results are cached). E.g.: Running /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp ... ERROR: tcl error sourcing /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp. ERROR: tcl error code TCL WRONGARGS ERROR: wrong # args: should be "gdb_real__get_compiler_info_1 language" while executing "gdb_real__get_compiler_info_1" ("uplevel" body line 1) invoked from within "uplevel 2 $real_name" (procedure "gdb_do_cache_wrap" line 3) invoked from within "gdb_do_cache_wrap $real_name {*}$args" (procedure "gdb_do_cache" line 98) invoked from within gdb.base/attach.exp triggers it too, for example. This is actually a latent problem in gdb_do_cache_wrap, introduced in: commit 71f1ab80f1aabd70bce526635f84c7b849e8a0f4 CommitDate: Mon Mar 6 16:49:19 2023 +0100 [gdb/testsuite] Allow args in gdb_caching_proc This change: # Call proc real_name and return the result, while ignoring calls to pass. -proc gdb_do_cache_wrap {real_name} { +proc gdb_do_cache_wrap {real_name args} { if { [info procs save_pass] != "" } { return [uplevel 2 $real_name] <<<<<<<<<<<<<<<<<<<<<<< HERE } @@ -31,7 +31,7 @@ proc gdb_do_cache_wrap {real_name} { rename pass save_pass rename ignore_pass pass - set code [catch {uplevel 2 $real_name} result] + set code [catch {uplevel 2 [list $real_name {*}$args]} result] Missed updating the line marked with HERE above, to pass down $args. So the case of a caching proc calling another caching proc with args isn't handled correctly. We could fix this by fixing the HERE line like so: - return [uplevel 2 $real_name] + return [uplevel 2 [list $real_name {*}$args]] However, we have with_override nowadays that we can use here which eliminates the duplicated logic, which was what was missed originally. A new test that exposes the problem is added to gdb.testsuite/gdb-caching-proc.exp. This also adds a new test to gdb.testsuite/with-override.exp that I think was missing, making sure that the inner foo override restores the outer foo override. Tested-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I8b2a7366bf910902fe5f547bde58c3b475bf5133
43 hoursMake get_compiler_info use gdb_caching_procPedro Alves2-34/+24
While running tests on Windows with: $ make check-parallel RUNTESTFLAGS="-v" I noticed that get_compiler_info was invoking the compiler over and over for each testcase, even though the result is supposed to be cached. This isn't normally very visible in gdb.log, because we suppress it there: # Run $ifile through the right preprocessor. # Toggle gdb.log to keep the compiler output out of the log. set saved_log [log_file -info] log_file ... I'm not sure it's a good idea to do that suppression, BTW. I was very confused when I couldn't find the compiler invocation in gdb.log, and it took me a while to notice that code. The reason get_compiler_info in parallel mode isn't hitting the cache is that in that mode each testcase runs under its own expect/dejagnu process, and the way get_compiler_info caches results currently doesn't handle that -- the result is simply cached in a global variable, which is private to each expect. So improve this by switching get_compiler_info's caching mechanism to gdb_caching_proc instead, so that results are cached across parallel invocations of dejagnu. On an x86-64 GNU/Linux run with "make check-parallel -j32", before the patch I get 2223 calls to get_compiler_info that result in a compiler invocation. After the patch, I get 7. On GNU/Linux, those compiler invocations don't cost much, but on Windows, they add up. On my machine each invocation takes around 500ms to 700ms. Here is one representative run: $ time x86_64-w64-mingw32-gcc \ /c/msys2/home/alves/gdb/build-testsuite/temp/14826/compiler.c \ -fdiagnostics-color=never -E ... real 0m0.639s user 0m0.061s sys 0m0.141s This reference to a 'compiler_info' global: # N.B. compiler_info is intended to be local to this file. # Call test_compiler_info with no arguments to fetch its value. # Yes, this is counterintuitive when there's get_compiler_info, # but that's the current API. if [info exists compiler_info] { unset compiler_info } is outdated, even before this patch, as "compiler_info" is a local variable in get_compiler_info. Remove all that code. Since test_compiler_info now calls get_compiler_info directly, the "Requires get_compiler_info" comments in skip_inline_frame_tests and skip_inline_var_tests are no longer accurate. Remove them. test_compiler_info's intro comment is also outdated; improve it. Changing the return value of get_compiler_info to be the 'compiler_info' string directly instead of 0/-1 was simpler. It would be possible to support the current 0/-1 interface by making get_compiler_info_1 still return the 'compiler_info' string, and then having the get_compiler_info wrapper convert to 0/-1, and I considered doing that. But the only caller of get_compiler_info outside gdb.exp is gdb.python/py-event-load.exp, and it seems that one simply crossed wires with: commit 9704b8b4bc58f4f464961cca97d362fd33740ce8 gdb/testsuite: remove unneeded calls to get_compiler_info as the test as added at roughly the same time as that commit. So simply remove that call in gdb.python/py-event-load.exp, otherwise we get something like: ERROR: ------------------------------------------- ERROR: in testcase src/gdb/testsuite/gdb.python/py-event-load.exp ERROR: expected boolean value but got "gcc-13-3-0" ERROR: tcl error code TCL VALUE NUMBER ERROR: tcl error info: expected boolean value but got "gcc-13-3-0" Approved-By: Tom Tromey <tom@tromey.com> Change-Id: Ia3d3dc34f7cdcf9a2013f1054128c62a108eabfb
3 daysRemove uses of "eval" from gdb testsuiteTom Tromey22-56/+53
This patch removes a lot of uses of the Tcl "eval" proc from the gdb test suite. In most cases the {*} "splat" expansion is used instead. A few uses of eval remain, primarily ones that were more complicated to untangle. In a couple of tests I also replaced some ad hoc code with string_to_regexp. Tested on x86-64 Fedora 40. Reviewed-By: Tom de Vries <tdevries@suse.de>
3 daysgdb: improve show text and help text for 'remote exec-file'Andrew Burgess2-3/+6
The current behaviour for 'show remote exec-file' is this: (gdb) show remote exec-file (gdb) set remote exec-file /abc (gdb) show remote exec-file /abc (gdb) The first output, the blank line, is just GDB showing the default empty value. This output is not really inline with GDB's more full sentence style output, so in this commit I've updated things, the output is now: (gdb) show remote exec-file The remote exec-file is unset, the default remote executable will be used. (gdb) set remote exec-file /abc (gdb) show remote exec-file The remote exec-file is "/abc". (gdb) Which I think is more helpful to the user. I have also updated the help text for this setting. Previously we had a set/show header line, but no body text, now we have: (gdb) help show remote exec-file Show the remote file name for starting inferiors. This is the file name, on the remote target, used when starting an inferior, for example with the \"run\", \"start\", or \"starti\" commands. This setting is only useful when debugging a remote target, otherwise, this setting is not used. (gdb) Which I think is more helpful. Reviewed-By: Mark Wielaard <mark@klomp.org> Tested-By: Mark Wielaard <mark@klomp.org> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
3 daysgdb: improve how 'remote exec-file' is stored and accessedAndrew Burgess1-0/+13
This commit makes two related changes. The goal of the commit is to update the 'remote exec-file' setting to work correctly in a multi-inferior setup. To do this I have switched from the older style add_setshow_* function, which uses a single backing variable, to the newer style add_setshow_* functions that uses a get/set callback. The get/set callbacks now directly access the state held in the progspace which ensures that the correct value is always returned. However, the new get/set API requires that the get callback return a reference to the setting's value, which in this case needs to be a std::string. Currently the 'remote exec-file' setting is stored as a 'char *' string, which isn't going to work. And so, this commit also changes 'remote exec-file' to be stored as a std::string within the progspace. Now, when switching between multiple inferiors, GDB can correctly inform the user about the value of the 'remote exec-file' setting. Approved-By: Tom Tromey <tom@tromey.com>
4 days[gdb/testsuite] Fix test names in gdb.tui/{empty,new-layout}.expTom de Vries2-2/+2
Post-commit review [1] pointed out that this change in gdb.tui/empty.exp: ... - eval Term::check_box [list "box $boxno"] $box + Term::check_box [list "box $boxno"] {*}$box ... is incomplete because it leaves the "[list ...]" in place. Indeed, it changes the test name like this: ... -PASS: gdb.tui/empty.exp: src: 80x24: box 1 +PASS: gdb.tui/empty.exp: src: 80x24: {box 1} ... Fix this by dropping the "[list ...]". Likewise in gdb.tui/new-layout.exp. [1] https://sourceware.org/pipermail/gdb-patches/2025-September/220863.html
5 daysgdb, gdbserver: fix typosSimon Marchi1-2/+2
Found by the codespell pre-commit hook. Change-Id: Iafadd9485ce334c069dc8dbdab88ac3fb5fba674
5 daysFix 32-bit failure in array_long_idx.expTom Tromey1-1/+4
Testing on the AdaCore-internal equivalent to array_long_idx.exp showed that it failed on 32-bit targets. This patch fixes the problem by arranging to use types that aren't target-dependent.
5 daysgdb: clear proceed status before starting a new inferiorAndrew Burgess1-0/+109
This patch fixes a bug when 'set schedule-multiple on' is in use and a second inferior is started using the 'run' command (or 'start' or 'starti'). This bug was reported as PR gdb/28777. The problem appears as the first inferior terminating with an unexpected SIGTRAP. The bug can be reproduced like this: gdb -ex 'set schedule-multiple on' \ -ex 'file /tmp/spin' \ -ex 'break main' \ -ex 'run' \ -ex 'add-inferior' \ -ex 'inferior 2' \ -ex 'file /tmp/spin' \ -ex 'break main' \ -ex 'run' The final 'run' can be replaced with 'start' or 'starti'. The output is different in the 'starti' case, but the cause is the same. For the 'run' and 'start' cases the final output is: Starting program: /tmp/spin Program terminated with signal SIGTRAP, Trace/breakpoint trap. The program no longer exists. In the 'starti' case the output is: Starting program: /tmp/spin Thread 2.1 "spin" stopped. Cannot remove breakpoints because program is no longer writable. Further execution is probably impossible. 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 What's happening is that GDB is failing to clear the previous proceed status from inferior 1 before starting inferior 2. Normally when schedule-multiple is off, this isn't a problem as 'run' only starts the new inferior, and the new inferior will have no previous proceed status that needs clearing. But when schedule-multiple is on, starting a new inferior, with 'run' and friends, will actually start all inferiors, including those that previous stopped at a breakpoint with a SIGTRAP signal. By failing to clear out the proceed status for those threads, when GDB restarts inferior 1 it arranges for the thread to receive the SIGTRAP, which is delivered, and, as GDB isn't expecting a SIGTRAP, is allowed to kill the process. Fix this by calling clear_proceed_status from run_command_1. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28777
5 daysgdb: ensure thread state is updated when remote target starts upAndrew Burgess1-9/+0
This patch fixes a bug that was exposed by a test added in the previous commit. After writing this patch I also discovered that this issue had been reported as PR gdb/27322. When 'maint set target-non-stop on' is in effect, then the remote targets will be running in non-stop mode. The previous commit revealed a bug where, in this mode, GDB can fail to copy the thread state from the target to the GDB frontend, this leaves the thread marked as running in the frontend, even though the thread is actually stopped. When this happens the user is no longer able to interrupt the thread (it's already stopped), nor can the user resume the thread (GDB thinks the threads is running). To reproduce the bug: gdb -q -ex 'maint set target-non-stop on' \ -ex 'set non-stop off' \ -ex 'set sysroot' \ -ex 'file /bin/ls' \ -ex 'run &' \ -ex 'add-inferior' \ -ex 'infer 2' \ -ex 'set sysroot' \ -ex 'target remote | gdbserver - ls' \ -ex 'info threads' The 'info threads' output will look something like: Id Target Id Frame 1.1 process 1746383 "ls" (running) * 2.1 Thread 1746389.1746389 "ls" 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 The thread 1.1 should be stopped. GDB is running in all-stop mode after all. The problem is that in remote_target::process_initial_stop_replies, there is a call to stop_all_threads, however, the changes in the thread state are never copied back to the GDB frontend. This leaves the threads stopped, but still marked running. Solve this by adding a scoped_finish_thread_state. This is similar to how scoped_finish_thread_state is used in run_command_1 when we start a new inferior running. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27322
5 daysgdb: disable commit resumed in wait_for_inferiorAndrew Burgess2-0/+218
This patch proposes a fix for PR gdb/33147. The bug can be reproduced like this: gdb -q -ex 'file /bin/ls' \ -ex 'run &' \ -ex 'add-inferior' \ -ex 'infer 2' \ -ex 'set sysroot' \ -ex 'target remote | gdbserver - ls' Which will trigger an assertion failure: target.c:3760: internal-error: target_stop: Assertion `!proc_target->commit_resumed_state' failed. The problem is that target_stop is being called for a target when commit_resumed_state is true, the comment on process_stratum_target::commit_resumed_state is pretty clear: To simplify the implementation of targets, the following methods are guaranteed to be called with COMMIT_RESUMED_STATE set to false: - resume - stop - wait So clearly we're breaking a precondition of target_stop. In this example there are two target, the native target (inferior 1), and the remote target (inferior 2). It is the first, the native target, for which commit_resumed_state is set incorrectly. At the point target_stop is called looks like this: #11 0x00000000009a3c19 in target_stop (ptid=...) at ../../src/gdb/target.c:3760 #12 target_stop (ptid=...) at ../../src/gdb/target.c:3756 #13 0x00000000007042f2 in stop_all_threads (reason=<optimized out>, inf=<optimized out>) at ../../src/gdb/infrun.c:5739 #14 0x0000000000711d3a in wait_for_inferior (inf=0x2b90fd0) at ../../src/gdb/infrun.c:4412 #15 start_remote (from_tty=from_tty@entry=1) at ../../src/gdb/infrun.c:3829 #16 0x0000000000897014 in remote_target::start_remote_1 (this=this@entry=0x2c4a520, from_tty=from_tty@entry=1, extended_p=extended_p@entry=0) at ../../src/gdb/remote.c:5350 #17 0x00000000008976e7 in remote_target::start_remote (extended_p=0, from_tty=1, this=0x2c4a520) at ../../src/gdb/remote.c:5441 #18 remote_target::open_1 (name=<optimized out>, from_tty=1, extended_p=0) at ../../src/gdb/remote.c:6312 #19 0x00000000009a815f in open_target (args=0x7fffffffa93c "| gdbserver - ls", from_tty=1, command=<optimized out>) at ../../src/gdb/target.c:838 For new inferiors commit_resumed_state starts set to false, for this reason, if we only start a remote inferior, then when wait_for_inferior is called commit_resumed_state will be false, and everything will work. Further, as target_stop is only called for running threads, if, when the remote inferior is started, all other threads (in other targets) are already stopped, then GDB will never need to call target_stop for the other targets, and so GDB will not notice that commit_resumed_state for those target is set to true. In this case though, as the first (native) inferior is left running in the background while the remote inferior is created, and because GDB is running in all-stop mode (so needs to stop all threads in all targets), then GDB does call target_stop for the other targets, and so spots that commit_resumed_state is not set correctly and asserts. The fix is to add scoped_disable_commit_resumed somewhere in the call stack. Initially I planned to add the scoped_disable_commit_resumed in `wait_for_inferior`, however, this isn't good enough. This location would solve the problem as described in the bug, but when writing the test I extended the problem to also cover non-stop mode, and this runs into a second problem, the same assertion, but triggered from a different call path. For this new case the stack looks like this: #1 0x0000000000fb0e50 in target_stop (ptid=...) at ../../src/gdb/target.c:3771 #2 0x0000000000a7f0ae in stop_all_threads (reason=0x1d0ff74 "remote connect in all-stop", inf=0x0) at ../../src/gdb/infrun.c:5756 #3 0x0000000000d9c028 in remote_target::process_initial_stop_replies (this=0x3e10670, from_tty=1) at ../../src/gdb/remote.c:5017 #4 0x0000000000d9cdf0 in remote_target::start_remote_1 (this=0x3e10670, from_tty=1, extended_p=0) at ../../src/gdb/remote.c:5405 #5 0x0000000000d9d0d4 in remote_target::start_remote (this=0x3e10670, from_tty=1, extended_p=0) at ../../src/gdb/remote.c:5457 #6 0x0000000000d9e8ac in remote_target::open_1 (name=0x7fffffffa931 "| gdbserver - /bin/ls", from_tty=1, extended_p=0) at ../../src/gdb/remote.c:6329 #7 0x0000000000d9d167 in remote_target::open (name=0x7fffffffa931 "| gdbserver - /bin/ls", from_tty=1) at ../../src/gdb/remote.c:5479 #8 0x0000000000f9914d in open_target (args=0x7fffffffa931 "| gdbserver - /bin/ls", from_tty=1, command=0x35d1a40) at ../../src/gdb/target.c:838 So I'm now thinking that stop_all_threads would be the best place for the scoped_disable_commit_resumed. I did leave an assert in wait_for_inferior as, having thought about the assert some, I do still think the logic of it is true, and it doesn't hurt to leave it in place I think. However, it's not quite that simple, the test throws up yet another bug when we 'maint set target-non-stop on', but then 'set non-stop off'. This bug leaves a stopped thread marked as "(running)" in the 'info threads' output. I have a fix for this issue, but I'm leaving that for the next commit. For now I've just disabled part of the test in the problem case. I've also tagged this patch with PR gdb/27322. That bug was created before the above assert was added, but if you follow the steps to reproduce for that bug today you will hit the above assert. The actual issue described in PR gdb/27322 is fixed in the next patch. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27322 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33147
5 daysgdb: ensure normal stop finishes the thread state of all threadsAndrew Burgess2-0/+190
This patch fixes a multi-target issue where the normal_stop function can fail to finish the thread state of threads from a non current target, this leaves the threads marked as running in GDB core, while the threads is actually stopped. For testing I used this test program: #include <unistd.h> int main () { while (1) sleep (1); return 0; } Compile this to make '/tmp/spin', then the bug can be shown using this command: $ gdb -ex 'file /tmp/spin' \ -ex 'start' \ -ex 'add-inferior' \ -ex 'inferior 2' \ -ex 'set sysroot' \ -ex 'target extended-remote | gdbserver --multi --once - /tmp/spin' \ -ex 'inferior 1' \ -ex 'continue&' \ -ex 'inferior 2' \ -ex 'search sleep' \ -ex 'break $_ inferior 2' \ -ex 'continue' \ -ex 'info threads' The interesting part of the output is: Id Target Id Frame 1.1 process 1610445 "spin" (running) * 2.1 Thread 1610451.1610451 "spin" main () at spin.c:7 (gdb) Notice that thread 1.1 is marked as running when it should be stopped. We can see that the thread is actually stopped if we try this: (gdb) inferior 1 [Switching to inferior 1 [process 1610445] (/tmp/spin)] [Switching to thread 1.1 (process 1610445)](running) (gdb) continue Cannot execute this command while the selected thread is running. (gdb) interrupt (gdb) info threads Id Target Id Frame * 1.1 process 1610445 "spin" (running) 2.1 Thread 1610451.1610451 "spin" main () at spin.c:7 (gdb) We can see the expected behaviour if both inferiors run on the same target, like this: $ gdb -ex 'file /tmp/spin' \ -ex 'start' \ -ex 'add-inferior' \ -ex 'inferior 2' \ -ex 'file /tmp/spin' \ -ex 'start' \ -ex 'inferior 1' \ -ex 'continue&' \ -ex 'inferior 2' \ -ex 'search sleep' \ -ex 'break $_ inferior 2' \ -ex 'continue' \ -ex 'info threads' The 'info threads' from this series of commands looks like this: Id Target Id Frame 1.1 process 1611589 "spin" 0x00007ffff7e951e7 in nanosleep () from /lib64/libc.so.6 * 2.1 process 1611593 "spin" main () at spin.c:7 (gdb) Now both threads are stopped as we'd expect. The problem is in normal_stop. The scoped_finish_thread_state uses user_visible_resume_target to select the target(s) over which GDB will iterate to find the threads to update. The problem with this is that when the ptid_t is minus_one_ptid, meaning all threads, user_visible_resume_target only returns nullptr, meaning all targets, when sched_multi is true. This dependency on sched_multi makes sense when _resuming_ threads. If we are resuming all threads, then when sched_multi (the schedule-multiple setting) is off (the default), all threads actually means all threads in the current inferior only. When sched_multi is true (schedule-multiple is on) then this means all threads, from all inferiors, which means GDB needs to consider every target. However, when stopping an inferior in all-stop mode (non_stop is false), then GDB wants to stop all threads from all inferiors, regardless of the sched_multi setting. What this means is that, when 'non_stop' is false, then we should be passing nullptr as the target selection to scoped_finish_thread_state. My proposal is that we should stop using user_visible_resume_target in the normal_stop function for the target selection of the scoped_finish_thread_state, instead we should manually figure out the correct target value and pass this in. There is precedent for this in GDB, see run_command_1, where 'finish_target' is calculated directly within the function rather than using user_visible_resume_target. After this commit, when using two different targets (native and remote) as in my first example above, both threads will be correctly stopped.
5 days[gdb/testsuite] Remove use of then keyword some moreTom de Vries6-9/+9
Find uses of the then keyword: ... $ find gdb/testsuite/ -type f -name *.exp* | xargs grep "if.*then {" ... and remove them. See also commit d4c4542312c ("gdb/testsuite: remove use of then keyword from library files") and related commits. Tested on aarch64-linux.
5 days[gdb/testsuite, tclint] Fix gdb.objcTom de Vries1-1/+1
Running tclint on the test-cases in gdb.opt shows a problem. Fix it. Tested on aarch64-linux.
5 days[gdb/testsuite, tclint] Fix gdb.optTom de Vries3-3/+3
Running tclint on the test-cases in gdb.opt shows a few problems. Fix these. Tested on aarch64-linux.
5 days[gdb/testsuite, tclint] Fix gdb.pascalTom de Vries6-10/+10
Running tclint on the test-cases in gdb.pascal shows a few problems. Fix these. Tested on aarch64-linux.
5 days[gdb/testsuite, tclint] Fix gdb.rocmTom de Vries1-3/+3
Running tclint on the test-cases in gdb.rocm shows a few problems: ... precise-memory-multi-inferiors.exp:33:5: expected braced word or word \ without substitutions in argument interpreted as expr [command-args] precise-memory-multi-inferiors.exp:43:5: expected braced word or word \ without substitutions in argument interpreted as expr [command-args] precise-memory-multi-inferiors.exp:55:5: expected braced word or word \ without substitutions in argument interpreted as expr [command-args] ... Fix these. The gdb.rocm test-cases are unsupported for me, so I can't test this.
5 days[gdb/testsuite, tclint] Fix gdb.rustTom de Vries2-2/+2
Running tclint on the test-cases in gdb.rust shows a few problems: ... modules.exp:37:1: expected braced word or word without substitutions in \ argument interpreted as expr [command-args] traits.exp:28:13: expected braced word or word without substitutions in \ argument interpreted as script [command-args] ... Fix these. Tested on aarch64-linux.
5 days[gdb/testsuite, tclint] Fix gdb.serverTom de Vries8-8/+8
Running tclint on the test-cases in gdb.server shows a few problems: ... connect-with-no-symbol-file.exp:72:1: line has trailing whitespace \ [trailing-whitespace] exit-multiple-threads.exp:73:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] extended-remote-restart.exp:73:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] monitor-exit-quit.exp:73:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] reconnect-ctrl-c.exp:54:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] server-exec-info.exp:24:1: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] stop-reply-no-thread.exp:73:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] /stop-reply-no-thread-multi.exp:81:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] ... Fix these. Tested on aarch64-linux.
5 days[gdb/testsuite, tclint] Fix lib/tuiterm.expTom de Vries1-4/+4
Running tclint on lib/tuiterm.exp shows a few problems: ... $ tclint --ignore line-length gdb/testsuite/lib/tuiterm.exp tuiterm.exp:105:3: expression with substitutions should be enclosed by \ braces [unbraced-expr] tuiterm.exp:1576:28: unnecessary command substitution within expression \ [redundant-expr] tuiterm.exp:1582:25: unnecessary command substitution within expression \ [redundant-expr] ... Fix these. Tested on aarch64-linux.
5 days[gdb/testsuite, tclint] Fix gdb.tuiTom de Vries5-9/+9
Running tclint on the test-cases in gdb.tui shows a few problems: ... $ ( cd gdb/testsuite/gdb.tui; tclint --ignore line-length *.exp ) compact-source.exp:58:28: expression with substitutions should be enclosed by \ braces [unbraced-expr] compact-source.exp:60:27: expression with substitutions should be enclosed by \ braces [unbraced-expr] compact-source.exp:68:32: expression with substitutions should be enclosed by \ braces [unbraced-expr] empty.exp:68:2: eval received an argument with a substitution, unable to \ parse its arguments [command-args] new-layout.exp:84:2: eval received an argument with a substitution, unable \ to parse its arguments [command-args] source-search.exp:33:25: expression with substitutions should be enclosed by \ braces [unbraced-expr] wrap-line.exp:40:21: expression with substitutions should be enclosed by \ braces [unbraced-expr] wrap-line.exp:44:14: expression with substitutions should be enclosed by \ braces [unbraced-expr] wrap-line.exp:62:40: expression with substitutions should be enclosed by \ braces [unbraced-expr] ... Fix these. Tested on aarch64-linux.
5 daysgdb/gdbserver: pass inferior arguments as a single stringAndrew Burgess3-93/+183
GDB holds the inferior arguments as a single string. Currently when GDB needs to pass the inferior arguments to a remote target as part of a vRun packet, this is done by splitting the single argument string into its component arguments by calling gdb::remote_args::split, which uses the gdb_argv class to split the arguments for us. The same gdb_argv class is used when the user has asked GDB/gdbserver to start the inferior without first invoking a shell; the gdb_argv class is used to split the argument string into it component arguments, and each is passed as a separate argument to the execve call which spawns the inferior. There is however, a problem with using gdb_argv to split the arguments before passing them to a remote target. To understand this problem we must first understand how gdb_argv is used when invoking an inferior without a shell. And to understand how gdb_argv is used to start an inferior without a shell, I feel we need to first look at an example of starting an inferior with a shell. Consider these two cases: (a) (gdb) set args \$VAR (b) (gdb) set args $VAR When starting with a shell, in case (a) the user expects the inferior to receive a literal '$VAR' string as an argument, while in case (b) the user expects to see the shell expanded value of the variable $VAR. If the user does 'set startup-with-shell off', then in (a) GDB will strip the '\' while splitting the arguments, and the inferior will be passed a literal '$VAR'. In (b) there is no '\' to strip, so also in this case the inferior will receive a literal '$VAR', remember startup-with-shell is off, so there is no shell that can ever expand $VAR. Notice, that when startup-with-shell is off, we end up with a many to one mapping, both (a) and (b) result in the literal string $VAR being passed to the inferior. I think this is the correct behaviour in this case. However, as we use gdb_argv to split the remote arguments we have the same many to one mapping within the vRun packet. But the vRun packet will be used when startup-with-shell is both on and off. What this means is that when gdbserver receives a vRun packet containing '$VAR' it doesn't know if GDB actually had '$VAR', or if GDB had '\$VAR'. And this is a huge problem. We can address this by making the argument splitting for remote targets smarter, and I do have patches that try to do this in this series: https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com That series was pretty long, and wasn't getting reviewed, so I'm pulling the individual patches out and posting them separately. This patch doesn't try to improve remote argument splitting. I think that splitting and then joining the arguments is a mistake which can only introduce problems. The patch in the above series which tries to make the splitting and joining "smarter" handles unquoted, single quoted, and double quoted strings. But that doesn't really address parameter substitution, command substitution, or arithmetic expansion. And even if we did try to address these cases, what rules exactly would we implement? Probably POSIX shell rules, but what if the remote target doesn't have a POSIX shell? The only reason we're talking about which shell rules to follow is because the splitting and joining logic needs to mirror those rules. If we stop splitting and joining then we no longer need to care about the target's shell. Clearly, for backward compatibility we need to maintain some degree of argument splitting and joining as we currently have; and that's why I have a later patch (see the series above) that tries to improve that splitting and joining a little. But I think, what we should really do, is add a new feature flag (as used by the qSupported packet) and, if GDB and the remote target agree, we should pass the inferior arguments as a single string. This solves all our problems. In the startup with shell case, we no longer need to worry about splitting at all. The arguments are passed unmodified to the remote target, that can then pass the arguments to the shell directly. In the 'startup-with-shell off' case it is now up to the remote target to split the arguments, though in gdbserver we already did this, so nothing really changes in this case. And if the remote target doesn't have a POSIX shell, well GDB just doesn't need to worry about it! Something similar to this was originally suggested in this series: https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ though this series didn't try to maintain backward compatibility, which I think is an issue that my patch solves. Additionally, this series only passed the arguments as a single string in some cases, I've simplified this so that, when GDB and the remote agree, the arguments are always passed as a single string. I think this is a little cleaner. I've also added documentation and some tests with this commit, including ensuring that we test both the new single string approach, and the fallback split/join approach. I've credited the author of the referenced series as co-author as they did come to a similar conclusion, though I think my implementation is different enough that I'm happy to list myself as primary author. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Tested-By: Guinevere Larsen <guinevere@redhat.com> Approved-by: Kevin Buettner <kevinb@redhat.com>
5 daysgdb/gdbserver: add a '--no-escape-args' command line optionMichael Weghorn3-33/+266
This introduces a new '--no-escape-args' option for gdb and gdbserver. I (Andrew Burgess) have based this patch from work done in this series: https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ I have changed things slightly from the original series. I think this work is close enough that I've left the original author (Michael) in place and added myself as co-author. Any bugs introduced by my modifications to the original patch should be considered mine. I've also added documentation and tests which were missing from the originally proposed patch. When the startup-with-shell option is enabled, arguments passed directly as 'gdb --args <args>' or 'gdbserver <args>', are by default escaped so that they are passed to the inferior as passed on the command line, no globbing or variable substitution happens within the shell GDB uses to start the inferior. For gdbserver, this is the case since commit: commit bea571ebd78ee29cb94adf648fbcda1e109e1be6 Date: Mon May 25 11:39:43 2020 -0400 Use construct_inferior_arguments which handles special chars Only arguments set via 'set args <args>', 'run <args>', or through the Python API are not escaped in standard upstream GDB right now. For the 'gdb --args' case, directly setting unescaped args on gdb invocation is possible e.g. by using the "--eval-command='set args <args>'", while this possibility does not exist for gdbserver. This commit adds a new '--no-escape-args' command line option for GDB and gdbserver. This option is used with GDB as a replacement for the current '--args' option, and for gdbserver this new option is a flag which changes how gdbserver handles inferior arguments on the command line. When '--no-escape-args' is used inferior arguments passed on the command line will not have escaping added by GDB or gdbserver. For gdbserver, using this new option allows having the behaviour from before commit bea571ebd78ee29cb94adf648fbcda1e109e1be6, while keeping the default behaviour unified between GDB and GDBserver. For GDB the --no-escape-args option can be used as a replacement for --args, like this: shell> gdb --no-escape-args my-program arg1 arg2 arg3 While for gdbserver, the --no-escape-args option is a flag, which can be used like: shell> gdbserver --no-escape-args --once localhost:54321 \ my-program arg1 arg2 arg3 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Tested-By: Guinevere Larsen <guinevere@redhat.com>
5 days[gdb/testsuite, tclint] Fix gdb.testsuiteTom de Vries3-8/+8
Running tclint on the test-cases in gdb.testsuite shows a few problems: ... board-sanity.exp:47:38: line has trailing whitespace [trailing-whitespace] board-sanity.exp:83:1: line has trailing whitespace [trailing-whitespace] board-sanity.exp:95:38: line has trailing whitespace [trailing-whitespace] gdb-caching-proc-consistency.exp:66:2: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] gdb-caching-proc-consistency.exp:117:12: eval received an argument with a \ substitution, unable to parse its arguments [command-args] with-override.exp:53:18: expression with substitutions should be enclosed by \ braces [unbraced-expr] with-override.exp:57:18: expression with substitutions should be enclosed by \ braces [unbraced-expr] ... Fix these. Tested on x86_64-linux.
5 days[gdb/testsuite] Remove gdb.testsuite/lmap.expTom de Vries1-20/+0
Test-case gdb.testsuite/lmap.exp was added to test a local definition of lmap in lib/gdb.exp. That one has been removed in commit e447f3a122c ("Require Tcl 8.6.2"). Remove the unnecessary test-case.
6 daysAdd Ada test case with long array indicesTom Tromey4-0/+104
This patch adds a test case to test that the previous two patches did their job. With the current gdb, this test fails: (gdb) print some_regular_access.all Value out of range. The bug here is that the array has an index type that is wider than 'int', which is perfectly acceptable in Ada. Note that this series doesn't quite go far enough: in Ada the index could be a 128-bit integer. This change would be more invasive; and in practice this doesn't really seem to come up much -- so I've deferred it.
6 days[gdb/testsuite, tclint] Drop lreverseTom de Vries1-13/+0
When running tclint with lib/future.exp, I get: ... $ tclint lib/future.exp $exp:756:5: redefinition of built-in command 'lreverse' [redefined-builtin] ... The code was added to handle pre-7.5 tcl versions without lreverse. Since we now require Tcl 8.6.2 (as per PR testsuite/33205), drop this. Tested by rerunning tclint. Approved-By: Simon Marchi <simon.marchi@efficios.com> PR testsuite/33403 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33403
6 days[gdb/testsuite, tclint] Fix syntax error in gdb.base/dtrace-probe.expTom de Vries1-2/+2
When running tclint with gdb.base/dtrace-probe.exp I get: ... $ tclint gdb.base/dtrace-probe.exp $exp:67:45: syntax error: expected newline or semicolon, got ] ... due to these lines: ... 67 runto "-probe-dtrace test:two-locations"] 68 runto "-probe-dtrace test:two-locations"] ... Fix this by dropping the trailing ']'. Tested by rerunning tclint. Approved-By: Simon Marchi <simon.marchi@efficios.com> PR testsuite/33403 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33403
6 days[gdb/testsuite, tclint] Fix unrecognized argument in ↵Tom de Vries1-2/+2
gdb.trace/mi-traceframe-changed.exp When running tclint on gdb.trace/mi-traceframe-changed.exp, I get: ... $ tclint gdb.trace/mi-traceframe-changed.exp $exp:94:1: unrecognized argument for append: -1 [command-args] $exp:95:1: unrecognized argument for append: -1 [command-args] ... for these lines: ... 94 append testfile -1 95 append binfile -1 ... This seems harmless to me, but since tclint complains, fix this by quoting the -1 arguments. Tested by rerunning tclint. Approved-By: Simon Marchi <simon.marchi@efficios.com> PR testsuite/33403 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33403
6 daysFix unwinding when restoring a register from one of a greater sizeKevin Buettner4-0/+198
When debugging functions where a callee-saved register is moved to a register of a larger size (e.g., a 64-bit general-purpose register to a 128-bit vector register), GDB would crash when the user issued the "return" command. For example: ldgr %f0, %r11 ; Move 64-bit general-purpose register (r11) ; to 128-bit vector register (f0) .cfi_register r11, f0 ; DW_CFA_register: r11 is stored in f0 ... lgdr %r11, %f0 ; Restore r11 from f0 .cfi_restore r11 ; DW_CFA_restore: r11 is restored to its original ; register (This example uses instructions and registers for the S390x architecture, where this bug was originally found.) If GDB is stopped in the "..." section and the user issues the "return" command, GDB crashes due to a buffer size mismatch during unwinding. Specifically, in frame_register_unwind in frame.c, a buffer the size of the original register (the 64-bit r11 in this example) has been allocated and GDB would like to use memcpy to copy the contents of the register where the original register was saved (the 128-bit f0) to the buffer for the original register. But, fortunately, GDB has an assertion which prevents this from happening: gdb_assert (buffer.size () >= value->type ()->length ()); This patch ensures that GDB uses the original register's type (e.g., r11's type) when unwinding, even if it was marked as saved to a differently typed/sized register (e.g., f0) via .cfi_register (DW_CFA_register). The fix adds a 'struct type *' parameter to value_of_register_lazy() to explicitly track the original register's type. The function frame_unwind_got_register is updated to pass the correct type for the original register. The call chain from frame_register_unwind to frame_unwind_got_register is shown by this backtrace: #0 frame_unwind_got_register (frame=..., regnum=13, new_regnum=128) at gdb/frame-unwind.c:300 #1 0x000000000135d894 in dwarf2_frame_prev_register (this_frame=..., this_cache=0x2204528, regnum=13) at gdb/dwarf2/frame.c:1187 #2 0x00000000014d9186 in frame_unwind_legacy::prev_register ( this=0x211f428 <dwarf2_frame_unwind>, this_frame=..., this_prologue_cache=0x2204528, regnum=13) at gdb/frame-unwind.c:401 #3 0x00000000014e1d12 in frame_unwind_register_value (next_frame=..., regnum=13) at gdb/frame.c:1263 #4 0x00000000014e16b8 in frame_register_unwind (next_frame=..., regnum=13, optimizedp=0x3ffffff813c, unavailablep=0x3ffffff8138, lvalp=0x3ffffff8134, addrp=0x3ffffff8128, realnump=0x3ffffff8124, buffer=...) at gdb/frame.c:1189 The register numbers shown above are for s390x. On s390x, S390_R11_REGNUM has value 13. Vector registers (like f0) are numbered differently from floating-point registers of the same name, leading to regnum 128 for f0 despite S390_F0_REGNUM being assigned a different value in s390-tdep.h. New test cases for aarch64 and x86_64 check for this on more popular architectures and also without dependency on a particular compiler to generate an unusual prologue in which a general purpose register is being moved to a vector register. In both cases, the test simulates the bug found on s390x where a 64-bit frame pointer was being moved to a much wider vector register. These test cases will cause an internal error on their respective architecture, but will pass with this fix in place. When tested on s390x linux (native), this change fixes 59 GDB internal errors and around 200 failures overall. This is the list of internal errors that no longer occur on s390x: FAIL: gdb.base/call-sc.exp: tc: return foo; return call-sc-tc (GDB internal error) FAIL: gdb.base/call-sc.exp: td: return foo; return call-sc-td (GDB internal error) FAIL: gdb.base/call-sc.exp: te: return foo; return call-sc-te (GDB internal error) FAIL: gdb.base/call-sc.exp: tf: return foo; return call-sc-tf (GDB internal error) FAIL: gdb.base/call-sc.exp: ti: return foo; return call-sc-ti (GDB internal error) FAIL: gdb.base/call-sc.exp: tl: return foo; return call-sc-tl (GDB internal error) FAIL: gdb.base/call-sc.exp: tld: return foo; return call-sc-tld (GDB internal error) FAIL: gdb.base/call-sc.exp: tll: return foo; return call-sc-tll (GDB internal error) FAIL: gdb.base/call-sc.exp: ts: return foo; return call-sc-ts (GDB internal error) FAIL: gdb.base/gnu_vector.exp: return from vector-valued function (GDB internal error) FAIL: gdb.base/return-3.exp: in foo: return (GDB internal error) FAIL: gdb.base/return-nodebug.exp: double: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: float: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: int: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: long-long: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: long: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: short: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: signed-char: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return.exp: return value 5 (GDB internal error) FAIL: gdb.base/return.exp: return value 5.0 (GDB internal error) FAIL: gdb.base/return2.exp: return from char_func (GDB internal error) FAIL: gdb.base/return2.exp: return from double_func (GDB internal error) FAIL: gdb.base/return2.exp: return from float_func (GDB internal error) FAIL: gdb.base/return2.exp: return from int_func (GDB internal error) FAIL: gdb.base/return2.exp: return from long_func (GDB internal error) FAIL: gdb.base/return2.exp: return from long_long_func (GDB internal error) FAIL: gdb.base/return2.exp: return from short_func (GDB internal error) FAIL: gdb.base/return2.exp: return from void_func (GDB internal error) FAIL: gdb.base/sigstep.exp: return from handleri: leave handler (GDB internal error) FAIL: gdb.base/structs.exp: types=tc-ti: return foo<n>; return 2 structs-tc-ti (GDB internal error) FAIL: gdb.base/structs.exp: types=tc-tl: return foo<n>; return 2 structs-tc-tl (GDB internal error) FAIL: gdb.base/structs.exp: types=tc-ts: return foo<n>; return 2 structs-tc-ts (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo<n>; return 1 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo<n>; return 2 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo<n>; return 3 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo<n>; return 4 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo<n>; return 5 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo<n>; return 6 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo<n>; return 7 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo<n>; return 8 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=td-tf: return foo<n>; return 2 structs-td-tf (GDB internal error) FAIL: gdb.base/structs.exp: types=td: return foo<n>; return 1 structs-td (GDB internal error) FAIL: gdb.base/structs.exp: types=tf-tc: return foo<n>; return 2 structs-tf-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tf-td: return foo<n>; return 2 structs-tf-td (GDB internal error) FAIL: gdb.base/structs.exp: types=tf: return foo<n>; return 1 structs-tf (GDB internal error) FAIL: gdb.base/structs.exp: types=tf: return foo<n>; return 2 structs-tf (GDB internal error) FAIL: gdb.base/structs.exp: types=ti-tc: return foo<n>; return 2 structs-ti-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=ti: return foo<n>; return 1 structs-ti (GDB internal error) FAIL: gdb.base/structs.exp: types=ti: return foo<n>; return 2 structs-ti (GDB internal error) FAIL: gdb.base/structs.exp: types=tl-tc: return foo<n>; return 2 structs-tl-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tl: return foo<n>; return 1 structs-tl (GDB internal error) FAIL: gdb.base/structs.exp: types=tl: return foo<n>; return 2 structs-tl (GDB internal error) FAIL: gdb.base/structs.exp: types=tld: return foo<n>; return 1 structs-tld (GDB internal error) FAIL: gdb.base/structs.exp: types=tll: return foo<n>; return 1 structs-tll (GDB internal error) FAIL: gdb.base/structs.exp: types=ts-tc: return foo<n>; return 2 structs-ts-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=ts: return foo<n>; return 1 structs-ts (GDB internal error) FAIL: gdb.base/structs.exp: types=ts: return foo<n>; return 2 structs-ts (GDB internal error) FAIL: gdb.base/structs.exp: types=ts: return foo<n>; return 3 structs-ts (GDB internal error) FAIL: gdb.base/structs.exp: types=ts: return foo<n>; return 4 structs-ts (GDB internal error) I have tested this commit on Fedora Linux, with architectures s390x, x86_64, x86_64/-m32, aarch64, ppc64le, and riscv64, with no regressions found. This v2 version makes some changes suggested by Andrew Burgess: It adds an assert to frame_unwind_got_register() and always passes the type of REGNUM to value_of_register_lazy(). It also updates value.h's comment describing value_of_register_lazy(). In his approval message, Andrew requested some changes to the tests. Those have been made exactly as requested. Approved-By: Andrew Burgess <aburgess@redhat.com>
7 daysPut all CTF symbols in global scopeTom Tromey1-2/+2
The new approach to searching (solely via the quick API) is more sensitive to discrepancies between the partial and full readers. In CTF, there is some disagreement about which scope to use. CTF doesn't seem to really distinguish between the file and global scope, so this patch takes the simple approach of putting all CTF symbols into the global scope. This changes one test as well. It seems to me that the behavior here is arbitrary and the test is making unwarranted assumptions. Acked-By: Simon Marchi <simon.marchi@efficios.com>
7 daysAda import functions not in indexTom Tromey1-14/+14
The cooked index does not currently contain entries for Ada import functions. This means that whether or not these are visible to "break" depends on which CUs were previously expanded -- clearly a bug. This patch fixes the issue. I think the comments in the patch explain the fix reasonably well. Perhaps one to-do item here is to change GNAT to use DW_TAG_imported_declaration for these imports. This may eventually let us remove some of the current hacks. This version includes a fix from Simon to initialize the new member. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32511 Acked-By: Simon Marchi <simon.marchi@efficios.com>
7 daysSkip some tests with "readnow" boardTom Tromey3-0/+12
This series pointed out a few tests that check that a particular index is in use. It seems to me that this does not really make sense when the "readnow" board is in use, as this actually skips index creation. The tests do pass today, but by accident. This patch adds the appropriate "require" line to the tests in question. Approved-By: Simon Marchi <simon.marchi@efficios.com> Acked-By: Simon Marchi <simon.marchi@efficios.com>
7 daysFix var_arr_typedef.exp to preserve local variableTom Tromey3-3/+5
This patch fixes var_arr_typedef.exp to preserve a local variable a bit better, protecting it from a gnat-llvm optimization.
8 daysFix gdb.Value.dynamic_type attributeHannes Domani2-0/+3
gdb currently crashes if you try to get the dynamic_type from a gdb.Value of a POD struct: (gdb) py print(gdb.parse_and_eval('pod').dynamic_type) Fatal signal: Segmentation fault It happens because value_rtti_type() returns NULL for them, and this is not handled correctly. Fixed by using val->type() as a fallback in this case. Approved-By: Simon Marchi <simon.marchi@efficios.com>