| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix 'text' to 'test' in a test comment.
|
|
The commit:
commit 22836ca88591ac7efacf06d5b6db191763fd8aba
Date: Tue May 21 09:57:49 2024 +0100
gdb: check for multiple matching build-id files
Was missing a 'require allow_gdbserver_tests' in a gdbserver test.
Add it now.
|
|
When running test-case gdb.dap/rust-slices.exp on aarch64-linux
(debian 12/bookworm), I run into:
...
{"request_seq": 6, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 3, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 261, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}]}, "success": true, "seq": 20}PASS: gdb.dap/rust-slices.exp: get scopes success
FAIL: gdb.dap/rust-slices.exp: three scopes
PASS: gdb.dap/rust-slices.exp: scope is locals
PASS: gdb.dap/rust-slices.exp: locals presentation hint
PASS: gdb.dap/rust-slices.exp: three vars in scope
...
The test-case expects three scopes due to a rust compiler issue:
...
# There are three scopes because an artificial symbol ends up in the
# DWARF. See https://github.com/rust-lang/rust/issues/125126.
gdb_assert {[llength $scopes] == 3} "three scopes"
...
but it seems that the version used here (rustc 1.63.0, llvm 14.0.6) doesn't
have this issue.
Fix this by allowing two or three scopes, and changing the test name to
"two scopes".
Tested on aarch64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR testsuite/31983
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31983
|
|
I noticed that in the 'info breakpoints' output, GDB sometimes prints
the inferior list for pending breakpoints, this doesn't seem right to
me. A pending breakpoint has no locations (at least, as far as we
display things in the 'info breakpoints' output), so including an
inferior list seems odd.
Here's what I see right now:
(gdb) info breakpoint 5
Num Type Disp Enb Address What
5 breakpoint keep y <PENDING> foo inf 1
(gdb)
It's the 'inf 1' at the end of the line that I'm objecting too.
To trigger this behaviour we need to be in a multi-inferior debug
session. The breakpoint must have been non-pending at some point in
the past, and so have a location assigned to it.
The breakpoint becomes pending again as a result of a shared library
being unloaded. When this happens the location itself is marked
pending (via bp_location::shlib_disabled).
In print_one_breakpoint_location, in order to print the inferior list
we check that the breakpoint has a location, and that we have multiple
inferiors, but we don't check if the location itself is pending.
This commit adds that check, which means the output is now:
(gdb) info breakpoint 5
Num Type Disp Enb Address What
5 breakpoint keep y <PENDING> foo
(gdb)
Which I think makes more sense -- indeed, the format without the
inferior list is what we display for a pending breakpoint that has
never had any locations assigned, so I think this change in behaviour
makes GDB more consistent.
|
|
When debugging gdb itself and trying to print a intrusive_list that has
more than one element, I get:
File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 365, in _children_generator
node_ptr = self._as_node_ptr(elem_ptr)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 345, in _as_node_ptr
assert elem_ptr.type.code == gdb.TYPE_CODE_PTR
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
This is because node_ptr is a typedef
(intrusive_list_base_iterator::pointer). Add a call to strip_typedefs
to get to the real type.
Enhance gdb.gdb/python-helper.exp with a test that would have caught
this bug.
Change-Id: I3eaca8de5ed06d05756ed979332b6a431e15b700
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Within the debug-file-directory GDB looks for the existence of a
.build-id directory.
Within the .build-id directory GDB looks for files with the form:
.build-id/ff/4b4142d62b399499844924d53e33d4028380db.debug
which contain the debug information for the objfile with the build-id
ff4b4142d62b399499844924d53e33d4028380db.
There appear to be two strategies for populating the .build-id
directory. Ubuntu takes the approach of placing the actual debug
information in this directory, so
4b4142d62b399499844924d53e33d4028380db.debug is an actual file
containing the debug information.
Fedora, RHEL, and SUSE take a slightly different approach, placing the
debug information elsewhere, and then creating symlinks in the
.build-id directory back to the original debug information file. The
actual debug information is arranged in a mirror of the filesystem
within the debug directory, as an example, if the debug-file-directory
is /usr/lib/debug, then the debug information for /bin/foo can be
found in /usr/lib/debug/bin/foo.debug.
Where this gets interesting is that in some cases a package will
install a single binary with multiple names, in this case a single
binary will be install with either hard-links, or symlinks providing
the alternative names.
The debug information for these multiple binaries will then be placed
into the /usr/lib/debug/ tree, and again, links are created so a
single file can provide debug information for each of the names that
binary presents as. An example file system might look like this (the
[link] could be symlinks, but are more likely hard-links):
/bin/
foo
bar -> foo [ HARD LINK ]
baz -> foo [ HARD LINK ]
/usr/
lib/
debug/
bin/
foo.debug
bar.debug -> foo.debug [ HARD LINK ]
baz.debug -> foo.debug [ HARD LINK ]
In the .build-id tree though we have a problem. Do we have a single
entry that links to one of the .debug files? This would work; a user
debugging any of the binaries will find the debug information based on
the build-id, and will get the correct information, after all the
.debug files are identical (same file linked together). But there is
one problem with this approach.
Sometimes, for *reasons* it's possible that one or more the linked
binaries might get removed, along with its associated debug
information. I'm honestly not 100% certain under what circumstances
this can happen, but what I observe is that sometime a single name for
a binary, and its corresponding .debug entry, can be missing. If this
happens to be the entry that the .build-id link is pointing at, then
we have a problem. The user can no longer find the debug information
based on the .build-id link.
The solution that Fedora, RHEL, & SUSE have adopted is to add multiple
entries in the .build-id tree, with each entry pointing to a different
name within the debug/ tree, a sequence number is added to the
build-id to distinguish the multiple entries. Thus, we might end up
with a layout like this:
/bin/
foo
bar -> foo [ HARD LINK ]
baz -> foo [ HARD LINK ]
/usr/
lib/
debug/
bin/
foo.debug
bar.debug -> foo.debug [ HARD LINK ]
baz.debug -> foo.debug [ HARD LINK ]
.build-id/
a3/
4b4142d62b399499844924d53e33d4028380db.debug -> ../../debug/bin/foo.debug [ SYMLINK ]
4b4142d62b399499844924d53e33d4028380db.1.debug -> ../../debug/bin/bar.debug [ SYMLINK ]
4b4142d62b399499844924d53e33d4028380db.2.debug -> ../../debug/bin/baz.debug [ SYMLINK ]
With current master GDB, debug information will only ever be looked up
via the 4b4142d62b399499844924d53e33d4028380db.debug link. But if
'foo' and its corresponding 'foo.debug' are ever removed, then master
GDB will fail to find the debug information.
Ubuntu seems to have a much better approach for debug information
handling; they place the debug information directly into the .build-id
tree, so there only ever needs to be a single entry for any one
build-id. I wonder if/how they handle the case where multiple names
might share a single .debug file, if one of those names is then
uninstalled, how do they know the .debug file should be retained or
not ... but I assume that problem either doesn't exist or has been
solved.
Anyway, for a while Fedora has carried a patch that handles the
build-id sequence number logic. What's presented here is inspired by
the Fedora patch, but has some changes to fix some issues.
I'm aware that this is a patch that applies to only some (probably a
minority) of distros. However, the logic is contained to only a
single function in build-id.c, and isn't too complex, so I'm hoping
that there wont be too many objections.
For distros that don't have build-id sequence numbers there should be
no impact. The sequence number approach still leaves the first file
without a sequence number, and this is the first file that GDB (after
this patch) checks for. The new logic only kicks in if the
non-sequence numbered first file exists, but is a symlink to a non
existent file; in this case GDB checks for the sequence numbered files
instead.
Tests are included.
There is a small fix needed for gdb.base/sysroot-debug-lookup.exp,
after this commit GDB now treats a target: sysroot where the target
file system is local to GDB the same as if the sysroot had no target:
prefix. The consequence of this is that GDB now resolves a symlink
back to the real filename in the sysroot-debug-lookup.exp test where
it didn't previously. As this behaviour is inline with the case where
there is no target: prefix I think this is fine.
|
|
When running test-case gdb.arch/arm-pseudo-unwind.exp with target board
unix/mthumb, we run into:
...
(gdb) continue^M
Continuing.^M
^M
Program received signal SIGILL, Illegal instruction.^M
0x00400f38 in ?? ()^M
(gdb) FAIL: $exp: continue to breakpoint: continue to callee
...
The test-case attempts to force arm-pseudo-unwind.c to be compiled in arm mode
using additional_flags=-marm, but that's overridden by using target board
unix/mthumb.
This causes function main to be in thumb mode, and consequently function
caller (which is called from main) is is executed as if it's in thumb mode,
while it's actually in arm mode.
Fix this by adding an intermediate function caller_trampoline in
arm-pseudo-unwind.c, and hardcoding it to arm mode using
__attribute__((target("arm"))).
Likewise for test-case gdb.arch/arm-pseudo-unwind-legacy.exp.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
I noticed a lot of escaping in test-case gdb.base/complex-parts.exp.
Make the test-case more readable by using:
- string_to_regexp, and
- {} instead of "".
Tested on x86_64-linux and aarch64-linux.
|
|
Currently you get this assertion failure if you try to execute the
inferior after loading a saved recording, when no recording was done
earlier in the same gdb session:
```
$ gdb -q c -ex "record restore test.rec"
Reading symbols from c...
[New LWP 26428]
Core was generated by `/tmp/c'.
Restored records from core file /tmp/test.rec.
(gdb) c
Continuing.
../../gdb/inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
```
The change in step-precsave.exp triggers this bug, since now the
recording is loaded in a new gdb session, where
record_full_resume_ptid was never set.
The fix is to simply set record_full_resume_ptid when resuming a loaded
recording.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31971
Approved-By: Guinevere Larsen <blarsen@redhat.com>
|
|
More of a DWARF-generation non-regression test; fixed on the GCC side
with 2024-06-03 "Implement wrap-around arithmetics in DWARF
expressions" (f3d6d60d2ae).
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Some compiler changes I'm working on cause a regression in
gdb.ada/limited-length.exp -- with the changes, the array type is
nameless and so is not mentioned in the max-value-size error message.
Because the array type is nameless in the source code, this seems like
an improvement to me, and so this patch changes the test to accept
either form.
|
|
Simplify a gdb_test_multiple in test-case gdb.base/bg-execution-repeat.exp
using "gdb_test -no-prompt-anchor".
Suggested-By: Guinevere Larsen <blarsen@redhat.com>
Tested on x86_64-linux.
|
|
I ran into the following test failure with test-case
gdb.base/bg-execution-repeat.exp:
...
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: repeat bg command
^M
Breakpoint 2, foo () at bg-execution-repeat.c:23^M
23 return 0; /* set break here */^M
print 1^M
$1 = 1^M
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: input still accepted
FAIL: gdb.base/bg-execution-repeat.exp: c&: breakpoint hit 2 (timeout)
...
The failure can be easily reproduced by adding a sleep 5 here:
...
+ sleep 5
gdb_test "print 1" " = 1" "input still accepted"
...
There's a race in the test-case, between:
- the command handled in the foreground: the "print 1" command, and
- the command handled in the background: the continue command.
The current way of dealing with this is by putting the inferior to sleep for 5
seconds:
...
foo ();
sleep (5);
foo ();
...
with the aim that the "print 1" command will win the race.
This method is both slow and unreliable.
Fix this by making the inferior wait till the "print 1" command is done.
This reduces running time from ~11s to ~1s.
I also verified that the test-case still triggers on the original problem by
applying this gdb/infcmd.c patch:
...
-strip_bg_char (const char *args, int *bg_char_p)
+strip_bg_char (const char *_args, int *bg_char_p)
{
- const char *p;
+ char *args = const_cast<char *>(_args);
+ char *p;
if (args == nullptr || *args == '\0')
{
@@ -210,6 +211,7 @@ strip_bg_char (const char *args, int *bg_char_p)
p--;
while (p > args && isspace (p[-1]))
p--;
+ *p = '\0';
...
Tested on x86_64-linux, with make-check-all.sh.
PR testsuite/31794
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31794
Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
|
|
In case a DIE contains a linkage name which cannot be demangled and
a source language name (DW_AT_NAME) exists then we want to display this name
instead of the non-demangeable linkage name.
dwarf2_physname returns the linkage name in case the linkage name
cannot be demangled. Before this patch we always set the returned physname
as demangled name. This patch changes this by comparing the value
of physname with the linkage name. Now after this change in case it is equals
to the linkage name and if DW_AT_NAME exists then this is set as the demangled
name otherwise like before still linkage name is used.
For the reproducer, using the test source file added in this change:
"gdb/testsuite/gdb.dwarf2/dw2-wrong-mangled-name.c"
Here is an example of the DWARF where wrong linkage name is emitted by the
compiler for the "func_demangled_test" function:
subprogram {
{MACRO_AT_range {func_demangled_test}}
{linkage_name "_FUNC_WRONG_MANGLED__"}
{name "func_demangled_test"}
{external 1 flag}
}
subprogram {
{MACRO_AT_range {main}}
{external 1 flag}
{name main}
{main_subprogram 1 flag}
}
Before this change for a function having both DIEs DW_AT_name and
DW_AT_LINKAGENAME but with the wrong linkage name info, the backtrace
command shows following:
(gdb) b func_demangled_test
(gdb) r
Breakpoint 1, 0x0000555555555131 in _FUNC_WRONG_MANGLED__ ()
(gdb) backtrace
\#0 0x0000555555555131 in _FUNC_WRONG_MANGLED__ ()
\#1 0x000055555555514a in main ()
After the change now GDB shows the name emitted by DW_AT_NAME:
(gdb) b func_demangled_test
(gdb) r
Breakpoint 1, 0x0000555555555131 in func_demangled_test ()
(gdb) backtrace
\#0 0x0000555555555131 in func_demangled_test ()
\#1 0x000055555555514a in main ()
A new test is added to verify this change.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Looking for a type defined locally in a function doesn't work
any more since the introduction of TYPE_DOMAIN:
```
(gdb) python print (gdb.lookup_type ('main()::Local'))
Python Exception <class 'gdb.error'>: No type named main()::Local.
Error occurred in Python: No type named main()::Local.
```
cp_search_static_and_baseclasses was simply missing a check for
SEARCH_TYPE_DOMAIN, now it works again:
```
(gdb) python print (gdb.lookup_type ('main()::Local'))
Local
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31922
Approved-By: Tom Tromey <tom@tromey.com>
|
|
- Add type annotations
- Use a raw string in one spot (where we call re.sub), to avoid an
"invalid escape sequence" warning.
- Remove unused "os" import.
Change-Id: I0149cbb73ad2b05431f032fa9d9530282cb01e90
Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
|
|
On fedora rawhide, I ran into:
...
(gdb) continue^M
Continuing.^M
^M
Catchpoint 2 (call to syscall clone3), 0x000000000042097d in __clone3 ()^M
(gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue
...
Fix this by updating a regexp to also recognize __clone3.
Tested on x86_64-linux.
Tested-By: Guinevere Larsen <blarsen@redhat.com>
|
|
When I changed the Rust parser to handle 128-bit ints, this
inadvertently broke some other gdb commands. For example, "info
symbol 0xffffffffffffffff" now fails, because the resulting value is
128 bits, but this is rejected by extract_integer.
This patch fixes the problem by changing extract_integer to allow
over-long integers as long as the high bytes are either 0, or (for
signed types) 0xff.
Regression tested on x86-64 Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31565
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When running test-case gdb.python/py-format-address.exp on arm-linux, I get:
...
(gdb) python print("Got: " + gdb.format_address(0x103dd))^M
Got: 0x103dd <main at py-format-address.c:30>^M
(gdb) FAIL: $exp: symbol_filename=on: gdb.format_address, \
result should have an offset
...
What is expected here is:
...
Got: 0x103dd <main+1 at py-format-address.c:30>^M
...
Main starts at main_addr:
...
(gdb) print /x &main^M
$1 = 0x103dc^M
...
and we obtained next_addr 0x103dd by adding 1 to it:
...
set next_addr [format 0x%x [expr $main_addr + 1]]
...
Adding 1 to $main_addr results in an address for a thumb function starting at
address 0x103dc, which is incorrect because main is an arm function (because
I'm running with target board unix/-marm).
At some point during the call to format_addr, arm_addr_bits_remove removes
the thumb bit, which causes the +1 offset to be dropped, causing the FAIL.
Fix this by using the address of the breakpoint on main, provided it's not at
the very start of main.
Tested on arm-linux.
PR testsuite/31452
Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31452
|
|
When running test-case gdb.base/watchpoint-unaligned.exp on ppc64le-linux, we
get:
...
XFAIL: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131)
XFAIL: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131)
...
UNTESTED: $exp: wpcount(4)
XFAIL: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131)
DUPLICATE: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131)
XFAIL: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131)
DUPLICATE: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131)
...
UNTESTED: $exp: wpcount(7)
...
Fix this by using foreach_with_prefix.
Tested on ppc64le-linux.
|
|
With test-case gdb.opt/inline-cmds.exp on ppc64le-linux, I ran into:
...
PASS: gdb.opt/inline-cmds.exp: finish from marker
...
PASS: gdb.opt/inline-cmds.exp: finish from marker
DUPLICATE: gdb.opt/inline-cmds.exp: finish from marker
...
Fix this by issuing less passes.
Tested on ppc64le-linux.
|
|
With test-case gdb.fortran/huge.exp, on a system without fortran compiler, I
ran into a number of duplicates:
...
Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/huge.exp ...
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/huge.exp: huge.exp
...
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/huge.exp: huge.exp
DUPLICATE: gdb.fortran/huge.exp: huge.exp
UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded
...
Fix this by wrapping the compile in a with_test_prefix, getting us instead:
...
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=2097152: huge.exp
...
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=16: huge.exp
UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded
...
Tested on x86_64-linux.
|
|
When running test-case gdb.base/complex-parts.exp on arm-linux, I get:
...
(gdb) p $_cimag (z3)^M
$6 = 6.5^M
(gdb) PASS: gdb.base/complex-parts.exp: long double imaginary: p $_cimag (z3)
ptype $^M
type = double^M
(gdb) FAIL: gdb.base/complex-parts.exp: long double imaginary: ptype $
...
Given that z3 is a complex long double, the test-case expects the type of the
imaginary part of z3 to be long double, but it's double instead.
This is due to the fact that the dwarf info doesn't specify an explicit target
type:
...
<5b> DW_AT_name : z3
<60> DW_AT_type : <0xa4>
...
<1><a4>: Abbrev Number: 2 (DW_TAG_base_type)
<a5> DW_AT_byte_size : 16
<a6> DW_AT_encoding : 3 (complex float)
<a7> DW_AT_name : complex long double
...
and consequently we're guessing in dwarf2_init_complex_target_type based on
the size:
...
case 64:
tt = builtin_type (gdbarch)->builtin_double;
break;
case 96: /* The x86-32 ABI specifies 96-bit long double. */
case 128:
tt = builtin_type (gdbarch)->builtin_long_double;
break;
...
For arm-linux, complex long double is 16 bytes, so the target type is assumed
to be 8 bytes, which is handled by the "case 64", which gets us double
instead of long double.
Fix this by searching for "long" in the name_hint parameter, and using long
double instead.
Note that base types in dwarf are not allowed to contain references to other
types, and the complex types are base types, so the missing explicit target
type is standard-conformant.
A gcc PR was filed to add this as a dwarf extension (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 ).
Tested on arm-linux.
|
|
On s390x-linux, I run into:
...
(gdb) p (short []) s1^M
$3 = {0, 1, 0, <optimized out>}^M
(gdb) FAIL: gdb.dwarf2/shortpiece.exp: p (short []) s1
...
while this is expected:
...
(gdb) p (short []) s1^M
$3 = {1, 0, 0, <optimized out>}^M
(gdb) PASS: gdb.dwarf2/shortpiece.exp: p (short []) s1
...
The type of s1 is:
...
(gdb) ptype s1
type = struct S {
myint a;
myushort b;
}
...
so the difference is due the fact that viewing an int as two shorts gives
different results depending on the endianness.
Fix this by allowing both results.
Tested on x86_64-linux and s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that we started using "string cat", which has been available since
tcl version 8.6.2.
Add a local implementation for use with older tcl versions.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When running test-case gdb.fortran/array-indices.exp on a system without
fortran compiler, I run into a duplicate:
...
Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/array-indices.exp ...
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp
DUPLICATE: gdb.fortran/array-indices.exp: array-indices.exp
...
Fix this by adding a with_test_prefix at the toplevel.
Likewise in gdb.fortran/array-repeat.exp.
Tested on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
Fix shellcheck warnings in script lib/dg-add-core-file-count.sh.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Since this commit:
commit 0ee6b1c511c0e2a6793568692d2e5418cd6bc10d
Date: Wed May 18 13:32:04 2022 -0700
Use aarch64_features to describe register features in target descriptions.
There has been an issue with how aarch64 target descriptions are
cached within gdbserver, and specifically, how this caching impacts
the in process agent (IPA).
The function initialize_tracepoint_ftlib (gdbserver/tracepoint.cc) is
part of the IPA, this function is a constructor function, i.e. is
called as part of the global initialisation process. We can't
guarantee the ordering of when this function is called vs when other
global state is initialised.
Now initialize_tracepoint_ftlib calls initialize_tracepoint, which
calls initialize_low_tracepoint, which for aarch64 calls
aarch64_linux_read_description.
The aarch64_linux_read_description function lives in
linux-aarch64-tdesc.cc and after the above commit, depends on a
std::unordered_map having been initialized.
Prior to the above commit aarch64_linux_read_description used a global
C style array, which obviously requires no runtime initialization.
The consequence of the above is that any inferior linked with the IPA
(for aarch64) will experience undefined behaviour (access to an
uninitialized std::unordered_map) during startup, which for me
manifests as a segfault.
I propose fixing this by moving the std::unordered_map into the
function body, but leaving it static. The map will now be initialized
the first time the function is called, which removes the undefiend
behaviour.
The same problem exists for the expedited_registers global, however
this global can just be made into a function local instead. The
expedited_registers variable is used to build a pointer list which is
then passed to init_target_desc, however init_target_desc copies the
values it is given so expedited_registers does not need to live longer
than its containing function.
On most of the AArch64 machines I have access too tracing is not
supported, and so the gdb.trace/*.exp tests that use the IPA just exit
early reporting unsupported. I've added a test which links an
inferior with the IPA and just starts the inferior. No tracing is
performed. This exposes the current issue even on hosts that don't
support tracing. After this patch the test passes.
|
|
Starting with gcc commit 80048aa13a6 ("debug/111409 - don't generate COMDAT
macro sections for split DWARF"), available from release gcc 14.1 onwards, gcc
produces a usable dwarf-5 32-bit .debug_macro.dwo section.
Add a test-case excercising this.
Tested on x86_64-linux.
Tested test-case using a current gcc trunk build, and gcc 14.
|
|
Test-case gdb.base/watchpoint-running.exp reports the following kfail:
...
KFAIL: $exp: all-stop: software: watchpoint hit (timeout) (PRMS: gdb/111111)
...
but the referenced gdb PR doesn't exist.
Fix this by using an actual PR.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31833
|
|
With test-case gdb.server/server-kill-python.exp, I sometimes run into:
...
builtin_spawn gdb -nw -nx -q -iex set height 0 -iex set width 0 \
-data-directory data-directory^M
kill^M
(gdb) kill^M
file server-kill-python^M
The program is not being run.^M
(gdb) ERROR: Couldn't load server-kill-python into GDB.
...
The problem is that the spawn produces a prompt, but it's not explicitly
consumed.
This is a regression since commit 0f077fcae0f ("[gdb/testsuite] Simplify
gdb.server/server-kill-python.exp").
Fix this by consuming the initial prompt.
PR testsuite/31819
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31819
Fixes: 0f077fcae0f ("[gdb/testsuite] Simplify gdb.server/server-kill-python.exp"
|
|
Currently it's not possible to call user-defined function call
operators, at least not without specifying operator() directly:
```
(gdb) l 1
1 struct S {
2 int operator() (int x) { return x + 5; }
3 };
4
5 int main () {
6 S s;
7
8 return s(23);
9 }
(gdb) p s(10)
Invalid data type for function to be called.
(gdb) p s.operator()(10)
$1 = 15
```
This now looks if an user-defined call operator is available when
trying to 'call' a struct value, and calls it instead, making this
possible:
```
(gdb) p s(10)
$1 = 15
```
The change in operation::evaluate_funcall is to make sure the type
fields are only used for function types, only they use them as the
argument types.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12213
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While working on a later patch in this series, I noticed that GDB
would print the message:
Reading /path/to/file from remote target...
Even when /path/to/file doesn't exist on the remote target.
GDB does indeed try to open /path/to/file, but I'm not sure we really
need to tell the user unless we actually manage to open the file, and
plan to read content from it.
If we consider how GDB probes for separate debug files, we can attempt
to open multiple possible files, most of them will not exist. When we
are native debugging we don't bother telling the user about each file
we're checking for, we just announce any file we finally use.
I think it makes sense to do a similar thing for remote files.
So, in remote_target::remote_hostio_open(), I'd like to move the block
of code that prints the above message to after the open call has been
made, and we should only print the message if the open succeeds.
Now GDB only tells the user about files that we actually open and read
from the remote.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The bitshift tests for opencl have these failures:
print /x (signed char) 0x0f << 8
No type named signed char.
(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print /x (signed char) 0x0f << 8
print (signed char) 0x0f << 8
No type named signed char.
(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print (signed char) 0x0f << 8
Apparently opencl doesn't have the 'signed' modifier for types, only
the 'unsigned' modifier.
Even 'char' is guaranteed to be signed if no modifier is used, so
this changes the casts to match this logic.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On systems where long has 32-bit size you get these failures:
print 1 << (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 << (unsigned long long) 0xffffffffffffffff
print 1 >> (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 >> (unsigned long long) 0xffffffffffffffff
print -1 << (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 << (unsigned long long) 0xffffffffffffffff
print -1 >> (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 >> (unsigned long long) 0xffffffffffffffff
Fixed by changing the number-of-bits variable to ULONGEST.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
As seen in these test failures:
print -1 >> -1
warning: right shift count is negative
$N = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -1 >> -1
print -4 >> -2
warning: right shift count is negative
$N = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -4 >> -2
Fixed by restoring the logic from before the switch to gmp.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR31590 shows that right shift of negative numbers doesn't work
correctly since GDB 14:
(gdb) p (-3) >> 1
$1 = -1
GDB 13 and earlier returned the correct value -2.
And there actually is one test that shows the failure:
print -1 >> 1
$84 = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=asm: rsh neg lhs: print -1 >> 1
The problem was introduced with the change to gmp functions in
commit 303a881f87.
It's wrong because gdb_mpz::operator>> uses mpz_tdif_q_2exp, which
always rounds toward zero, and the gmp docu says this:
For positive n both mpz_fdiv_q_2exp and mpz_tdiv_q_2exp are simple
bitwise right shifts.
For negative n, mpz_fdiv_q_2exp is effectively an arithmetic right shift
treating n as two's complement the same as the bitwise logical functions
do, whereas mpz_tdiv_q_2exp effectively treats n as sign and magnitude.
So this changes mpz_tdiv_q_2exp to mpz_fdiv_q_2exp, since it
does right shifts for both positive and negative numbers.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31590
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Commit cdd4206647 unintentionally disabled all tests of bitshift.exp,
so it actually just does this:
Running /c/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/bitshift.exp ...
PASS: gdb.base/bitshift.exp: complete set language
=== gdb Summary ===
# of expected passes 1
It changed the 'continue' of unsupported languages to 'return', and
since ada is the first language and is unsupported, no tests were run.
This changes it back to 'continue', and the following patches fix
the regressions that were introduced since then unnoticed.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
After fixing test-case gdb.python/py-disasm.exp to recognize the arm nop:
...
nop {0}
...
we run into:
...
disassemble test^M
Dump of assembler code for function test:^M
0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M
0x004004dc <+4>: add r11, sp, #0^M
0x004004e0 <+8>: nop {0}^M
=> 0x004004e4 <+12>: Python Exception <class 'ValueError'>: Buffer \
returned from read_memory is sized 0 instead of the expected 4^M
^M
unknown disassembler error (error = -1)^M
(gdb) FAIL: $exp: global_disassembler=ShowInfoRepr: disassemble test
...
This is caused by this code in gdbpy_disassembler::read_memory_func:
...
gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj,
"read_memory",
"KL", len, offset));
...
where len has type "unsigned int", while "K" means "unsigned long long" [1].
Fix this by using "I" instead, meaning "unsigned int".
Also, offset has type LONGEST, which is typedef'ed to int64_t, while "L" means
"long long".
Fix this by using type gdb_py_longest for offset, in combination with format
character "GDB_PY_LL_ARG". Likewise in disasmpy_info_read_memory.
Tested on arm-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR python/31845
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845
[1] https://docs.python.org/3/c-api/arg.html
|
|
In test-case gdb.mi/mi-var-child-f.exp, we have:
...
mi_gdb_test "-gdb-set auto-solib-add off" "\\^done"
mi_runto prog_array
mi_gdb_test "nosharedlibrary" ".*\\^done"
...
This was added to avoid a name clash between the array variable as defined in
gdb.mi/array.f90 and debug info in shared libraries, and used in other places
in the testsuite.
The same workaround is also used to ignore symbols from shared libraries when
excercising for instance a command that prints all symbols.
However, this approach can cause problems for targets like arm that require
symbol info for some libraries like ld.so and libc to fully function.
While absense of debug info for shared libraries should be handled gracefully
(which does need fixing, see PR31817), failure to do so should not result
in failures in unrelated test-cases.
Fix this by removing "set auto-solib-add off".
This ensures that we don't run into PR31817, while the presence of
nosharedlibrary still ensures that in the rest of the test-case we're not
bothered by shared library symbols.
Likewise in other test-cases.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Tested on arm-linux.
|
|
Test behaviour of watchpoints triggered by MOPS instructions. This test
is similar to gdb.base/memops-watchpoint.exp, but specifically for MOPS
instructions rather than whatever instructions are used in the libc's
implementation of memset/memcpy/memmove.
There's a separate watched variable for each set of instructions so that
the testcase can test whether GDB correctly identified the watchpoint
that triggered in each case.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
There are two kinds of MOPS instructions: set instructions and copy
instructions. Within each group there are variants with minor
differences in how they read or write to memory — e.g., non-temporal
read and/or write, unprivileged read and/or write and permutations of
those — but they work in the same way in terms of the registers and
regions of memory that they modify.
The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS
instructions are recorded and correctly reversed. Not all variants of the
copy and set instructions are tested, since there are many and the record
and replay target processes them in the same way.
PR tdep/31666
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
The AArch64 MOPS (Memory Operation) instructions provide a standardised
instruction sequence to perform a memset, memcpy or memmove. A sequence is
always composed of three instructions: a prologue instruction, a main
instruction and an epilogue instruction. As an illustration, here are the
implementations of these memory operations in glibc 2.39:
(gdb) disassemble/r
Dump of assembler code for function __memset_mops:
=> 0x0000fffff7e8d780 <+0>: d503201f nop
0x0000fffff7e8d784 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8d788 <+8>: 19c10443 setp [x3]!, x2!, x1
0x0000fffff7e8d78c <+12>: 19c14443 setm [x3]!, x2!, x1
0x0000fffff7e8d790 <+16>: 19c18443 sete [x3]!, x2!, x1
0x0000fffff7e8d794 <+20>: d65f03c0 ret
End of assembler dump.
(gdb) disassemble/r
Dump of assembler code for function __memcpy_mops:
=> 0x0000fffff7e8c580 <+0>: d503201f nop
0x0000fffff7e8c584 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8c588 <+8>: 19010443 cpyfp [x3]!, [x1]!, x2!
0x0000fffff7e8c58c <+12>: 19410443 cpyfm [x3]!, [x1]!, x2!
0x0000fffff7e8c590 <+16>: 19810443 cpyfe [x3]!, [x1]!, x2!
0x0000fffff7e8c594 <+20>: d65f03c0 ret
End of assembler dump.
(gdb) disassemble/r
Dump of assembler code for function __memmove_mops:
=> 0x0000fffff7e8d180 <+0>: d503201f nop
0x0000fffff7e8d184 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8d188 <+8>: 1d010443 cpyp [x3]!, [x1]!, x2!
0x0000fffff7e8d18c <+12>: 1d410443 cpym [x3]!, [x1]!, x2!
0x0000fffff7e8d190 <+16>: 1d810443 cpye [x3]!, [x1]!, x2!
0x0000fffff7e8d194 <+20>: d65f03c0 ret
End of assembler dump.
The Arm Architecture Reference Manual says that "the prologue, main, and
epilogue instructions are expected to be run in succession and to appear
consecutively in memory". Therefore this patch disables displaced stepping
on them.
The testcase verifies that MOPS sequences are correctly single-stepped.
PR tdep/31666
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
When running test-case gdb.fortran/array-bounds.exp on arm-linux, we run into:
...
(gdb) print &foo^M
$1 = (PTR TO -> ( real(kind=4) (0:1) )) 0xfffef008^M
(gdb) FAIL: gdb.fortran/array-bounds.exp: print &foo
print &bar^M
$2 = (PTR TO -> ( real(kind=4) (-1:0) )) 0xfffef010^M
(gdb) FAIL: gdb.fortran/array-bounds.exp: print &bar
...
This is due to gcc PR debug/54934.
The test-case contains a kfail for this, which is only activated for
x86_64/i386.
Fix this by enabling the kfail for all ilp32 targets.
Also:
- change the kfail into an xfail, because gdb is not at fault here, and
- limit the xfail to the gfortran compiler.
Tested on arm-linux.
|
|
Previously a "stepOut" request when in the outermost frame would result
in a sucessful response even though gdb internally would reject the
associated "finish" request, which means no stoppedEvent would ever be
sent back to the client. Thus the client would believe the inferior was
still running and as a consequence reject subsequent "next" and "stepIn"
requests from the user.
The solution is to execute the underlying finish command as a background
command, i.e. `finish &`. If we're in the outermost frame an exception
will be raised immediately, which we can now capture and report back to
the client as success=False so then the absence of a `stopped` event is
no longer a problem.
We also make use of the `defer_stop_event` option to prevent a stop
event from reaching the client until the response has been sent.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that the value returned by rust_llvm_version had a trailing
carriage return. I don't think this is causing any problems right
now, but looking at the code I don't think this was the desired
behaviour.
The current code runs 'rustc --version --verbose', splits the output
at each '\n' and then loops over every line looking for the line that
contains the LLVM version.
There are two problems here. First, at the end of each captured line
we have '\r\n', so when we split the lines on '\n', each of the lines
will still end with a '\r' character.
Second, though we loop over the lines, when we try to compare the line
contents we actually compare the unsplit full output. Luckily this
still finds the match, but this renders the loop over lines redundant.
This commit makes two fixes:
1. I use regsub to convert all '\r\n' sequences to '\n'; now when we
split on '\n' the lines will not end in '\r'.
2. Within the loop over lines block I now check the line contents
rather than the unsplit full output; now we capture a value
without a trailing '\r'.
There's only one test (gdb.rust/simple.exp) that uses
rust_llvm_version, and it doesn't care if there's a trailing '\r' or
not, so this change should make no difference there.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A co-worker requested that the DAP code emit a scope for global
variables. It's not really practical to do this for all globals, but
it seemed reasonable to do this for globals coming from the frame's
compilation unit. For Ada in particular, this is convenient as it
exposes package-scoped variables.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
In subsequent patches, it's handy if gdb.Block is hashable, so it can
be stored in a set or a dictionary. However, doing this in a
straightforward way is not really possible, because a block isn't
truly immutable -- it can be invalidated. And, while this isn't a
real problem for my use case (in DAP the maps are only used during a
single stop), it seemed error-prone.
This patch instead takes the approach of using the gdb.Block's own
object identity to allow hashing. This seems fine because the
contents don't affect the hashing. In order for this to work, though,
the blocks have to be memoized -- two requests for the same block must
return the same object.
This also allows (actually, requires) the simplification of the
rich-compare method for blocks.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
I noticed a FIXME comment in the DAP code about adding a "source"
field to a scope. This is easy to implement; I don't know why I
didn't do this originally.
|
|
Add tests for looking up debug information within the sysroot via both
build-id and gnu_debuglink.
I wanted to ensure that the gnu_debuglink test couldn't make use of
build-ids, so I added the 'no-build-id' flag to gdb_compile.
As these tests rely on setting the sysroot, if I'm running a
dynamically linked executable, GDB will try to find all shared
libraries within the sysroot. This would mean I'd have to figure out
and copy all shared libraries the executable uses, certainly possible,
but a bit of a pain.
So instead, I've just compiled the test executable as a static binary.
Now there are no shared library dependencies.
I can now split the debug information out from the test binary, and
place it within the sysroot. When GDB is started and the executable
loaded, we can check that GDB is finding the debug information within
the sysroot.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804
Approved-By: Tom de Vries <tdevries@suse.de>
|
