| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On s390x-linux, I get:
...
(gdb) print l^M
$29 = 0^M
(gdb) FAIL: gdb.base/store.exp: var doublest l; print old l, expecting -1
...
So, we're in wack_doublest trying to print l, which is a copy of parameter u:
...
register doublest l = u, r = v;
...
which does have the expected value:
...
(gdb) p u
$1 = -1
...
which is a long double, 16 bytes and looks like this:
...
(gdb) p /x u
$3 = 0xbfff0000000000000000000000000000
...
Parameter u is passed in two registers:
...
<2><6a5>: Abbrev Number: 15 (DW_TAG_formal_parameter)
<6a6> DW_AT_name : v
<69e> DW_AT_location : 6 byte block: 50 93 8 51 93 8 \
(DW_OP_reg0 (r0); DW_OP_piece: 8; DW_OP_reg1 (r1); DW_OP_piece: 8)
...
and indeed we find the msw in r0 and the lsw in r1:
...
(gdb) p /x $r0
$4 = 0xbfff000000000000
(gdb) p /x $r1
$5 = 0x0
(gdb)
...
Likewise, variable l consists of two registers:
...
<2><6b5>: Abbrev Number: 13 (DW_TAG_variable)
<6b6> DW_AT_name : l
<6be> DW_AT_location : 6 byte block: 68 93 8 69 93 8 \
(DW_OP_reg24 (f8); DW_OP_piece: 8; DW_OP_reg25 (f10); DW_OP_piece: 8)
...
and we find the same values there:
...
(gdb) p /x $f8
$6 = 0xbfff000000000000
(gdb) p /x $f10
$7 = 0x0
...
So, we get the expected results when fetching the value from two gprs, but not
when fetching the value from two fprs.
When fetching the values from the two fprs, we stumble upon a particularity of
the DWARF register numbers as defined by the s390x ABI [1]: dwarf register 24
maps to both floating-point register f8 (8 bytes), and vector register v8
(16 bytes).
In s390_dwarf_reg_to_regnum, it's determined which of the two is chosen, and
if available vector registers are preferred over floating-point registers, so
v8 is chosen, and used to fetch the value.
Since the size of the DW_OP_piece is 8 bytes, and the register size is 16
bytes, this bit in rw_pieced_value is activated:
...
/* If the piece is located in a register, but does not
occupy the entire register, the placement of the piece
within that register is defined by the ABI. */
bits_to_skip
+= 8 * gdbarch_dwarf2_reg_piece_offset (arch, gdb_regnum,
p->size / 8);
...
but since the default implemention default_dwarf2_reg_piece_offset does not
match the s390x ABI, we get the wrong answer.
This is a known problem, see FOSDEM 2018 presentation "DWARF Pieces And Other
DWARF Location Woes" [2].
Fix this by adding s390_dwarf2_reg_piece_offset, roughly implementing the same
logic as in s390_value_from_register.
Tested on s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://github.com/IBM/s390x-abi
[2] https://archive.fosdem.org/2018/schedule/event/dwarfpieces
|
|
In rw_pieced_value, when reading/writing part of a register, DW_OP_piece and
DW_OP_bit_piece are handled the same, but the standard tells us:
- DW_OP_piece: if the piece is located in a register, but does not occupy the
entire register, the placement of the piece within that register is defined
by the ABI.
- DW_OP_bit_piece: if the location is a register, the offset is from the least
significant bit end of the register.
Add a new hook gdbarch_dwarf2_reg_piece_offset that allows us to define the
ABI-specific behaviour for DW_OP_piece.
The default implementation of the hook is the behaviour of DW_OP_bit_piece, so
there should not be any functional changes.
Tested on s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add a new field "dwarf_location_atom op" to dwarf_expr_piece to keep track of
which dwarf_location_atom caused a dwarf_expr_piece to be added.
This is used in the following patch.
Tested on s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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>
|
|
loongarch_stopped_data_address() is a common function and will be used by
gdb and gdbserver, so move its definition from gdb/loongarch-linux-nat.c
to gdb/nat/loongarch-hw-point.c. This is preparation for later gdbserver
patch on LoongArch and is no effect for the current code.
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
loongarch_{get,remove}_debug_reg_state() are used as helper functions
by loongarch_linux_nat_target. We should move their definitions from
gdb/nat/loongarch-linux-hw-point.c to gdb/loongarch-linux-nat.c.
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
loongarch_lookup_debug_reg_state() is a unused function, so we
can remove it.
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
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).
|
|
Test-case gdb.python/py-symbol.exp fails with various target boards, including
fission and gold-gdb-index.
The problem here is that, in this test, the current language is still
unset (i.e., lazy) when the symbol lookup is done. It is eventually
set deep in the lookup -- but this then requires a reentrant symbol
lookup, which fails. (DWARF symbol lookup is not reentrant.)
Fix this by:
- detecting symbol lookup reentrance using an assert, and
- requiring the current language to be set when entering symbol lookup.
Tested on x86_64-linux.
Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/32490
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32490
|
|
This changes decode_line_2_item::selected to bool. There was no
benefit to keeping this as a bitfield, so I removed that. Note that
the constructor already uses bool here.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes add_sal_to_sals to use 'bool' rather than 'int'.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I found a few filename-related "show" commands that do not use the
filename style when displaying the file. This patch fixes the
oversight.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
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>
|
|
UST support in gdbserver is substantially outdated. Simon says:
...[having HAVE_UST defined] never happens nowadays because it used
a version of lttng-ust that has been deprecated for a loooong time
(the 0.x series). So everything in HAVE_UST just bitrots. It might
be possible to update all this code to use lttng-ust 2.x (1.x never
existed), but I don't think it's going to happen unless somebody
specifically asks for it. I would suggest removing support for UST
from gdbserver. ...If we ever want to resurrect the support for UST
and port to 2.x, we can get the code from the git history.
This patch removes the support, mostly mechanically by deleting code
guarded by `#ifdef HAVE_UST`. After these removals, `struct
static_tracepoint_ctx` becomes unused. So, remove it, too.
The following patches remove more code.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I noticed that 'L' is a tracepoint action but it is not defined in the
document. Add the description.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
I noticed that gdbserver accepts an 'S' option for the QTDP packet to
create a static tracepoint, but this is not mentioned in the document.
Update the document.
I first thought about updating the argument as `[:Flen|:S]`, but then
opted for `[:Flen][:S]`. Although it is odd that ':F' and ':S' are
allowed to co-exist, the implementation at the gdbserver side allows
this and handles the packet arguments so that the right-most
positioned ':F' or ':S' overwrites the final tracepoint type. When
the documentation is missing, the implementation usually determines
the behavior.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
In AIX a recent commit caused a build break with the error as shown below.
In file included from python/py-color.h:23,
from python/python.c:39:
python/python-internal.h:86:10: fatal error: Python.h: No such file or directory
86 | #include <Python.h>
In AIX, we run builds with and without python for our internal CI's.
A feature development made by the recent commit https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6447969d0ac774b6dec0f95a0d3d27c27d158690
missed to guard Python.h in HAVE_PYTHON macro.
This commit is a fix for the same.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A comment in bugzilla pointed out a bug in my earlier patch to handle
the DAP "linesStartAt1" setting. In particular, in the backtrace
code, "line" can be None, which would lead to an exception from
export_line.
This patch fixes the problem.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468
|
|
Fix a typo and do a format change.
|
|
Commit 7fcdec025c05 ("GDB: Use gdb::array_view for buffers used in
register reading and unwinding") introduces a regression in
gdb.base/jit-reader.exp:
$ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/jit-reader/jit-reader -ex 'jit-reader-load /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/jit-reader/jit-reader.so' -ex r -batch
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
Program received signal SIGTRAP, Trace/breakpoint trap.
Recursive internal problem.
The "Recusive internal problem" part is not good, but it's not the point
of this patch. It still means we hit an internal error.
The stack trace is:
#0 internal_error_loc (file=0x55555ebefb20 "/home/simark/src/binutils-gdb/gdb/frame.c", line=1207, fmt=0x55555ebef500 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:53
#1 0x0000555561604d83 in frame_register_unwind (next_frame=..., regnum=16, optimizedp=0x7ffff12e5a20, unavailablep=0x7ffff12e5a30, lvalp=0x7ffff12e5a40, addrp=0x7ffff12e5a60, realnump=0x7ffff12e5a50, buffer=...)
at /home/simark/src/binutils-gdb/gdb/frame.c:1207
#2 0x0000555561608334 in deprecated_frame_register_read (frame=..., regnum=16, myaddr=...) at /home/simark/src/binutils-gdb/gdb/frame.c:1496
#3 0x0000555561a74259 in jit_unwind_reg_get_impl (cb=0x7ffff1049ca0, regnum=16) at /home/simark/src/binutils-gdb/gdb/jit.c:988
#4 0x00007fffd26e634e in read_register (callbacks=0x7ffff1049ca0, dw_reg=16, value=0x7fffffffb4c8) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:100
#5 0x00007fffd26e645f in unwind_frame (self=0x50400000ac10, cbs=0x7ffff1049ca0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:143
#6 0x0000555561a74a12 in jit_frame_sniffer (self=0x55556374d040 <jit_frame_unwind>, this_frame=..., cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/jit.c:1042
#7 0x00005555615f499e in frame_unwind_try_unwinder (this_frame=..., this_cache=0x5210002905f8, unwinder=0x55556374d040 <jit_frame_unwind>) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:138
#8 0x00005555615f512c in frame_unwind_find_by_frame (this_frame=..., this_cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:209
#9 0x00005555616178d0 in get_frame_type (frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2996
#10 0x000055556282db03 in do_print_frame_info (uiout=0x511000027500, fp_opts=..., frame=..., print_level=0, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1033
The problem is that function `jit_unwind_reg_get_impl` passes field
`gdb_reg_value::value`, a gdb_byte array of 1 element (used as a
flexible array member), as the array view parameter of
`deprecated_frame_register_read`. This results in an array view of size
1. The assertion in `frame_register_unwind` that verifies the passed in
buffer is larger enough to hold the unwound register value then fails.
Fix this by explicitly creating an array view of the right size.
Change-Id: Ie170da438ec9085863e7be8b455a067b531635dc
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
|
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.
|
|
I noticed that an article was missing in the "Debug Names" node. I'm
checking this in to correct the error.
|
|
event-top.h declares the_prompts, but it is never defined. It's a
leftover from some ancient refactoring.
Similarly, top.c defines a few prompt-related macros, but these are
unused.
This patch removes these.
|
|
This was flagged by Debian's lintian.
Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
|
|
I belatedly realized I had forgotten to update a bool-related comment
in linespec.c. This patch fixes the oversight.
|
|
This changes various spots in linespec to use a bool rather than an
int.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I noticed that two parts of linespec.c:add_matching_symbols_to_info
use the same lambda, and hoisting this seems slightly more efficient.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This cleans up a 'return' in linespec.c:add_minsym.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes linespec_state to use a std::vector, and changes
linespec_canonical_name to use std::string. This removes some manual
memory management, including some odd cleanup code in in
decode_line_full.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This patch changes linespec_state to use gdb::unordered_set. This
simplifies the code a little and removes some manual management. It
also replaces address_entry with a std::pair, which simplifies the
code even more; and since this is a private type, IMO it doesn't
reduce readability at all.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes linespec_state to have real constructors and a
destructor.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This allows checking the size of the given buffer. Changes
frame_register_unwind (), frame_unwind_register (), get_frame_register ()
and deprecated_frame_register_read ().
As pointed out by Baris, in the case of MIPS target code this is best
done by changing a couple of alloca-based buffers in
mips_read_fp_register_single and mips_print_fp_register to
gdb::byte_vector instances.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
It already accepts a nullptr value and a couple of places were always
calling it that way, so make it possible to omit the argument entirely.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
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>
|
|
With gcc 10 and -std=c++20, we run into the same problem as reported in commit
6feae66da1d ("[gdb/build, c++20] Handle deprecated std::allocator::construct").
The problem was fixed using:
...
-template<typename T, typename A = std::allocator<T>>
+template<typename T,
+ typename A
+#if __cplusplus >= 202002L
+ = std::pmr::polymorphic_allocator<T>
+#else
+ = std::allocator<T>
+#endif
+ >
...
but that doesn't work for gcc 10, because it defines __cplusplus differently:
...
$ echo | g++-10 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus
#define __cplusplus 201709L
$ echo | g++-11 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus
#define __cplusplus 202002L
...
Fix this by using the library feature test macro
__cpp_lib_polymorphic_allocator [1], which is undefined for c++17 and defined
for c++20:
...
$ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++17 2>&1 \
| grep __cpp_lib_polymorphic_allocator
$ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++20 2>&1 \
| grep __cpp_lib_polymorphic_allocator
#define __cpp_lib_polymorphic_allocator 201902L
$
...
A similar problem exists for commit 3173529d7de ("[gdb/guile, c++20] Work
around Werror=volatile in libguile.h"). Fix this by testing for 201709L
instead.
Tested on x86_64-linux, by building gdb with
{gcc 10, clang 17.0.6} x {-std=c++17, -std=c++20}.
PR build/32503
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32503
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://en.cppreference.com/w/cpp/feature_test#cpp_lib_polymorphic_allocator
|
|
The goal is to ensure that it is available in frame_unwind_got_bytes () to
make sure that the provided buf isn't larger than the size of the register
being provisioned.
In the process, regcache's cached_reg_t::data also needed to be
converted to a gdb::byte_vector, so that the register contents' size can
be tracked.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This is useful information I missed while debugging issues with
the g packet reply.
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
On s390x-linux, I run into:
...
(gdb) backtrace
#0 0x000000000100061a in fun_three ()
#1 0x000000000100067a in fun_two ()
#2 0x000003fffdfa9470 in ?? ()
Backtrace stopped: frame did not save the PC
(gdb) FAIL: gdb.base/readnever.exp: backtrace
...
This is really due to a problem handling the fun_three frame. When generating
a backtrace from fun_two, everying looks ok:
...
$ gdb -readnever -q -batch outputs/gdb.base/readnever/readnever \
-ex "b fun_two" \
-ex run \
-ex bt
...
#0 0x0000000001000650 in fun_two ()
#1 0x00000000010006b6 in fun_one ()
#2 0x00000000010006ee in main ()
...
For reference the frame info with debug info (without -readnever) looks like this:
...
$ gdb -q -batch outputs/gdb.base/readnever/readnever \
-ex "b fun_three" \
-ex run \
-ex "info frame"
...
Stack level 0, frame at 0x3fffffff140:
pc = 0x1000632 in fun_three (readnever.c:20); saved pc = 0x100067a
called by frame at 0x3fffffff1f0
source language c.
Arglist at 0x3fffffff140, args: a=10, b=49 '1', c=0x3fffffff29c
Locals at 0x3fffffff140, Previous frame's sp in v0
...
But with -readnever, like this instead:
...
Stack level 0, frame at 0x0:
pc = 0x100061a in fun_three; saved pc = 0x100067a
called by frame at 0x3fffffff140
Arglist at 0xffffffffffffffff, args:
Locals at 0xffffffffffffffff, Previous frame's sp in r15
...
An obvious difference is the "Previous frame's sp in" v0 vs. r15.
Looking at the code:
...
0000000001000608 <fun_three>:
1000608: b3 c1 00 2b ldgr %f2,%r11
100060c: b3 c1 00 0f ldgr %f0,%r15
1000610: e3 f0 ff 50 ff 71 lay %r15,-176(%r15)
1000616: b9 04 00 bf lgr %r11,%r15
...
it becomes clear what is going on. This is an unusual prologue.
Rather than saving r11 (frame pointer) and r15 (stack pointer) to stack,
instead they're saved into call-clobbered floating point registers.
[ For reference, this is the prologue of fun_two:
...
0000000001000640 <fun_two>:
1000640: eb bf f0 58 00 24 stmg %r11,%r15,88(%r15)
1000646: e3 f0 ff 50 ff 71 lay %r15,-176(%r15)
100064c: b9 04 00 bf lgr %r11,%r15
...
where the first instruction stores registers r11 to r15 to stack. ]
Gdb fails to properly analyze the prologue, which causes the problems getting
the frame info.
Fix this by:
- adding handling of the ldgr insn [1] in s390_analyze_prologue, and
- recognizing the insn as saving a register in
s390_prologue_frame_unwind_cache.
This gets us instead:
...
Stack level 0, frame at 0x0:
pc = 0x100061a in fun_three; saved pc = 0x100067a
called by frame at 0x3fffffff1f0
Arglist at 0xffffffffffffffff, args:
Locals at 0xffffffffffffffff, Previous frame's sp in f0
...
and:
...
(gdb) backtrace^M
#0 0x000000000100061a in fun_three ()^M
#1 0x000000000100067a in fun_two ()^M
#2 0x00000000010006b6 in fun_one ()^M
#3 0x00000000010006ee in main ()^M
(gdb) PASS: gdb.base/readnever.exp: backtrace
...
Tested on s390x-linux.
PR tdep/32417
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32417
Approved-By: Andreas Arnez <arnez@linux.ibm.com>
[1] https://www.ibm.com/support/pages/sites/default/files/2021-05/SA22-7871-10.pdf
|
|
In s390_prologue_frame_unwind_cache there are two loops using a hardcoded
constant 16:
...
for (i = 0; i < 16; i++)
if (s390_register_call_saved (gdbarch, S390_R0_REGNUM + i)
...
for (i = 0; i < 16; i++)
if (s390_register_call_saved (gdbarch, S390_F0_REGNUM + i)
...
Fix this by using symbolic constants S390_NUM_GPRS and S390_NUM_FPRS instead.
Tested on s390x-linux, by rebuilding.
Approved-By: Andreas Arnez <arnez@linux.ibm.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.
|
|
Boolify the field. The 'set_stop_requested' function was already
taking a bool parameter, whose value is assigned to the field.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
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.
|
|
The regcache_register_size function has one implementation in GDB, and
one in gdbserver. Both of them have a gdb::checked_static_cast to their
corresponding regcache class. This can be avoided by defining a
pure virtual register_size method in the
reg_buffer_common class, which is then implemented by the reg_buffer
class in GDB, and by the regcache class in gdbserver.
Calls to the register_size () function from methods of classes in the
reg_buffer_common hierarchy need to be changed to calls to the newly
defined method, otherwise the compiler complains that a matching method
cannot be found.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Change-Id: I7f4f74a51e96c42604374e87321ca0e569bc07a3
|
|
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.
|
