| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
A couple of ".tcl" files in gdb.dwarf2 escaped notice during the
"require" refactoring. This patch fixes these to use "require" rather
than if/return.
|
|
When the changes on the remote protocol are made,
we want to test all the corner cases to prevent
regressions. Currently it can be tricky to simulate
some corner case conditions that would expose possible
regressions. When I want to add or change the remote
protocol packet, I need to hack gdbserver to send a
corrupted packet or an error to make sure GDB is able
to handle such a case.
This test makes it easy to send a corruped packet or
an error message to GDB using the gdbreplay tool and
check GDB deals with it as we expect it to.
This test starts a communication with gdbsever setting
the remotelog file. Then, it modifies the remotelog with
update_log proc, injects an error message instead of
the expected replay to the vMustReplyEmpty packet in order
to test GDB reacts to the error response properly. After
the remotelog modification, this test restarts GDB and starts
communication with gdbreply instead of the gdbserver using
the remotelog.
Add a lib/gdbreplay-support.exp. update_log proc matches lines
from GDB to gdbserver in a remotelogfile. Once a match is found then
the custom line is used to build a replacement line to send from
gdbserver to GDB.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
With test-case gdb.python/py-mi-notify.exp and python 3.4, I occasionally run
into:
...
python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })
&"python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })\n"
=-test-notification,data2="2",data1="1"
^done
(gdb)
FAIL: $exp: python notification, with additional data (unexpected output)
...
In contrast, a passing version looks like:
...
python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })
&"python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })\n"
=-test-notification,data1="1",data2="2"
^done
(gdb)
PASS: gdb.python/py-mi-notify.exp: python notification, with additional data
...
The python method "gdb.notify_mi(name, data)" has parameter data which is a
dictionary, and it iterates over that dictionary.
The problem is that dictionaries are only guaranteed to be iterating in
insertion order starting python 3.7 (though cpython does this starting python
3.6).
Fix this in the same way as in commit 362a867f2ac ("[gdb/testsuite] Handle
unordered dict in gdb.python/py-mi-cmd.exp"): by allowing the alternative
order.
Tested on x86_64-linux.
|
|
This changes the help command to use the new command style when
displaying text like:
List of "catch" subcommands:
As a side effect, this mildly -- but not hugely -- cleans up some i18n
issues in help_list. The header comment for that function is also
changed to the gdb style.
Finally, this function used to print something like:
Type "help catch" followed by catch subcommand name for full documentation.
The second "catch" here seems redundant to me, so this patch removes
it.
|
|
Add comments to the assembler generated by the DWARF assembler that
builds the line table. I found these comments useful when debugging
issues with the line table parsing.
This patch should make no difference to what is being tested. The
test binaries should be unchanged after this commit.
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
Say we use the executable of test-case gdb.tui/tui-missing-src.exp like this:
...
$ gdb.sh -q -tui outputs/gdb.tui/tui-missing-src/tui-missing-src \
-ex "b f2"\
-ex run
...
(from a directory not containing a file called main.c to make sure that the
missing source stays missing) and then issue finish:
...
(gdb) finish
Run till exit from #0 f2 (x=4)
at f2.c:5
0x0000000000400570 in main ()
at main.c:7
Value returned is $1 = 13
(gdb)
...
and use control-<minus> to decrease the font size (IOW increase the $LINES and
$COLUMNS) on the terminal, we get:
...
gdb/tui/tui-winsource.c:340: internal-error: refresh_window: \
Assertion `pad_x + view_width <= pad_width || m_pad.get () == nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
The tui_source_window_base class has variable m_pad which keeps track of a
curses pad that is used to display the source code or disassembly efficiently.
The assert in tui_source_window_base::refresh_window triggers while preparing
to display part of the pad.
The problem is that the window is in a state in which the pad is not used,
because m_content.empty () == true. Instead, it simply shows
"[ No Source Available ]".
Fix this by bailing out of tui_source_window_base::refresh_window before
accessing the m_pad variable, if m_content.empty () == true.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR tui/32592
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32592
|
|
In commit 64a97606 ("Support template lookups in
strncmp_iw_with_mode"), gdb was changed so that a command like "break
func<templ>" would match instantiations like "func<templ<int>>".
The new indexer does not support this and so this is a regression.
This went unnoticed because gdb.linespec.cpcompletion.exp puts all
these functions into the main file, and this CU is expanded early.
This patch fixes the bug by changing the cooked index entry comparison
function. It also updates the test to fail without this fix.
Regression tested on x86-64 Fedora 40.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32482
|
|
While stepping through gdb.reverse/time-reverse.exp I realized that we're
recording the instructions for resolving the PLT entries for functions time
and syscall, while that's not really the focus of the test-case.
Limit the scope of the test, by calling the functions once before starting
to record.
Also call "info record" after recording to make it clear how many
instructions were recorded.
On x86_64-linux, before this patch (but with info record added), we have:
...
$ grep "Log contains" gdb.log
Log contains 750 instructions.
Log contains 1218 instructions.
...
and with this patch we have:
...
$ grep "Log contains" gdb.log
Log contains 24 instructions.
Log contains 19 instructions.
...
Tested on x86_64-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Consider test-case gdb.base/return-3.exp:
...
$ gdb -q outputs/gdb.base/return-3/return-3
Reading symbols from outputs/gdb.base/return-3/return-3...
(gdb)
...
Function bar is an inlined function, and consequently we cannot return from
it:
...
(gdb) b bar
Breakpoint 1 at 0x4006ac: file return-3.c, line 25.
(gdb) r
Starting program: return-3
...
Breakpoint 1, bar () at return-3.c:25
25 c++;
(gdb) return
Can not force return from an inlined function.
(gdb)
...
However, function foo is not an inline function, and we should be able to
return from it, but we get the same error message:
...
(gdb) up
31 bar ();
(gdb) return
Can not force return from an inlined function.
(gdb)
...
Fix this by using the selected frame rather than the current frame in
return_command, such that we get instead:
...
(gdb) up
31 bar ();
(gdb) return
40 printf ("%d\n", c);
(gdb)
...
Tested on aarch64-linux.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
PR cli/32479
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32479
|
|
This removes gnatmake_version_at_least in favor of using the more
flexible gnat_version_compare. I think these two version numbers
should be the same, as gnatmake is shipped with the compiler.
|
|
While testing gnat-llvm, I found a gdb crash when applying 'length to
a non-array type. This patch fixes the crash.
|
|
I found another Ada test case where gnat-llvm optimizes away the local
variables. This patch applies the same fix to it as previous patches.
|
|
On arm-linux (ubuntu 24.04 with gcc 13.3.0) with target board unix/-marm and
test-case gdb.base/branch-to-self.exp I run into:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
si^M
0x0040058c 38 for (;;); /* loop-line */^M
(gdb) FAIL: $exp: single-step: si
...
In contrast, on the same machine but with debian testing and gcc 14.2.0 we have:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
si^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: stepi
...
The difference is in the instruction(s) generated for the loop.
In the passing case, we have:
...
588: eafffffe b 588 <main+0x24>
...
and in the failing case:
...
588: e320f000 nop {0}
58c: eafffffd b 588 <main+0x24>
...
The purpose of this part of the test-case is to:
- generate a branch instruction that jumps to itself, and
- set a breakpoint on it, and check that stepi-ing from that breakpoint
triggers the breakpoint again.
As we can see, in the failing case we failed to generate a branch instruction
that jumps to itself, and consequently we cannot expect to hit the breakpoint
again after issuing a single si.
Fix this by issuing stepi until we hit the breakpoint.
Tested on arm-linux.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
|
When running test-case gdb.base/fission-macro.exp on openSUSE Tumbleweed
(using gcc 14) with target board unix/-m32, I get:
...
(gdb) info macro FIRST^M
Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:0^M
-DFIRST=1^M
(gdb) FAIL: $exp: \
dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST
...
instead of the expected:
...
(gdb) info macro FIRST^M
Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:18^M
(gdb) PASS: $exp: \
dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST
...
A dwarf-5 .debug_str_offsets section starts with a header consisting of:
- an initial length (4 bytes for 32-bit and 12 bytes for 64-bit),
- a 2 byte version string, and
- 2 bytes padding
so in total 8 bytes for 32-bit and 16 bytes for 64-bit.
This offset is calculated here in dwarf_decode_macros:
...
str_offsets_base = cu->header.addr_size;
...
which is wrong for both dwarf-5 cases (and also happens to be wrong for
dwarf-4).
Fix this by computing str_offsets_base correctly for dwarf-5, for both the
32-bit and 64-bit case.
Likewise, fix this for dwarf-4, using str_offsets_base 0. We can only test
this with gcc-15, because gcc 14 and earlier don't have the fix for
PR debug/115066.
Tested on x86_64-linux.
Tested test-case using a current gcc trunk build, and gcc 14.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/31897
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31897
|
|
The stated intention of test-case gdb.base/lineinc.exp is:
...
# Test macro handling of #included files.
...
However, the test-case does not produce any macro debug information.
Fix this by adding macros in the compilation flags.
Tested on x86_64-linux.
|
|
The newly added test gdb.base/backtrace-through-cu-nodebug.exp had a
problem in the call to gdb_compile, that caused the .o files to be
outputted in the GDB file tree. This commit fixes the issues in the calls.
Reported-By: Tom de Vries <tdevries@suse.de>
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
On arm-linux, with target board unix/-mthumb, we get:
...
(gdb) PASS: gdb.cp/non-trivial-retval.exp: continue to breakpoint: Break here
p f1 (i1, i2)^M
$1 = {a = -136274256}^M
(gdb) FAIL: gdb.cp/non-trivial-retval.exp: gdb-command<p f1 (i1, i2)>
...
This is not a problem with the inferior call, which works fine:
...
(gdb) p f1 (23, 100)
$3 = {a = 123}
...
but instead it's a problem with the location information:
...
(gdb) p i1
$1 = -136274356
(gdb) p i2
$2 = 100
...
which tells us to find the value of i1 in (DW_OP_fbreg: -12).
The test-case passes if we drop -fvar-tracking, in which case the debug info
tells us to find the value of i1 in (DW_OP_fbreg: -20).
This is with gcc 13.3.0 on Ubuntu 24.04. With gcc 14.2.0 on Debian testing,
the code is the same, but -fvar-tracking does use the correct
'(DW_OP_fbreg: -20)'.
There seems to be some bugfix in -fvar-tracking for gcc 14.
Workaround the bug by using constants 23 and 100 instead of i1 and i2 when
using -fvar-tracking and gcc < 14.
Tested on arm-linux.
PR testsuite/32549
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32549
|
|
Tom de Vries reported that some of the test for the vmov[u|a]p[s|d] were
failing. In my machine xmm3 was consistently set to 0x54, but apparently
that is different depending on the system. This commit zeroes out xmm3
at the start of the test instead.
While debugging the test failures, I also noticed an issue where the
recording wasn't saving all the required memory. That happened because
vmovs[s|d] shares its opcode with vmovap[s|d], meaning they seem to
share code paths, but the latter encodes memory modification size on
VEX.L whereas the former encodes in VEX.pp. So this commit fixed that,
and made the relevant tests more robust and complete.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32561
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
This commit fixes an issue with the commit:
commit d3d13bf876aae425ae0eff2ab0f1af9f7da0264a
Date: Thu Apr 25 09:36:43 2024 +0100
gdb: add gdbarch method to get execution context from core file
The above commit improves GDB's ability to display inferior arguments
when opening a core file, however, if an argument includes white
space, then this is not displayed as well as it should be. For
example:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) show args
Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e".
(gdb)
Notice the 'Core was generated by ...' line. In this case it is not
clear if the "e e e e e" is a single argument containing white space,
or 5 single arguments.
But when we 'show args' it is immediately clear that this is a single
argument, as the white space is now escaped.
This problem was caused by the above commit building the argument
string itself, and failing to consider white space escaping.
This commit changes things around, first we place the arguments into
the inferior, then, to print the 'Core was generated by ...' line, we
ask the inferior for the argument string. In this way the quoting is
handled just as it is for 'show args'. The initial output is now:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f4f007af625 in raise () from /lib64/libc.so.6
(gdb)
Much better. The existing test is extended to cover this case.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fedora has been carrying this test since back in the Project Archer
days. A change back then caused GDB to stop being able to backtrace when
only some of the object files had debug information. Even though the
changed code never seems to have made its way into the main GDB project,
I think it makes sense to bring the test along to ensure something like
this doesn't pass unnoticed.
Co-Authored-By: Jan Kratochvil <jan@jankratochvil.net>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Sometimes, in the GDB testsuite, we want to test the ability of specific
unwinders to handle some piece of code. Usually this is done by trying
to outsmart GDB, or by coercing the compiler to remove information that
GDB would rely on. Both approaches have problems as GDB gets smarter
with time, and that compilers might differ in version and behavior, or
simply introduce new useful information. This was requested back in 2003
in PR backtrace/8434.
To improve our ability to thoroughly test GDB, this patch introduces a
new maintenance command that allows a user to disable some unwinders,
based on either the name of the unwinder or on its class. With this
change, it will now be possible for GDB to not find any frame unwinders
for a given frame, which would previously cause GDB to assert. GDB will
now check if any frame unwinder has been disabled, and if some has, it
will just error out instead of asserting.
Unwinders can be disabled or re-enabled in 3 different ways:
* Disabling/enabling all at once (using '-all').
* By specifying an unwinder class to be disabled (option '-class').
* By specifying the name of an unwinder (option '-name').
If you give no options to the command, GDB assumes the input is an
unwinder class. '-class' would make no difference if used, is just here
for completeness.
This command is meant to be used once the inferior is already at the
desired location for the test. An example session would be:
(gdb) start
Temporary breakpoint 1, main () at omp.c:17
17 func();
(gdb) maint frame-unwinder disable ARCH
(gdb) bt
\#0 main () at omp.c:17
(gdb) maint frame-unwinder enable ARCH
(gdb) cont
Continuing.
This commit is a more generic version of commit 3c3bb0580be0,
and so, based on the final paragraph of the commit message:
gdb: Add switch to disable DWARF stack unwinders
<...>
If in the future we find ourselves adding more switches to disable
different unwinders, then we should probably move to a more generic
solution, and remove this patch.
this patch also reverts 3c3bb0580be0
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8434
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
temp adding completion
|
|
When running test-case gdb.dwarf2/implptr.exp on target board unix/-m32, we
get:
...
(gdb) PASS: gdb.dwarf2/implptr.exp: print ***l in implptr:bar
break implptr.c:34^M
No compiled code for line 34 in file "implptr.c".^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: $exp: set baz breakpoint for implptr (got interactive prompt)
...
This is a regression since commit dcaa85e58c4 ("gdb: reject inserting
breakpoints between functions").
The .debug_line info does not contain an entry with a line number lower than
36, so gdb cannot map it to an address.
Fix this by setting a breakpoint at the function containing line 34 instead.
Tested on x86_64-linux.
PR testsuite/32477
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32477
|
|
Once in a while, I run into a timeout in test-case
gdb.threads/step-over-thread-exit.exp:
...
(gdb) continue^M
Continuing.^M
[New Thread 0xfffff7cff1a0 (LWP 2874854)]^M
^M
Thread 97 "step-over-threa" hit Breakpoint 2, 0x0000000000410314 in \
my_exit_syscall () at gdb/testsuite/lib/my-syscalls.S:74^M
74 SYSCALL (my_exit, __NR_exit)^M
(gdb) [Thread 0xfffff7cff1a0 (LWP 2874853) exited]^M
FAIL: $exp: step_over_mode=displaced: non-stop=on: target-non-stop=on: \
schedlock=off: cmd=continue: ns_stop_all=0: iter 95: continue (timeout)
...
I can reproduce it more frequently by running with taskset -c <slow core id>.
Fix this by using -no-prompt-anchor.
This requires us to add -no-prompt-anchor to proc gdb_test_multiple.
Tested on aarch64-linux.
PR testsuite/32489
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32489
|
|
I happened to notice that "help add-inferior" said:
-execFILENAME
FILENAME is the file name of the executable to use as the
main program.
This is missing a space after "-exec". This patch fixes the bug.
If ok'd on time I plan to check this in to the gdb-16 branch as well.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
The test gdb.reverse/i386-avx-reverse.exp requires CPU to have AVX
instructions but it actually also uses AVX2 instructions (like
vpcmpeqd). This caused the test to fail on CPUs that have AVX but not
AVX2.
This commit adds check for AVX2.
Tested on Intel Xeon CPU E3-1265L (no AVX2) and Intel Core i7-1355U
(has AVX2).
|
|
The custom linetable functionality in GDB's JIT Interface has been broken
since commit 1acc9dca423f78e44553928f0de839b618c13766.
In that commit, linetables were made independent from the objfile, which
requires objfile->section_offsets to be initialized. However, section_offsets
were never initialized in objfiles generated by GDB's JIT Interface
with custom jit-readers, leading to GDB crashes when stepping into JITed code
blocks with the following command already executed:
jit-reader-load libmygdbjitreader.so
This patch fixes the issue by initializing the minimum section_offsets required
for linetable parsing procedures.
A minimal test is included. The test sets up some very simple line
table information, which is enough to trigger the bug. However, the
line table information is crafted such that none of the line table
entries will end up being displayed in GDB's output when the test is
run, as such, none of the expected output actually changes.
It might be nice in the future to extend some of the jit tests to
actually test hitting line table entries added via the jit reader.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit adds support for the following types of instructions
relating to floating poitn values: add, mul, sub, min, div, max.
These are supported with packed or single values, and single or double
precision.
Some of the instructions had opcode clashes, however, considering the
mechanics of recording the registers is the same on both instructions,
this is just marked with a comment.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
This commit adds support for the AVX instructions vunpck[l|h][ps|pd]
instructions, which was pretty straightforward.
This commit also fixes a mistake in the test, where "record stop" was
used after the recording was already stopped, if it failed during
vpunpck_test recording. It also improved the documentation at the start
of the relevant .c function.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
This commit updates GDB's record-full to be able to record vmov[ss|sd]
and vmov [u|a] [ps|pd] AVX instructions, and tests for them.
Unlike the vmovdq[u|a] instructions, the aligned and unalgined versions
of vmov?[ps|pd] have different opcodes. The mechanics of recording them
is the same, but the aligned version has opcodes 0x28 and 0x29, while
the unaligned has the same opcode as vmov[ss|sd] instruction, 0x10 and
0x11.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Colors can be specified as "none" for terminal's default color, as a name of
one of the eight standard colors of ISO/IEC 6429 "black", "red", "green", etc.,
as an RGB hexadecimal tripplet #RRGGBB for 24-bit TrueColor, or as an
integer from 0 to 255. Integers 0 to 7 are the synonyms for the standard
colors. Integers 8-15 are used for the so-called bright colors from the
aixterm extended 16-color palette. Integers 16-255 are the indexes into xterm
extended 256-color palette (usually 6x6x6 cube plus gray ramp). In
general, 256-color palette is terminal dependent and sometimes can be
changed with OSC 4 sequences, e.g. "\033]4;1;rgb:00/FF/00\033\\".
It is the responsibility of the user to verify that the terminal supports
the specified colors.
PATCH v5 changes: documentation fixed.
PATCH v6 changes: documentation fixed.
PATCH v7 changes: rebase onto master and fixes after review.
PATCH v8 changes: fixes after review.
|
|
gnat-llvm seems to be a bit more aggressive about eliminating unused
variables. This patch improves the test results a tiny bit by
arranging for some variables to appear to be used.
Note the copyright dates on the new files are done that way because I
simply copied existing files.
|
|
With test-case gdb.cp/non-trivial-retval.exp on riscv64-linux, I ran into:
...
(gdb) finish^M
Run till exit from #0 f1 (i1=i1@entry=23, i2=i2@entry=100) \
at non-trivial-retval.cc:34^M
main () at non-trivial-retval.cc:163^M
163 B b = f2 (i1, i2);^M
Value returned is $6 = {a = -5856}^M
(gdb) FAIL: $exp: finish from f1
...
where "Value returned is $6 = {a = 123}" is expected.
The problem is that gdb thinks that the return value is in $a0:
...
$ gdb -q -batch non-trivial-retval \
-ex "b f1" \
-ex run \
-ex "set debug riscv infcall on" \
-ex finish
Breakpoint 1 at 0x80a: file non-trivial-retval.cc, line 34.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/riscv64-linux-gnu/libthread_db.so.1".
Breakpoint 1, f1 (i1=i1@entry=23, i2=i2@entry=100) at non-trivial-retval.cc:34
34 {
[riscv-infcall] riscv_return_value: \
[R] type: 'A', length: 0x4, alignment: 0x4, register a0
[riscv-infcall] riscv_return_value: \
[R] type: 'A', length: 0x4, alignment: 0x4, register a0
[riscv-infcall] riscv_return_value: \
[R] type: 'A', length: 0x4, alignment: 0x4, register a0
main () at non-trivial-retval.cc:163
163 B b = f2 (i1, i2);
Value returned is $1 = {a = -3568}
...
while $a0 actually contains a pointer to the returned value 123:
...
(gdb) p /x $a0
$3 = 0x3ffffff210
(gdb) p *((unsigned int *)$a0)
$5 = 123
...
The returned type is:
...
class A
{
public:
A () {}
A (A &obj);
int a;
};
...
which is a C++ aggregate with a nontrivial (because it's user-defined) copy
constructor:
According to the ABI [1], indeed this is returned by reference:
...
Values are returned in the same manner as a first named argument of the same
type would be passed. If such an argument would have been passed by
reference, the caller allocates memory for the return value, and passes the
address as an implicit first parameter.
...
Aggregates larger than 2×XLEN bits are passed by reference and are replaced in
the argument list with the address, as are C++ aggregates with nontrivial copy
constructors, destructors, or vtables.
...
Fix this in riscv_call_arg_scalar_int by checking for
language_pass_by_reference ().trivially_copy_constructible.
The vtable case is explictly mentioned in the ABI, but AFAIU already covered
by the nontrivial copy constructor case.
The nontrivial destructor case is also not supported, but the testsuite
doesn't seem to trigger this.
Fix this by:
- extending the test-case to cover this scenario, and
- fixing it in riscv_call_arg_scalar_int by checking for
language_pass_by_reference ().trivially_destructible.
Tested on riscv64-linux.
PR tdep/32152
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32152
Approved-By: Andrew Burgess <aburgess@redhat.com>
[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc
|
|
On riscv64-linux, with test-case gdb.rust/completion.exp I run into the
following timeout:
...
(gdb) complete break pars^M
FAIL: gdb.rust/completion.exp: complete break pars (timeout)
...
Replaying the scenario outside the testsuite show us that the command takes
~13 seconds:
...
$ gdb -q -batch -x gdb.in
...
2025-01-08 12:23:46.853 - command started
+complete break pars
break parse.rs
break parse_printf_format
break parse_running_mmaps_unix.rs
break parser.rs
2025-01-08 12:23:59.600 - command finished
Command execution time: 12.677752 (cpu), 12.748565 (wall)
...
while the timeout is 10 seconds.
The riscv64 processor on the server (cfarm91) is not fast (a fair amount of
the skip_huge_test test-cases times out), but something else is going on as
well.
For x86_64-linux, roughly measuring the size of debug info in the exec get us:
...
$ readelf -wi outputs/gdb.rust/completion/completion | wc -l
2007
...
while on the riscv64 server I get:
...
$ readelf -wi outputs/gdb.rust/completion/completion | wc -l
1606950
...
So it seems reasonable that the test is somewhat slower on riscv64.
Fix this by using timeout factor 2.
Tested on riscv64-linux and x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
ASAN_OPTIONS=verify_asan_link_order=0
After building gdb with asan, and running test-case
gdb.trace/basic-libipa.exp, I got:
...
(gdb) run ^M
Starting program: basic-libipa ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
==7705==ASan runtime does not come first in initial library list; you should \
either link runtime to your application or manually preload it with \
LD_PRELOAD.^M
[Inferior 1 (process 7705) exited with code 01]^M
(gdb) FAIL: gdb.trace/basic-libipa.exp: runto: run to main
...
Fix this in the same way as in commit 75948417af8 ("[gdb/testsuite] Run two
test-cases with ASAN_OPTIONS=verify_asan_link_order=0").
Tested on x86_64-linux.
|
|
I happened to notice that the Ada compiler emitted a warning when
compiling a couple of DAP tests. This wasn't intentional, and this
patch renames the functions to match the filename.
|
|
On a system with gcc 14.2.0 and gnatmake 13.3.0 I run into:
...
(gdb) PASS: gdb.ada/scalar_storage.exp: print V_LE
get_compiler_info: gcc-14-2-0
print V_BE^M
$2 = (value => 126, another_value => 12, color => red)^M
(gdb) FAIL: gdb.ada/scalar_storage.exp: print V_BE
...
The test-case contains a corresponding kfail:
...
# This requires a compiler fix that is in GCC 14.
if {[gcc_major_version] < 14} {
setup_kfail "DW_AT_endianity on enum types" *-*-*
}
...
which doesn't trigger because it checks the gcc version rather than the
gnatmake version.
Fix this by checking the gnatmake version instead.
Tested on aarch64-linux and x86_64-linux.
|
|
I ran test-case gdb.base/gstack.exp on a machine with kernel.yama.ptrace_scope
set to 1 and ran into:
...
PASS: gdb.base/gstack.exp: spawn gstack
ptrace: Operation not permitted.^M
GSTACK-END^M
PASS: gdb.base/gstack.exp: gstack exits with no error
PASS: gdb.base/gstack.exp: gstack's exit status is 0
FAIL: gdb.base/gstack.exp: got backtrace
...
Fix this by requiring can_spawn_for_attach.
Tested on x86_64-linux.
|
|
gdb.reverse/test_ioctl_TCSETSW.exp
I ran test-case gdb.reverse/test_ioctl_TCSETSW.exp on riscv64-linux, and got:
...
(gdb) record full^M
Process record: the current architecture doesn't support record function.^M
(gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: record full
...
Fix this by requiring supports_process_record.
Tested on riscv64-linux and x86_64-linux.
|
|
!supports_catch_syscall
I ran test-case gdb.base/reset-catchpoint-cond.exp on riscv64-linux, and got:
...
(gdb) catch syscall write^M
The feature 'catch syscall' is not supported on this architecture yet.^M
(gdb) FAIL: $exp: mode=syscall: catch syscall write
...
Fix this by checking for supports_catch_syscall.
Tested on riscv64-linux and x86_64-linux.
|
|
This renames two maint commands, removing a hyphen from
"check-symtabs" and "check-psymtabs"; that is, moving them under the
existing "maint check" prefix.
Regression tested on x86-64 Fedora 40.
Reviewed-By: Tom de Vries <tdevries@suse.de>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Iain pointed out a crash in the DWARF indexer when run on a certain D
program. The DWARF in this case has a nameless enum class; this
causes an assertion failure.
This patch arranges to simply ignore such types. The fact that an
enum class is nameless in this case appears to be a compiler bug.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32518
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
Since commit "gdbserver: allow the --debug command line option to take a
value", gdbserver no longer supports
--debug
--remote-debug
--event-loop-debug.
Instead, --debug now takes a comma separated list of components.
The make check parameter GDBSERVER_DEBUG doesn't support these changes
yet. This patch fixes this, by adding the --debug gdbserver arguments,
as "debug-threads", "debug-remote", "debug-event-loop" or "debug-all" for
GDBSERVER_DEBUG. Replay logging is still enabled by adding the
"replay" GDBSERVER_DEBUG argument. We can also configure "all" to
enable all of the available options.
Now, for instance, we can use it as follows:
make check GDBSERVER_DEBUG="debug-remote,debug-event-loop,replay" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp"
or simply
make check GDBSERVER_DEBUG="all" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp"
to enable all debug options.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR cli/32525 reports that a variable with this DWARF:
..
<2><423>: Abbrev Number: 14 (DW_TAG_variable)
<424> DW_AT_name : var1867
<42a> DW_AT_type : <0x2f8>
<42e> DW_AT_const_value : 8 byte block: 0 0 0 0 0 0 0 0
...
is not shown by info locals.
Fix this by handling LOC_CONST_BYTES in iterate_over_block_locals.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32525
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The DAP initialize request has a "linesStartAt1" option, where the
client can indicate that it prefers whether line numbers be 0-based or
1-based.
This patch implements this. I audited all the line-related code in
the DAP implementation.
Note that while a similar option exists for column numbers, gdb
doesn't handle these yet, so nothing is done here.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468
|
|
Consider this Rust tuple:
let tuple_tuple = ((23i32, 24i32), 25i32);
Here, the value is a tuple whose first element is also a tuple.
You should be able to print this with:
(gdb) print tuple_tuple.0.1
However, currently the Rust lexer sees "0.1" as a floating-point
number.
This patch fixes the problem by introducing a special case in the
lexer: when parsing a field expression, the parser informs the lexer
that a number should be handled as a decimal integer only.
This change then lets us remove the decimal integer special case from
lex_number.
v2: I realized that the other DECIMAL_INTEGER cases aren't needed any
more.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32472
|
|
This removes the "then" keyword from the test suite. Andrew did this
once before, but some new ones crept in.
This also adds braces to the "if" conditions and normalizes the
failures to just use "return".
|
|
A recent discussion about what commands are allowed during
gdb.Breakpoint.stop, made me wonder if there would be less restrictions if
we'd do those commands as part of a breakpoint command list instead.
Attribute gdb.Breakpoint.commands is a string with gdb commands, so I
tried implementing a new class PyCommandsBreakpoint, derived from
gdb.Breakpoint, that supports a py_commands method.
My original idea was to forbid setting PyCommandsBreakpoint.commands, and do:
...
def py_commands(self):
print("VAR: %d" % self.var)
self.var += 1
gdb.execute("continue")
...
but as it turns out 'gdb.execute("continue")' does not behave the same way as
continue. I've filed PR python/32454 about this.
So the unsatisfactory solution is to first execute
PyCommandsBreakpoint.py_commands:
...
def py_commands(self):
print("VAR: %d" % self.var)
self.var += 1
...
and then:
...
self.commands = "continue"
...
I was hoping for a better outcome, but having done the work of writing this, I
suppose it has use as a test-case, perhaps also as an example of how to work
around PR python/32454.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32454
|
|
On s390x-linux, with test-case gdb.base/finish-pretty.exp I ran into:
...
(gdb) finish
Run till exit from #0 foo () at finish-pretty.c:28
main () at finish-pretty.c:40
40 return v.a + v.b;
Value returned has type: struct s. Cannot determine contents
(gdb) FAIL: $exp: finish foo prettyprinted function result
...
The function being finished is foo, which returns a value of type struct s.
The ABI [1] specifies:
- that the value is returned in a storage buffer allocated by the caller, and
- that the address of this buffer is passed as a hidden argument in r2.
GDB fails to print the value when finishing foo, because it doesn't know the
address of the buffer.
Implement the gdbarch_get_return_buf_addr hook for s390x to fix this.
This is based on ppc_sysv_get_return_buf_addr, the only other implementation
of gdbarch_get_return_buf_addr. For readability I've factored out
dwarf_reg_on_entry.
There is one difference with ppc_sysv_get_return_buf_addr: only
NO_ENTRY_VALUE_ERROR is caught. If this patch is approved, I intend to submit
a follow-up patch to fix this in ppc_sysv_get_return_buf_addr as well.
The hook is not guaranteed to work, because it attempts to get the value r2
had at function entry.
The hook can be called after function entry, and the ABI doesn't guarantee
that r2 is the same throughout the function.
Using -fvar-tracking adds debug information, which allows the hook to succeed
more often, and indeed after adding this to the test-case, it passes.
Do likewise in one more test-case.
Tested on s390x-linux.
Fixes:
- gdb.ada/finish-large.exp
- gdb.base/finish-pretty.exp
- gdb.base/retval-large-struct.exp
- gdb.cp/non-trivial-retval.exp
- gdb.ada/array_return.exp
AFAICT, I've also enabled the hook for s390 and from the ABI I get the
impression that it should work, but I haven't been able to test it.
[1] https://github.com/IBM/s390x-abi
|
|
The Linaro CI reported a regression on arm-linux in test-case
gdb.base/sigstep.exp following commit 7b46460a619 ("[gdb/symtab] Apply
workaround for PR gas/31115 a bit more") [1]:
...
(gdb) return^M
Make __default_sa_restorer return now? (y or n) n^M
Not confirmed^M
(gdb) FAIL: $exp: return from handleri: \
leave signal trampoline (got interactive prompt)
...
After installing package glibc-debuginfo and adding --with-separate-debug-dir
to the configure flags, I managed to reproduce the FAIL.
The regression seems to be a progression in the sense that the function name
for the signal trampoline is found.
After reading up on the signal trampoline [2] and the return command [3], my
understanding is that forced returning from the signal trampoline is
potentially unsafe, given that for instance the process signal mask won't be
restored.
Fix this by:
- rather than using the name, using "signal trampoline" in the query, and
- adding a warning about returning from a signal trampoline,
giving us:
...
(gdb) return^M
warning: Returning from signal trampoline does not fully restore pre-signal \
state, such as process signal mask.^M
Make signal trampoline return now? (y or n) y^M
87 dummy = 0; dummy = 0; while (!done);^M
(gdb) PASS: $exp: return from handleri: leave signal trampoline (in main)
...
Tested on x86_64-linux.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
[1] https://linaro.atlassian.net/browse/GNU-1459
[2] https://man7.org/linux/man-pages/man2/sigreturn.2.html
[3] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Returning.html
|
|
I ran make-check-all.sh with gdb.linespec/explicit.exp, and the only problems
were found with target board stabs.
With target board unix the test-case runs in two seconds, but with target
board stabs it takes 12 seconds due to a timeout.
Stabs support in gdb has been unmaintained for a while, and there's an ongoing
discussion to deprecate and remove it (PR symtab/31210).
It seems unnecessary to excercise this unmaintained feature in
make-check-all.sh, so drop it.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31210
|
