aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
7 hoursAutomatic date update in version.inHEADmasterGDB Administrator1-1/+1
12 hoursGDB: aarch64: Use GCS features to calculate hash of struct aarch64_featuresThiago Jung Bauermann1-0/+4
Luis noticed that when adding the gcs and gcs_linux members to struct aarch64_features in my Guarded Control Stack patch series, I neglected to modify struct hash<aarch64_features>::operator() to take them into account when computing its hash. This can cause GDB to use the wrong aarch64_features object during a debugging session. Regression tested on aarch64-linux-gnu. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33440 Suggested-by: Luis Machado <luis.machado.foss@gmail.com> Approved-By: Luis Machado <luis.machado.foss@gmail.com>
14 hours[gdb/testsuite, tclint] Fix gdb.dapTom de Vries3-4/+9
Running tclint on gdb.dap shows these warnings: ... bt-nodebug.exp:74:16: namespace eval received an argument with a \ substitution, unable to parse its arguments [command-args] eof.exp:33:1: expected braced word or word without substitutions in argument \ interpreted as script [command-args] eof.exp:34:1: expected braced word or word without substitutions in argument \ interpreted as script [command-args] ... The first one is for: ... set list_form [namespace eval ton::2list $last_ton] ... I don't think this can be fixed by rewriting into something similar, so ignore this. Likewise in lib/dap-support.exp. The second and third ones are for: ... catch "close -i $gdb_spawn_id" catch "wait -i $gdb_spawn_id" ... which can easily be fixed by using curly braces instead of double quotes, but doing so gets us: ... eof.exp:33:8: unrecognized argument for close: -i [command-args] ... This is because tclint doesn't have support for expect yet [1], so ignore this. While we're at it, fix some trailing whitespace in lib/dap-support. Approved-By: Tom Tromey <tom@tromey.com> [1] https://github.com/nmoroze/tclint/issues/118
22 hoursgdb: fix --args handling when inferior argument have dashAndrew Burgess2-1/+19
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>
26 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.
26 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.
26 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.
26 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.
26 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.
26 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.
26 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.
26 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.
26 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.
26 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.
26 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.
31 hoursAutomatic date update in version.inGDB Administrator1-1/+1
35 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>
38 hoursld: testsuite: arm: Fix duplicate test names.Richard Earnshaw5-8/+8
Rename some tests to avoid ambiguity in the test names. I've changed several of the Thumb2 BL testnames to more accurately reflect the nature of the tests (some omitted 'bad' even when testing for errors, but that then led to other naming conflicts...).
38 hoursgdb: fix record si error in baremetal gdbtimurgol0071-2/+3
While I was debugging application using spike, openocd and baremetal gdb in record mode I encountered with gdb internal error. The reason was that minus_one_ptid had been passed to record_full_target::resume method. And in this function, the assert worked in target_thread_architecture. So I added a check before calling this function, that ptid is not minus_one_ptid. Actually, minus_one_ptid here doesn't mean that an error has occured, but it is just a define for RESUME_ALL. (gdb) record (gdb) si ../../gdb/process-stratum-target.c:32: internal-error: thread_architecture: Assertion `inf != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- ... 0x71463a _ZN22process_stratum_target19thread_architectureE6ptid_t ../../gdb/process-stratum-target.c:32 0x71463a _ZN22process_stratum_target19thread_architectureE6ptid_t ../../gdb/process-stratum-target.c:29 0x77131f _ZN18record_full_target6resumeE6ptid_ti10gdb_signal ../../gdb/record-full.c:1087 0x85a761 _Z13target_resume6ptid_ti10gdb_signal ../../gdb/target.c:2654 0x677aa9 do_target_resume ../../gdb/infrun.c:2631 0x6818b5 resume_1 ../../gdb/infrun.c:2984 0x6828a8 resume ../../gdb/infrun.c:2997 0x682b13 keep_going_pass_signal ../../gdb/infrun.c:9144 0x682fd9 proceed_resume_thread_checked ../../gdb/infrun.c:3580 ... ---------------------
39 hoursbinutils: testsuite: fix duplicate testnames in readelf.expRichard Earnshaw1-3/+1
There are two places in readelf.exp where we generate duplicate testnames. The first is due to calling readelf_find_size twice with the same iteration index (2). This is fixed by using 4 for the second instance. The other is at the end of readelf_thin_archive_test. This test calls readelf_test before unconditionally passing. It happens to construct exactly the same test name as readelf test (might not be a coincidence), so we end up with a duplicate test. But it seems wrong anyway to 'pass' a test that readelf_test might have failed, so simply delete this duplicate pass entry.
40 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>
40 hoursgas: testsuite: aarch64: Resolve duplicate testrun names.Richard Earnshaw3-3/+3
These are all simple typos in the test names.
40 hoursgas: testsuite: aarch64: Remove duplicate test from sv2p1-5.dRichard Earnshaw1-1/+0
This test runs with the assembler options '-march=armv9.4-a' twice. Looking at the related tests in this set, this appears to be redundant rather than a typo, so remove the second run.
41 hoursgas: Define comment_chars for non-ELF PowerPC targetsNick Clifton2-7/+7
44 hoursFix gdb.base/gcorebg.exp and --program-prefixPedro Alves4-8/+31
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
44 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
46 hoursgas: testsuite: all: Avoid clashing names in err-sizeof.sRichard Earnshaw1-1/+1
The first junk test in this file was missing "junk" in the test name, which resulted in a duplicate test name when comparing with the real test on line 3.
46 hoursgas: testsuite: elf: avoid clashing mbind test namesRichard Earnshaw1-1/+1
The section12b.d test has the wrong name, leading to a clash with the section 16b.d test. Fix that up.
46 hoursbinutils: testsuite: avoid dup names when using multiple as: directivesRichard Earnshaw1-11/+16
binutils tests support running a test with distinct options to the assembler by allowing #as: <optset-1> #as: <optset-2> But results in both test runs using the same test name in the summary file. This causes confusion if one test fails but the other doesn't (and GCC's compare_tests script will diagnose this as an error). To fix the ambiguity append the appropriate optset to the test name. We only do this if a test has multiple runs in this way to avoid causing every test result name to change.
46 hoursgas: testsuite: all: use unique test names for multibyte3 testsRichard Earnshaw1-1/+1
There are two tests of the mutibyte3 source file, with different options. As things stand this results in two distinct tests in the logs with the same name. Avoid this by adding the optional testname option to the second test.
47 hoursRemove Solaris/PowerPC supportRainer Orth14-99/+42
Solaris/PowerPC was a shortlived Solaris port with limited hardware support. It was released with Solaris 2.5.1 back in 1996, with support removed again only a year later in Solaris 2.6. Since this is long obsolete, this patch removes the remains of the support. Tested by a cross to ppc-unknown-linux-gnu to ascertain the build didn't get broken. 2025-09-15 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> bfd: * config.bfd <powerpc-*-solaris2*>: Remove. gas: * NEWS: Mention Solaris/PowerPC removal. * configure.ac <ppc-*-solaris*>: Remove. * configure: Regenerate. * configure.in: Regenerate. * configure.tgt <ppc-*-solaris*>: Remove. * config/tc-ppc.c (ppc_solaris_comment_chars): Remove. (ppc_eabi_comment_chars): Remove. (SOLARIS_P): Remove. (msolaris): Remove. (md_parse_option): Remove "solaris", "no-solaris" hangling. (md_show_usage): Likewise. (md_begin): Remove msolaris handling. * config/tc-ppc.h (ppc_comment_chars): Fix declaration. * stabs.c (s_stab_generic) [TC_PPC && OBJ_ELF]: Remove 4-arg .stabd support. * doc/as.texi (Overview, Target PowerPC options): Remove -msolaris, -mno-solaris. * doc/c-ppc.texi (PowerPC-Opts): Remove -msolaris, -mno-solaris. (PowerPC-Chars): Remove ! as line comment character. ld: * configure.tgt <powerpc*-*-solaris*>: Remove.
2 daysgas/expr.h fixmeAlan Modra1-12/+4
* expr.h (expressionS): Adjust comments. Use ENUM_BITFIELD for X_op. (enum operatorT): Define.
2 daysDelete gas/po/gas.es.poAlan Modra1-24208/+0
es.po is newer, and this file is wrongly named.
2 daysAutomatic date update in version.inGDB Administrator1-1/+1
3 daysMake 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 daysgdbsupport: remove xmalloc in format_piecesSimon Marchi6-86/+89
Remove the use of xmalloc (and the arbitrary allocation size) in format_pieces. This turned out a bit more involved than expected, but not too bad. format_pieces::m_storage is a buffer with multiple concatenated null-terminated strings, referenced by format_piece::string. Change this to an std::string, while keeping its purpose (use the std::string as a buffer with embedded null characters). However, because the std::string's internal buffer can be reallocated as it grows, and I do not want to hardcode a big reserved size like we have now, it's not possible to store the direct pointer to the string in format_piece::string. Those pointers would become stale as the buffer gets reallocated. Therefore, change format_piece to hold an index into the storage instead. Add format_pieces::piece_str for the callers to be able to access the piece's string. This requires changing the few callers, but in a trivial way. The selftest also needs to be updated. I want to keep the test cases as-is, where the expected pieces contain the expected string, and not hard-code an expected index. To achieve this, add the expected_format_piece structure. Note that the previous format_piece::operator== didn't compare the n_int_args fields, while the test provides expected values for that field. I guess that was a mistake. The new code checks it, and the test still passes. Change-Id: I80630ff60e01c8caaa800ae22f69a9a7660bc9e9 Reviewed-By: Keith Seitz <keiths@redhat.com>
3 daysgdbsupport: remove remaining alloca usesSimon Marchi3-36/+21
Remove the three remaining uses of alloca in gdbsupport. I only built-tested the Windows-only portion in pathstuff.cc. Change-Id: Ie588fa57f43de900d5f42e93a8875a7da462404b Reviewed-By: Keith Seitz <keiths@redhat.com>
3 daysgdbsupport: format_pieces: declare variables when neededSimon Marchi1-14/+9
I think it makes the code slightly easier to understand. Change-Id: I49056728e43fbf37c2af8f3904a543c10e987bba Reviewed-By: Keith Seitz <keiths@redhat.com>
3 daysarm: Rename some tests to avoid duplicate tests namesRichard Earnshaw29-29/+29
A number of arm-specific tests print the same name. This can cause problems if one of those tests fails, since then comparing tests with GCC's compare_tests script can result in ambiguities in the changes summary. Avoid this by giving tests unique names. Still to do is where a test is run more than once (eg by having multiple '#as: ' lines). This will require a tweak to the framework.
3 daysRISC-V: Add support for sdtrig and ssstrict extensions.Dongyan Chen5-0/+15
This implements the sdtrig extension, version 1.0[1] and ssstrict extension, version 1.0[2]. [1]https://github.com/riscv/riscv-debug-spec/blob/main/Sdtrig.adoc [2]https://github.com/riscv/riscv-profiles/issues/173 bfd/ChangeLog: * elfxx-riscv.c: Added sdtrig and ssstrict v1.0, and imply rules. gas/ChangeLog: * NEWS: Updated for sdtrig and ssstrict. * testsuite/gas/riscv/imply.d: DItto. * testsuite/gas/riscv/imply.s: Ditto. * testsuite/gas/riscv/march-help.l: Ditto.
3 daysAutomatic date update in version.inGDB Administrator1-1/+1
4 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>
4 daysgdb: improve show text and help text for 'remote exec-file'Andrew Burgess3-6/+18
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>
4 daysgdb: improve how 'remote exec-file' is stored and accessedAndrew Burgess2-36/+39
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 daysgdb: have remote_target::extended_remote_run take the exec filenameAndrew Burgess1-4/+5
Small refactor, have remote_target::extended_remote_run take the name of the executable to run rather than looking it up directly, the one caller of this function has already looked up the remote-exec filename. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
4 daysAutomatic date update in version.inGDB Administrator1-1/+1
5 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 daysdoc: sframe: add DRAFT marker for all outputsIndu Bhagat1-0/+4
Add DRAFT marker to be emitted in the info, pdf and html outputs. This is done in two places: one in the @ifnottex block meant for PDF output and another in @titlepage block meant for info and html output. While at it, also add date to non-pdf outputs. The marker lines: @center @strong{*** DRAFT - NOT FOR DISTRIBUTION ***} should be removed before a release. libsframe/doc/ * sframe-spec.texi: Add marker for DRAFT.
5 daysgdb, gdbserver: fix typosSimon Marchi2-4/+4
Found by the codespell pre-commit hook. Change-Id: Iafadd9485ce334c069dc8dbdab88ac3fb5fba674
5 daysAutomatic date update in version.inGDB Administrator1-1/+1