aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
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>
9 daysUse ada_fvar_tracking in finish-var-size.expTom Tromey1-1/+1
commit a16f37e8 changed finish-var-size.exp to use have_fvar_tracking. However, in Ada tests, ada_fvar_tracking must be used instead.
10 daysRequire Tcl 8.6.2Tom Tromey2-53/+7
This changes the gdb test suite to require Tcl 8.6.2. This allows the removal of some more compatibility code. I wrote this as a separate patch so make it simpler to drop if some platform only provides Tcl 8.5. According to research in the bug, though, it seems like this isn't likely. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33205 Approved-By: Simon Marchi <simon.marchi@efficios.com>
10 daysRewrite tcl_version_at_leastTom Tromey1-15/+3
tcl_version_at_least can more easily be expressed using the built-in "package" command. Approved-By: Simon Marchi <simon.marchi@efficios.com>
10 daysRequire Tcl 8.5Tom Tromey1-17/+2
This patch changes the gdb test suite to require Tcl 8.5. It also removes the one pre-8.5 compatibility function. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33205 Approved-By: Simon Marchi <simon.marchi@efficios.com>
10 daysgdb/testsuite: small fix for amd64-extended-prologue-analysis.expAndrew Burgess1-2/+6
I noticed I was sometimes getting this failure: FAIL: gdb.arch/amd64-extended-prologue-analysis.exp: offset \ initialization: ASM source: gdb_breakpoint: set breakpoint \ at *0x0000000000401151 The problem was introduced in commit: commit f9aa48dc545ef511e19f4dfab88a196b820fd2da Date: Thu Aug 28 11:50:13 2025 +0000 gdb, amd64: extend the amd64 prologue analyzer to skip register pushes A gdb_test_multiple exits early when processing the results of a 'disassemble' command, without waiting for the prompt to be seen. This can leave unhandled output in expect's input buffer, which will then throw off the next test. Update the gdb_test_multiple to wait for the prompt before declaring the test passed. After this I'm no longer seeing the above failure. There should be no change in what is tested after this commit.
11 days[gdb/testsuite] Error out on clean_restart <absolute filename>Tom de Vries2-0/+7
Error out in proc clean_restart if the argument is an absolute filename. Likewise in proc mi_clean_restart. Tested on x86_64-linux.
13 daysAllow conversion of 128-bit integers to PythonTom Tromey1-0/+12
Currently, trying to convert a 128-bit integer from a gdb.Value to a Python integer will fail. This is surprising because Python uses bigints internally. The bug here is that valpy_long uses value_as_long, which fails for anything wider than LONGEST. This patch fixes the problem by using the recommended Python API. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33366 Approved-By: Simon Marchi <simon.marchi@efficios.com>
13 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 3Tom de Vries6-9/+16
Fix fallout in gdb.base from erroring out on clean_restart <absolute filename>. Tested on x86_64-linux.
13 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 2Tom de Vries31-42/+69
Manually fix the test-cases found by: ... $ find gdb/testsuite/gdb.base -name *.exp* \ | xargs grep -l 'clean_restart[^;]*binfile' $ find gdb/testsuite/gdb.base -name *.exp* \ | xargs grep -l 'prepare_for_testing.*bin' ... except for gdb.base/foll-vfork.exp and gdb.base/solib-overlap.exp. Tested on x86_64-linux.
13 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 1Tom de Vries192-250/+500
Run: ... $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart $binfile$/\1clean_restart\n\1gdb_load $binfile/' $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart ${binfile}$/\1clean_restart\n\1gdb_load $binfile/' $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart $::binfile$/\1clean_restart\n\1gdb_load $::binfile/' $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart ${::binfile}$/\1clean_restart\n\1gdb_load $::binfile/' ... Revert the change in test-case gdb.base/foll-vfork.exp, which does 'set binfile $testfile'. Tested on x86_64-linux. The only modified test-case I was not able to test is gdb.base/dtrace-probe.exp (filed PR testsuite/33379 about this). The change in the test-case is trivial though.
13 daysgdb: ensure bp_location::section is set correct to avoid an assertAndrew Burgess1-0/+5
While reviewing and testing another patch I set a breakpoint on an gnu ifunc function, then restarted the inferior, and this assert triggered: ../../src/gdb/breakpoint.c:14747: internal-error: breakpoint_free_objfile: Assertion `loc->symtab == nullptr' failed. The backtrace at the time of the assert is: #6 0x00000000005ffee0 in breakpoint_free_objfile (objfile=0x4064b30) at ../../src/gdb/breakpoint.c:14747 #7 0x0000000000c33ff2 in objfile::~objfile (this=0x4064b30, __in_chrg=<optimized out>) at ../../src/gdb/objfiles.c:478 #8 0x0000000000c38da6 in std::default_delete<objfile>::operator() (this=0x7ffc1a49d538, __ptr=0x4064b30) at /usr/include/c++/9/bits/unique_ptr.h:81 #9 0x0000000000c3782a in std::unique_ptr<objfile, std::default_delete<objfile> >::~unique_ptr (this=0x7ffc1a49d538, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/unique_ptr.h:292 #10 0x0000000000caf1bd in owning_intrusive_list<objfile, intrusive_base_node<objfile> >::erase (this=0x3790d68, i=...) at ../../src/gdb/../gdbsupport/owning_intrusive_list.h:111 #11 0x0000000000cacd0c in program_space::remove_objfile (this=0x3790c80, objfile=0x4064b30) at ../../src/gdb/progspace.c:192 #12 0x0000000000c33e1c in objfile::unlink (this=0x4064b30) at ../../src/gdb/objfiles.c:408 #13 0x0000000000c34fb9 in objfile_purge_solibs (pspace=0x3790c80) at ../../src/gdb/objfiles.c:729 #14 0x0000000000edf6f7 in no_shared_libraries (pspace=0x3790c80) at ../../src/gdb/solib.c:1359 #15 0x0000000000fb3f6c in target_pre_inferior () at ../../src/gdb/target.c:2466 #16 0x0000000000a724d7 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:390 #17 0x0000000000a72a97 in run_command (args=0x0, from_tty=0) at ../../src/gdb/infcmd.c:514 #18 0x00000000006bbb3d in do_simple_func (args=0x0, from_tty=0, c=0x39124b0) at ../../src/gdb/cli/cli-decode.c:95 #19 0x00000000006c1021 in cmd_func (cmd=0x39124b0, args=0x0, from_tty=0) at ../../src/gdb/cli/cli-decode.c:2827 The function breakpoint_free_objfile is being called when an objfile representing a shared library is being unloaded ahead of the inferior being restarted, the function is trying to remove references to anything that could itself reference the objfile that is being deleted. The assert is making the claim that, for a bp_location, which has a single address, the objfile of the symtab associated with the location will be the same as the objfile associated with the section of the location. This seems reasonable to me now, as it did when I added the assert in commit: commit 5066f3680667ec0f2d1745847a2372d85973a1e7 Date: Mon Nov 11 21:45:17 2024 +0000 gdb: do better in breakpoint_free_objfile The bp_location::section is maintained, according to the comments in breakpoint.h, to aid overlay debugging (is that even used any more), and looking at the code, this does appear to be the case. The problem in the above case arises when we are dealing with an ifunc function. What happens is that we end up with a section from one objfile, but a symtab from a different objfile. This problem originates from minsym_found (in linespec.c). The user asked for 'break gnu_ifunc' where 'gnu_ifunc' is an ifunc function. What this means is that gnu_ifunc is actually a resolver function that returns the address of the actual function to use. In this particular test case, the resolver function is in a shared library, and the actual function to use is in the main executable. So, when GDB looks for 'gnu_ifunc' is finds the minimal_symbol with that name, and spots that this has type mst_text_gnu_ifunc. GDB then uses this to figure out the actual address of the function that will be run. GDB then creates the symtab_and_line using the _real_ address and the symtab in which that address lies, in our case this will all be related to the main executable objfile. But, finally, in minsym_found, GDB fills in the symtab_and_line's section field, and this is done using the section containing the original minimal_symbol, which is from the shared library objfile. The minimal symbol and section are then use to initialise the bp_location object, and this is how we end up in, what I think, is an unexpected state. So what to do about this? The symtab_and_line::msymbol field is _only_ set within minsym_found, and is then _only_ used to initialise the bp_location::msymbol field. The bp_location::msymbol field is _only_ used in the function set_breakpoint_location_function, and we only really care about the msymbol type, we check to see if it's an ifunc symbol or not. This allows us to set the name of the function correctly. The bp_location::section is used, as far as I can tell, extensively for overlay handling. It would seem to me, that this section should be the section containing the actual breakpoint address. If the question we're asking is, is this breakpoint mapped in or not? Then surely we need to ask about the section holding the breakpoint's address, and not the section holding some other code (e.g. the resolver function). In fact, in a memory constrained environment, you'd expect the resolver functions to get mapped out pretty early on, but while the actual functions might still be mapped in. Finally, symtab_and_line::section. This is mostly set using calls to find_pc_overlay. The minsym_found function is one of the few places where we do things differently. In the places where the section is used, it is (almost?) always used in conjunction with the symtab_and_line::pc to lookup information, e.g. calls to block_for_pc_sect, or find_pc_sect_containing_function. In all these cases, it appears to me that the assumption is that the section will be the section that contains the address. So, where does this leave us? I think what we need to do is update minsym_found to just use find_pc_overlay, which is how the symtab_and_line::section is set in most other cases. What this actually means in practise is that the section field will be set to NULL (see find_pc_overlay in symfile.c). But given that this is how the section is computed in most other cases, I don't see why it should be especially problematic for this case. In reality, I think this just means that the section is calculated via a call to find_pc_section when it's needed, as an example, see lookup_minimal_symbol_by_pc_section (minsyms.c). I do wonder if we should be doing better when creating the symtab_and_line, and insist that the section be calculated correctly at that point, but I really don't want to open that can of worms right now, so I think just changing minsym_found to "do it just like everyone else" should be good enough. I've extended the existing ifunc test to expose this issue, the updated test fails without this patch, and passes with. Approved-By: Simon Marchi <simon.marchi@efficios.com>
13 days[gdb/testsuite] Fix gdb.base/fileio.exp for local-remote-host-nativeTom de Vries2-1/+5
When running test-case gdb.base/fileio.exp with host/target board local-remote-host-native I run into: ... gdb compile failed, fileio.c: In function 'test_open': <command-line>:0:8: error: expected expression before '.' token fileio.c:89:15: note: in expansion of macro 'OUTDIR' ret = open (OUTDIR FILENAME, O_CREAT | O_TRUNC | O_RDWR, S_IWUSR | S_IRUSR); ^~~~~~ ... Fix this by using: - quote_for_host to pass -DOUTDIR to the compilation, and - STRINGIFY to stringify OUTDIR in fileio.c. Tested on x86_64-linux, with target board unix and host/target board local-remote-host-native.
13 days[gdb/testsuite] Fix clean_restart <absolute filename> in allow_aarch64_sme_testsTom de Vries1-1/+2
Fix fallout on aarch64-linux with test-case gdb.testsuite/gdb-caching-proc-consistency.exp from erroring out on clean_restart <absolute filename>.
13 days[gdb/testsuite] Fix silent timeout in allow_aarch64_gcs_testsTom de Vries1-0/+3
I noticed on M1 aarch64-linux that test-case gdb.testsuite/gdb-caching-proc-consistency.exp took a long time. I saw lack of progress in gdb.log for proc allow_aarch64_gcs_tests. This gdb_expect only handles the case that gcs support is detected: ... gdb_expect { -re ".*$inferior_exited_re normally.*${gdb_prompt} $" { verbose -log "\n$me: gcs support detected" set allow_gcs_tests 1 } } ... but in my case, I get: ... (gdb) run ^M Starting program: allow_aarch64_gcs_tests.x ^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M [Inferior 1 (process 3336556) exited with code 01]^M (gdb) ... so the gdb_expect times out quietly, taking 10 seconds. In the test-case, it does so 11 times. Fix this by adding a gdb_expect clause handling the "with code 01" case. Tested on aarch64-linux. PR testsuite/33378 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33378
13 daysGDB: aarch64-linux: Define HWCAP_GCS as unsigned long long valueThiago Jung Bauermann5-5/+5
On platforms where long is 32 bits, this change fixes a build failure: /home/linux/arm/gdb/src/gdb/aarch64-linux-tdep.c: In function ‘const target_desc* aarch64_linux_core_read_description(gdbarch*, target_ops*, bfd*)’: /home/linux/arm/gdb/src/gdb/arch/aarch64-gcs-linux.h:27:24: error: left shift count >= width of type [-Werror=shift-count-overflow] 27 | #define HWCAP_GCS (1UL << 32) | ~~~~^~~~~ /home/linux/arm/gdb/src/gdb/aarch64-linux-tdep.c:1714:47: note: in expansion of macro ‘HWCAP_GCS’ 1714 | features.gcs = features.gcs_linux = hwcap & HWCAP_GCS; | ^~~~~~~~~ Suggested-by: Tom de Vries <tdevries@suse.de> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33372
13 daysgdb/testsuite: revert recent changes to gdb.dap/scopes.expAndrew Burgess1-143/+132
After the previous commit, the changes to gdb.dap/scopes.exp from the commit: commit 63b862be762e1e6e7ce667c6b4a1a3dd79939bf4 Date: Fri Mar 29 16:38:50 2019 +0100 gdb, gdbserver: Add support of Intel shadow stack pointer register. Are no longer needed, the test will now happily handle the shadow stack pointer being unavailable. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33345 Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
13 daysgdb/python: add gdb.Value.is_unavailable attributeAndrew Burgess2-0/+42
Add a new gdb.Value.is_unavailable attribute. This is similar to the existing Value.is_optimized_out attribute, but returns True if any part of the value is <unavailable>. The existing Value.is_optimized_out attribute returns true if any part of the value is optimized out, so I thought that Value.is_unavailable should work the same way. There's also a test. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33345 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
13 daysgdb, amd64: extend the amd64 prologue analyzer to skip stack allocPawel Kupczak5-25/+105
Following the previous patch (gdb, amd64: extend the amd64 prologue analyzer to skip register pushes), this patch extends the analyzer further to be able to skip stack space allocation as the next prologue part, for functions with a frame pointer. Implementation was based on the i386 counterpart, which already had that functionality. As of now, the stack allocation is not skipped. Examples below use C source listed below, compiled with gcc 11.4.0. ``` int foo (int n) { int ns[] = { 1, 4, 9, 16, 25 }; return ns[n]; } int main (int argc, char **argv) { return foo (argc); } ``` Compiling with "gcc -O0 -fno-omit-frame-pointer" we get: ``` (gdb) b foo Breakpoint 1 at 0x1151 (gdb) r ... Breakpoint 1, 0x0000555555555151 in foo () (gdb) disassemble Dump of assembler code for function foo: 0x0000555555555149 <+0>: endbr64 0x000055555555514d <+4>: push %rbp 0x000055555555514e <+5>: mov %rsp,%rbp => 0x0000555555555151 <+8>: sub $0x30,%rsp 0x0000555555555155 <+12>: mov %edi,-0x24(%rbp) ... ``` With this patch, it gets skipped the same way register pushes are: ``` (gdb) b foo Breakpoint 1 at 0x1155 (gdb) r ... Breakpoint 1, 0x0000555555555155 in foo () (gdb) disassemble Dump of assembler code for function foo: 0x0000555555555149 <+0>: endbr64 0x000055555555514d <+4>: push %rbp 0x000055555555514e <+5>: mov %rsp,%rbp 0x0000555555555151 <+8>: sub $0x30,%rsp => 0x0000555555555155 <+12>: mov %edi,-0x24(%rbp) ... ``` Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
13 daysgdb, amd64: extend the amd64 prologue analyzer to skip register pushesPawel Kupczak5-0/+552
A typical function's prologue can consist of setting up a frame pointer, pushing registers onto the stack and allocating space on the stack. Current amd64 prologue analyzer would stop after the frame setup. This patch allows GDB to skip past register pushes, while also improving unwinding pushed registers, for functions with a frame pointer, without debug info and .cfi directives found in .eh_frame section that are used for unwinding. Skipping register pushes was also present for i386 targets before - the proposed changes are based on i386 implementation. It also improves the unwinding even if .cfi directives are present, because GDB can only unwind a register if it has reached a corresponding .cfi directive, which won't be there before the pushes. Additionally, at least gcc 11.4 and later by default doesn't emit necessary debug info, which GDB would try to use to find prologue's end. In that case, extended prologue analyzer would take effect. Using C source listed below as an example, compiled with gcc 11.4.0: ``` int __attribute__ ((noinline)) bar (int a) { return a + a; } int __attribute__ ((noinline)) foo (int a, int b, int c, int d, int e) { int x = bar (a) + bar (b) + bar (c) + bar (d) + bar (e); return x; } int main (int argc, char **argv) { return foo (1, 2, 3, 4, 5); } ``` Compiling with "gcc -O1 -fno-omit-frame-pointer -fno-asynchronous-unwind-tables", we get: ``` (gdb) b foo Breakpoint 1 at 0x1139 (gdb) r ... Breakpoint 1, 0x0000555555555139 in foo () (gdb) disassemble Dump of assembler code for function foo: 0x0000555555555131 <+0>: endbr64 0x0000555555555135 <+4>: push %rbp 0x0000555555555136 <+5>: mov %rsp,%rbp => 0x0000555555555139 <+8>: push %r15 0x000055555555513b <+10>: push %r14 0x000055555555513d <+12>: push %r13 0x000055555555513f <+14>: push %r12 0x0000555555555141 <+16>: push %rbx 0x0000555555555142 <+17>: sub $0x8,%rsp 0x0000555555555146 <+21>: mov %esi,%r15d ... (gdb) ni 0x000055555555513b in foo () (gdb) p $r15 $1 = 140737354125376 (gdb) p $r15=1234 $2 = 1234 (gdb) p $r15 $3 = 1234 (gdb) up #1 0x00005555555551b7 in main () (gdb) p $r15 $4 = 1234 ``` With the proposed changes, breakpoint gets past those register pushes: ``` (gdb) b foo Breakpoint 1 at 0x1142 (gdb) r ... Breakpoint 1, 0x0000555555555142 in foo () (gdb) disassemble Dump of assembler code for function foo: 0x0000555555555131 <+0>: endbr64 0x0000555555555135 <+4>: push %rbp 0x0000555555555136 <+5>: mov %rsp,%rbp 0x0000555555555139 <+8>: push %r15 0x000055555555513b <+10>: push %r14 0x000055555555513d <+12>: push %r13 0x000055555555513f <+14>: push %r12 0x0000555555555141 <+16>: push %rbx => 0x0000555555555142 <+17>: sub $0x8,%rsp 0x0000555555555146 <+21>: mov %esi,%r15d ... ``` Also, unwinding pushed registers now works: ``` ... Breakpoint 1, 0x0000555555555142 in foo () (gdb) disassemble Dump of assembler code for function foo: 0x0000555555555131 <+0>: endbr64 0x0000555555555135 <+4>: push %rbp 0x0000555555555136 <+5>: mov %rsp,%rbp 0x0000555555555139 <+8>: push %r15 0x0000555555555139 <+8>: push %r15 0x000055555555513b <+10>: push %r14 0x000055555555513d <+12>: push %r13 0x000055555555513f <+14>: push %r12 0x0000555555555141 <+16>: push %rbx => 0x0000555555555142 <+17>: sub $0x8,%rsp 0x0000555555555146 <+21>: mov %esi,%r15d ... (gdb) p $r15 $1 = 140737354125376 (gdb) p $r15=1234 $2 = 1234 (gdb) p $r15 $3 = 1234 (gdb) up #1 0x00005555555551b7 in main () (gdb) p $r15 $4 = 140737354125376 ``` Additionally a new test was added to verify this behavior. Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
14 daysgdb/testsuite: fix possible TCL errors in gdb.threads/threadcrash.expGuinevere Larsen1-2/+3
The test gdb.threads/threadcrash.exp, among other things, creates a list of the threads seen in the order that the "thread apply all backtrace" would generate them, tests that this list is the same size as GDB's count of threads, and then loops over the list to check that each thread has the expected backtrace. A problem occurs because the loop iterates on GDB's internal count of threads, rather than the size of the list, but then attempts to acces the n-th element of the list. If the list size is smaller than GDB's internal thread count, it'll access past the end of the list and generate TCL errors. This commit fixes this by using the list's length instead. Approved-By: Tom Tromey <tom@tromey.com>
14 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/*.expTom de Vries9-10/+19
Fix clean_restart <absolute filename> in gdb.arch/*.exp. The fixed test-cases are supported on archs sh, ia64, mips, pa and sparc. I haven't tested these.
14 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/powerpc*.expTom de Vries27-31/+47
Fix clean_restart <absolute filename> in gdb.arch/powerpc*.exp. Likewise in gdb.arch/ppc*.exp, gdb.arch/altivec*.exp, gdb.arch/e500*.exp and gdb.arch/vsx*.exp. Tested on ppc64le-linux. The following test-cases only run on 32-bit ppc: - gdb.arch/e500-abi.exp - gdb.arch/e500-prologue.exp - gdb.arch/e500-regs.exp - gdb.arch/powerpc-aix-prologue.exp - gdb.arch/powerpc-prologue.exp - gdb.arch/powerpc-prologue-frame.exp - gdb.arch/powerpc-trap.exp so these haven't been tested.
14 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/thumb*.expTom de Vries3-3/+3
Fix clean_restart <absolute filename> in gdb.arch/thumb*.exp. Likewise in test-case gdb.arch/pr25124.exp. Tested on arm-linux, target boards unix/-marm and unix/-mthumb.
14 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/arm*.expTom de Vries3-3/+3
Fix clean_restart <absolute filename> in gdb.arch/arm*.exp. Tested on: - arm-linux, target boards unix/-marm and unix/-mthumb - aarch64-linux
14 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/aarch64*.expTom de Vries7-14/+27
Fix clean_restart <absolute filename> in gdb.arch/aarch64*.exp. Tested on aarch64-linux, M1 system. There's a large number (44) of unsupported, for the following reasons: - allow_aarch64_gcs_tests - allow_aarch64_mops_tests - allow_aarch64_sve_tests / target does not support SVE - memory tagging unsupported Consequently, we mostly use the simple substitution: ... clean_restart $binfile -> clean_restart gdb_load $binfile ...
14 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/i386*.expTom de Vries14-15/+15
Fix clean_restart <absolute filename> in gdb.arch/i386*.exp. Tested on x86_64-linux, with target board unix/-m32 and gcc 15. The only unsupported test-case is gdb.arch/i386-avx512.exp, which isn't changed by this commit.
14 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/amd64*.expTom de Vries12-22/+23
Fix clean_restart <absolute filename> in gdb.arch/amd64*.exp. Tested on x86_64-linux, with kernel version 6.16.3. The only unsupported test-case is gdb.arch/amd64-lam.exp, which isn't changed by this commit.
14 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.adaTom de Vries18-18/+18
Fix clean_restart <absolute filename> in the test-cases in gdb.ada. Tested on x86_64-linux with gcc 14.
2025-09-03gdb/testsuite] Fix clean_restart <absolute filename> in gdb.compileTom de Vries2-4/+5
Fix clean_restart <absolute filename> in the test-cases in gdb.compile. Tested on x86_64-linux, fedora rawhide.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.cpTom de Vries8-10/+11
Fix clean_restart <absolute filename> in the test-cases in gdb.cp. Tested on x86_64-linux.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.debuginfodTom de Vries3-11/+12
Fix clean_restart <absolute filename> in the test-cases in gdb.debuginfod. Tested on x86_64-linux.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.disasmTom de Vries4-4/+4
Fix clean_restart <absolute filename> in the test-cases in gdb.disasm. The changed test-cases: - gdb.disasm/am33.exp - gdb.disasm/hppa.exp - gdb.disasm/mn10300.exp - gdb.disasm/sh3.exp are unsupported for me, but the changes are trivial.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.dwarf2Tom de Vries25-31/+38
Fix clean_restart <absolute filename> in the test-cases in gdb.dwarf2. Tested on x86_64-linux using gcc-14. Tested these test-cases on x86_64-linux with target board unix/-m32: - gdb.dwarf2/valop.exp - gdb.dwarf2/callframecfa.exp - gdb.dwarf2/implptr.exp - gdb.dwarf2/watch-notconst.exp - gdb.dwarf2/pieces.exp - gdb.dwarf2/pieces-optimized-out.exp Tested these test-cases on x86_64-linux with target board fission-dwp: - gdb.dwarf2/dwp-symlink.exp - gdb.dwarf2/dwp-sepdebug.exp Tested test-case gdb.dwarf2/gdb-index-tilde.exp on x86_64-linux by disabling a too strict home directory check, see PR testsuite/33364.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.fortranTom de Vries4-5/+5
Fix clean_restart <absolute filename> in the test-cases in gdb.fortran. Tested on x86_64-linux, with gcc 14.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.gdbTom de Vries2-2/+3
Fix clean_restart <absolute filename> in the test-cases in gdb.gdb. Tested on x86_64-linux.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.guileTom de Vries4-6/+9
Fix clean_restart <absolute filename> in the test-cases in gdb.guile. Tested on x86_64-linux.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.linespecTom de Vries2-2/+2
Fix clean_restart <absolute filename> in the test-cases in gdb.linespec. Tested on x86_64-linux.
2025-09-03[gdb/testsuite] Fix mi_clean_restart <absolute filename> in gdb.miTom de Vries91-97/+97
Fix mi_clean_restart <absolute filename> in the test-cases in gdb.mi. Tested on x86_64-linux. Also tested test-case gdb.mi/mi-dprintf.exp with target boards native-gdbserver and native-extended-gdbserver. Since test-case gdb.mi/mi-regs.exp requires istarget "sparc-*-*", I didn't test the trivial change in that test-case.
2025-09-03[gdb/testsuite] Fix mi_clean_restart <absolute filename> in gdb.traceTom de Vries5-15/+9
Fix mi_clean_restart <absolute filename> in the test-cases in gdb.trace. Tested on x86_64-linux, with target boards unix, native-gdbserver and native-extended-gdbserver.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.multiTom de Vries15-26/+29
Fix clean_restart <absolute filename> in the test-cases in gdb.multi. Tested on x86_64-linux.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.objcTom de Vries3-3/+3
Fix clean_restart <absolute filename> in the test-cases in gdb.objc. Tested on x86_64-linux, using 'lappend options "nowarnings"' in gdb_compile_shlib_pthreads. See also PR testsuite/24807.
2025-09-03[gdb/testsuite] Fix clean_restart in gdb.opencl/callfuncs.expTom de Vries1-3/+4
In test-case gdb.opencl/callfuncs.exp I noticed: ... clean_restart [standard_testfile $testfile] ... This doesn't have the desired effect of starting gdb with $testfile because standard_testfile doesn't return anything. Fix this by using "clean_restart $testfile". While we're at it: - move standard_testfile to the start of the file - drop the redundant 'set testfile "callfuncs"' - use standard_testfile .cl to properly define $srcfile - use $srcfile instead of $testfile.cl Tested on x86_64-linux, using the demonstrator patch in PR testsuite/33363. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33363
2025-09-03gdb/testsuite: Fix gdb.base/gcore-memory-usage with address sanitizerGuinevere Larsen1-11/+14
The test gdb.base/gcore-memory-usage is meant to show that the memory requirements of GDB's gcore command don't grow with the memory usage of the inferior. It was using hardcoded values for memory, but the values were too small when building GDB with address sanitizer. This commit fixes one of the failures by increasing the limit on the first gcore call. But, rather than just increasing the hardcoded limit for the second call, we instead save the amount of memory used in the first call and ensure that the second call doesn't use more memory than the first. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33148 Approved-By: Tom de Vries <tdevries@suse.de>
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.optTom de Vries3-6/+6
Fix clean_restart <absolute filename> in the test-cases in gdb.opt. Tested on x86_64-linux using gcc 14.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.perfTom de Vries6-6/+6
Fix clean_restart <absolute filename> in the test-cases in gdb.perf. Tested on x86_64-linux using check-perf.
2025-09-03[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.pythonTom de Vries18-33/+46
Fix clean_restart <absolute filename> in the test-cases in gdb.python. Tested on x86_64-linux.
2025-09-02[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.replayTom de Vries1-4/+2
Fix clean_restart <absolute filename> in the test-case in gdb.replay. Tested on x86_64-linux, with target boards unix, native-gdbserver and native-extended-gdbserver.
2025-09-02[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.reverseTom de Vries6-6/+7
Fix clean_restart <absolute filename> in the test-cases in gdb.reverse. Tested on: - x86_64-linux, target boards unix and unix/-m32 - aarch64-linux - ppc64le-linux - s390x-linux
2025-09-02[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.rocmTom de Vries9-9/+18
Fix clean_restart <absolute filename> in the test-cases in gdb.rocm. Since these test-cases are unsupported for me, do the simple substitution: ... clean_restart $binfile -> clean_restart gdb_load $binfile ...