| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Some of the gdb and testsuite files double include some headers. While
all headers use include guards, it helps a bit keeping the code base
tidy.
No functional change.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
gdb.server/server-run.exp
One thing GDB always does when the inferior stops is finding out where
it's stopped at, by way of querying the value of the program counter
register.
To save a packet round trip, the remote target can send the PC
value (often alongside other frequently consulted registers such as the
stack pointer) in the stop reply packet as an "expedited register".
Test that this is actually done for the targets where gdbserver is
supposed to.
Extend the "maintenance print remote-registers" command output with an
"Expedited" column which says "yes" if the register was seen by GDB in
the last stop reply packet it received, and is left blank otherwise.
Tested for regressions on aarch64-linux-gnu native-extended-remote.
The testcase was tested on aarch64-linux-gnu, i686-linux-gnu and
x86_64-linux-gnu native-remote and native-extended-remote targets.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently, gdbserver hangs after stdin is closed while it tries to
write: "Remote side has terminated connection. GDBserver will reopen
the connection." This hang disappears if --once is also given. Since
the stdin connection won't ever reopen if it's closed, it's safe to
assume --once is desired.
The gdb.server/server-pipe.exp test was also updated to reflect this
change. There is now a second disconnect at the end of the proc,
with a tighter-than-normal timeout to catch if the command hangs as
it used to.
Co-Authored-By: Guinevere Larsen <blarsen@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29796
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Clang doesn't add build-id information by default, unlike gcc. This
means that tests that rely on build-id being available and don't
explicitly add it to the compilation options will fail with clang.
This commit fixes the fails in gdb.python/py-missing-debug.exp,
gdb.server/remote-read-msgs.exp, gdb.base/coredump-filter-build-id.exp
and gdb.server/solib-list.exp
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
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.
|
|
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.
|
|
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"
|
|
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>
|
|
INTERNAL_GDBFLAGS contains:
- -quiet
- -iex "set width 0"
- -iex "set height 0"
There are test-cases that add these once more.
Clean this up.
Tested on x86_64-linux.
PR testsuite/31649
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31649
|
|
The commit ed32754a8c7 ("[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for
remote target") intended to addresss the problem that this command:
...
set gdbserver_pid [exp_pid -i $server_spawn_id]
...
does not return the pid of the gdbserver for remote target, but rather the one
of the ssh client session.
To fix this, it added another way of getting the gdbserver_pid.
For the trivial case of non-remote target, the PID found by either method
should be identical, but if we compare those by adding
"puts [exec ps -p $gdbserver_pid]" we get:
...
PID TTY TIME CMD
31711 pts/8 00:00:00 gdbserver
PID TTY TIME CMD
31718 pts/8 00:00:00 server-kill-pyt
...
The problem is that while the gdbserver PID is supposed to be read from the
result of "gdb.execute ('p server_pid')" in the python script, instead it's
taken from:
...
Process server-kill-python created; pid = 31718^M
...
Fix this by moving the printing of the gdbserver PID out of the python script.
Also double-check the two methods against each other, in the cases that they
should match.
Tested on x86_64-linux.
PR testsuite/31633
https://sourceware.org/bugzilla/show_bug.cgi?id=31633
|
|
In test-case gdb.server/server-kill-python.exp we have:
...
if {[gdb_spawn_with_cmdline_opts \
"-quiet -iex \"set height 0\" -iex \"set width 0\" -ex \"source $host_file1\""] != 0} {
fail "spawn"
return
}
...
I reproduced the problem by reverting the fix at the commit adding both the
fix and the test-case, and the reproduced the same problem using:
...
(gdb) source $host_file1
...
so there doesn't seem to be a specific need to source the python file using
"-ex".
Simplify the test-case by sourcing the python file using send_gdb.
This also allow us to simplify the python script.
Tested on x86_64-linux.
|
|
Commit 467a34bb9e6 ("gdb tests: Allow for "LWP" or "process" in thread IDs
from info threads") introduces a new global variable tdlabel_re, but fails to
indicate it's global when used in procs in four test-cases.
Fix this by adding "global tdlabel_re".
Tested on aarch64-linux.
|
|
Several tests assume that the first word after a thread ID in 'info
threads' output is "Thread". However, several targets use "LWP"
instead such as the FreeBSD and NetBSD native targets. The Linux
native target also uses "LWP" if libthread_db is not being used.
Targets that do not support threads use "process" as the first word
via normal_pid_to_str.
Add a tdlabel_re global variable as a regular-expression for a thread
label in `info threads' that matches either "process", "Thread", or
"LWP".
Some other tests in the tree don't require a specific word, and
some targets may use other first words (e.g. OpenBSD uses "thread"
and Ravenscar threads use "Ravenscar Thread").
|
|
On a system without ipv6 support enabled, when running test-case
gdb.server/server-connect.exp, it takes about 4 minutes, and I get:
...
builtin_spawn gdbserver --once ::1:2347 server-connect^M
Can't open socket: Address family not supported by protocol.^M
Exiting^M
PASS: gdb.server/server-connect.exp: tcp6: start gdbserver
target remote tcp6:::1:2347^M
A program is being debugged already. Kill it? (y or n) y^M
could not connect: Address family not supported by protocol.^M
(gdb) FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1
...
Fix this by:
- recognizing the error message in gdbserver_start, and returning an empty list
to signal unsupported, and
- handling the unsupported response in the test-case.
This brings testing time down to 2 seconds, and gets me:
...
UNSUPPORTED: gdb.server/server-connect.exp: tcp6: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: tcp6-with-brackets: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: udp6: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: udp6-with-brackets: start gdbserver
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31502
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31502
|
|
Bug PR gdb/28313 describes attaching to a process when the executable
has been deleted. The bug is for S390 and describes how a user sees a
message 'PC not saved'.
On x86-64 (GNU/Linux) I don't see a 'PC not saved' message, but
instead I see this:
(gdb) attach 901877
Attaching to process 901877
No executable file now.
warning: Could not load vsyscall page because no executable was specified
0x00007fa9d9c121e7 in ?? ()
(gdb) bt
#0 0x00007fa9d9c121e7 in ?? ()
#1 0x00007fa9d9c1211e in ?? ()
#2 0x0000000000000007 in ?? ()
#3 0x000000002dc8b18d in ?? ()
#4 0x0000000000000000 in ?? ()
(gdb)
Notice that the addresses in the backtrace don't seem right, quickly
heading to 0x7 and finally ending at 0x0.
What's going on, in both the s390 case and the x86-64 case is that the
architecture's prologue scanner is going wrong and causing the stack
unwinding to fail.
The prologue scanner goes wrong because GDB has no unwind information.
And GDB has no unwind information because, of course, the executable
has been deleted.
Notice in the example session above we get this line in the output:
No executable file now.
which indicates that GDB failed to find an executable to debug.
For GNU/Linux when GDB tries to find an executable for a given pid we
end up calling linux_proc_pid_to_exec_file in gdb/nat/linux-procfs.c.
Within this function we call `readlink` on /proc/PID/exe to find the
path of the actual executable.
If the `readlink` call fails then we already fallback on using
/proc/PID/exe as the path to the executable to debug.
However, when the executable has been deleted the `readlink` call
doesn't fail, but the path that is returned points to a non-existent
file.
I propose that we add an `access` call to linux_proc_pid_to_exec_file
to check that the target file exists and can be read. If the target
can't be read then we should fall back to /proc/PID/exe (assuming that
/proc/PID/exe can be read).
Now on x86-64 the output looks like this:
(gdb) attach 901877
Attaching to process 901877
Reading symbols from /proc/901877/exe...
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6
(gdb) bt
#0 0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6
#1 0x00007fa9d9c1211e in sleep () from /lib64/libc.so.6
#2 0x000000000040117e in spin_forever () at attach-test.c:17
#3 0x0000000000401198 in main () at attach-test.c:24
(gdb)
which is much better.
I've also tagged the bug PR gdb/29782 which concerns the test
gdb.server/connect-with-no-symbol-file.exp. After making this change,
when running gdb.server/connect-with-no-symbol-file.exp GDB would now
pick up the /proc/PID/exe file as the executable in some cases.
As GDB is not restarted for the multiple iterations of this test
GDB (or rather BFD) would given a warning/error like:
(gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: disconnect
set sysroot target:
BFD: reopening /proc/3283001/exe: No such file or directory
(gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: adjust sysroot
What's happening is that an executable found for an earlier iteration
of the test is still registered for the inferior when we are setting
up for a second iteration of the test. When the sysroot changes, if
there's an executable registered GDB tries to reopen it, but in this
case the file has disappeared (the previous inferior has exited by
this point).
I did think about maybe, when the executable is /proc/PID/exe, we
should auto-delete the file from the inferior. But in the end I
thought this was a bad idea. Not only would this require a lot of
special code in GDB just to support this edge case: we'd need to track
if the exe file name came from /proc and should be auto-deleted, or
we'd need target specific code to check if a path should be
auto-deleted.....
... in addition, we'd still want to warn the user when we auto-deleted
the file from the inferior, otherwise they might be surprised to find
their inferior suddenly has no executable attached, so we wouldn't
actually reduce the number of warnings the user sees.
So in the end I figured that the best solution is to just update the
test to avoid the warning. This is easily done by manually removing
the executable from the inferior once each iteration of the test has
completed.
Now, in bug PR gdb/29782 GDB is clearly managing to pick up an
executable from the NFS cache somehow. I guess what's happening is
that when the original file is deleted /proc/PID/exe is actually
pointing to a file in the NFS cache which is only deleted at some
later point, and so when GDB starts up we do manage to associate a
file with the inferior, this results in the same message being emitted
from BFD as I was seeing. The fix included in this commit should also
fix that bug.
One final note: On x86-64 GNU/Linux, the
gdb.server/connect-with-no-symbol-file.exp test will produce 2 core
files. This is due to a bug in gdbserver that is nothing to do with
this test. These core files are created before and after this
commit. I am working on a fix for the gdbserver issue, but will post
that separately.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28313
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29782
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
Building on the last commit, which added a general --debug=COMPONENT
option to the gdbserver command line, this commit updates the monitor
command to allow for general:
(gdb) monitor set debug COMPONENT off|on
style commands. Just like with the previous commit, the COMPONENT can
be any one of all, threads, remote, event-loop, and correspond to the
same set of global debug flags.
While on the command line it is possible to do:
--debug=remote,event-loop,threads
the components have to be entered one at a time with the monitor
command. I guess there's no reason why we couldn't allow component
grouping within the monitor command, but (to me) what I have here
seemed more in the spirit of GDB's existing 'set debug ...' commands.
If people want it then we can always add component grouping later.
Notice in the above that I use 'off' and 'on' instead of '0' and '1',
which is what the 'monitor set debug' command used to use. The 0/1
can still be used, but I now advertise off/on in all the docs and help
text, again, this feels more inline with GDB's existing boolean
settings.
I have removed the two existing monitor commands:
monitor set remote-debug 0|1
monitor set event-loop-debug 0|1
These are replaced by:
monitor set debug remote off|on
monitor set debug event-loop off|on
respectively.
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Following on from this commit:
commit f2c4f78c813a9cef38b7e9c9ad18822fb9e19345
Date: Thu Sep 21 16:35:30 2023 +0100
gdb: fix reread_symbols when an objfile has target: prefix
In this commit I update reopen_exec_file to correctly handle
executables with a target: prefix. Before this commit we used the
system 'stat' call, which obviously isn't going to work for files with
a target: prefix (files located on a possibly remote target machine).
By switching to bfd_stat we will use remote fileio to stat the remote
files, which means we should now correctly detect changes in a remote
executable.
The program_space::ebfd_mtime variable, with which we compare the
result of bfd_stat is set with a call to bfd_get_mtime, which in turn
calls bfd_stat, so comparing to the result of calling bfd_stat makes
sense (I think).
As I discussed in the commit f2c4f78c813a, if a BFD is an in-memory
BFD, then calling bfd_stat will always return 0, while bfd_get_mtime
will always return the time at which the BFD was created. As a result
comparing the results will always show the file having changed.
I don't believe that GDB can set the main executable to an in-memory
BFD object, so, in this commit, I simply assert that the executable is
not in-memory. If this ever changes then we would need to decide how
to handle this case -- always reload, or never reload. The assert
doesn't appear to trigger for our current test suite.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When using a remote target, it is possible to tell GDB that the
executable to be debugged is located on the remote machine, like this:
(gdb) target extended-remote :54321
... snip ...
(gdb) file target:/tmp/hello.x
Reading /tmp/hello.x from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /tmp/hello.x from remote target...
Reading symbols from target:/tmp/hello.x...
(gdb)
So far so good. However, when we try to start the inferior we run
into a small problem:
(gdb) set remote exec-file /tmp/hello.x
(gdb) start
`target:/tmp/hello.x' has disappeared; keeping its symbols.
Temporary breakpoint 1 at 0x401198: file /tmp/hello.c, line 18.
Starting program: target:/tmp/hello.x
... snip ...
Temporary breakpoint 1, main () at /tmp/hello.c:18
18 printf ("Hello World\n");
(gdb)
Notice this line:
`target:/tmp/hello.x' has disappeared; keeping its symbols.
That's wrong, the executable hasn't been removed, GDB just doesn't
know how to check if the remote file has changed, and so falls back to
assuming that the file has been removed.
In this commit I update reread_symbols to use bfd_stat instead of
a direct stat call, this adds support for target: files, and fixes the
problem.
This change was proposed before in this commit:
https://inbox.sourceware.org/gdb-patches/20200114210956.25115-3-tromey@adacore.com/
However, that patch never got merged, and seemed to get stuck
discussing issues around gnulib stat vs system stat as used by BFD.
I didn't 100% understand the issues discussed in that thread, however,
I think the problem with the previous thread related to the changes in
gdb_bfd.c, rather than to the change in symfile.c. As such, I think
this change might be acceptable, my reasoning is:
- the objfile::mtime field is set by a call to bfd_get_mtime (see
objfiles.c), which calls bfd_stat under the hood. This will end
up using the system stat,
- In symfile.c we currently call stat directly, which will call the
gnulib stat, which, if I understand the above thread correctly,
might give a different result to the system stat in some cases,
- By switching to using bfd_stat in symfile.c we should now be
consistently calling the system stat.
There is another issue that came up during testing that this commit
fixes. Consider this GDB session:
$ gdb -q
(gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
Remote debugging using | ./gdbserver/gdbserver --multi --once -
Remote debugging using stdio
(gdb) file /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) set remote exec-file /tmp/hello.x
(gdb) start
... snip ...
(gdb) load
`system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
Loading section .interp, size 0x1c lma 0x4002a8
... snip ...
Start address 0x0000000000401050, load size 2004
Transfer rate: 326 KB/sec, 87 bytes/write.
Notice this line:
`system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
We actually see the same output, for the same reasons, when using a
native target, like this:
$ gdb -q
(gdb) file /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) start
... snip ...
(gdb) load
`system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
You can't do that when your target is `native'
(gdb)
In both cases this line appears because load_command (symfile.c) calls
reread_symbols, and reread_symbols loops over every currently loaded
objfile and tries to check if the file has changed on disk by calling
stat.
However, the `system-supplied DSO at 0x7ffff7fcf000' is an in-memory
BFD, the filename for this BFD is literally the string
'system-supplied DSO at 0x7ffff7fcf000'.
Before this commit GDB would try to use the system 'stat' call to stat
the file `system-supplied DSO at 0x7ffff7fcf000', which obviously
fails; there's no file with that name (usually). As a consequence of
the stat failing GDB prints the ' .... has disappeared ...' line.
Initially, all this commit did was switch from using 'stat' to using
'bfd_stat'. Calling bfd_stat on an in-memory BFD works just fine,
however, BFD just fills the 'struct stat' buffer with zeros (except
for the file size), see memory_bstat in bfd/bfdio.c.
However, there is a bit of a weirdness about in-memory BFDs. When
they are initially created the libbfd caches an mtime within the bfd
object, this is done in bfd_from_remote_memory (elfcode.h), the cached
mtime is the time at which the in-memory BFD is created.
What this means is that when GDB creates the in-memory BFD, and we
call bfd_get_mtime(), the value returned, which GDB caches within
objfile::mtime is the creation time of the in-memory BFD. But, when
this patch changes to use bfd_stat() we now get back 0, and so we
believe that the in-memory BFD has changed. This is a change in
behaviour.
To avoid this change in behaviour, in this commit, I propose that we
always skip in-memory BFDs in reread_symbols. This preserves the
behaviour from before this commit -- mostly.
As I'm not specifically checking for, and then skipping, in-memory
BFDs, we no longer see this line:
`system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
Which I think is an improvement.
Co-Authored-By: Tom Tromey <tromey@adacore.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When running the gdb testsuite inside a container, I run into:
...
(gdb) gdb_expect_list pattern: /1 +root +[/a-z]*(init|systemd)/
FAIL: gdb.server/ext-run.exp: get process list (pattern 2)
...
because there's no process with pid 1 and cmd init or systemd.
In the host system (where the test passes), I have:
...
$ ps -f 1
UID PID PPID C STIME TTY STAT TIME CMD
root 1 0 0 Sep25 ? Ss 0:03 /usr/lib/systemd/systemd ...
...
but in the container instead:
...
UID PID PPID C STIME TTY STAT TIME CMD
root 1 0 0 11:45 pts/0 Ss 0:00 /bin/bash
...
Fix this by also accepting bash as a valid cmd.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A local gdb test failed with this error message:
Remote communication error. Target disconnected.: Arg list too long.
The ".:" seemed weird to me. This patch removes the ".".
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
After this commit:
commit ed32754a8c7919feffc6ddb66ff1c532e4a4d1cd
Date: Thu Mar 9 10:45:03 2023 +0100
[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target
I noticed the occasional failure in gdb.server/multi-ui-errors.exp,
which looked like this:
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
interrupt
(gdb)
Program received signal SIGINT, Interrupt.
0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6
FAIL: gdb.server/multi-ui-errors.exp: interrupt (timeout)
PASS: gdb.server/multi-ui-errors.exp: interrupt arrived
p server_pid
$1 = 718174
(gdb) PASS: gdb.server/multi-ui-errors.exp: p server_pid
This is triggered by this code in gdb.server/multi-ui-errors.exp:
gdb_test "interrupt"
gdb_test_multiple "" "interrupt arrived" {
-re "Program received signal SIGINT, Interrupt\\.\r\n" {
pass $gdb_test_name
}
}
The problem here is that the first interrupt will trigger the prompt
to be printed, and then, after some time the inferior will be
interrupted.
However the default pattern for gdb_test includes a '$' end anchor.
If expect sees the prompt with nothing following it then everything is
fine, and the test passes.
However, if the interrupt is quick and so what expect sees is this:
(gdb)
Program received signal SIGINT, Interrupt.
0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6
In this case the end anchor means that the gdb_test fails to match,
and eventually times out.
Fix this by passing -no-prompt-anchor to gdb_test.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
When using a compiler defaulting to -std=gnu90, we run into:
...
Running gdb.server/attach-flag.exp ...
gdb compile failed, attach-flag.c: In function 'main':
attach-flag.c:22:3: error: 'for' loop initial declarations are only allowed \
in C99 or C11 mode
for (int i = 0; i < NTHREADS; i++)
^~~
attach-flag.c:22:3: note: use option -std=c99, -std=gnu99, -std=c11 or \
-std=gnu11 to compile your code
...
Fix this by using -std=gnu99.
Tested on x86_64-linux.
|
|
This commit follows on from the following two commits:
commit 80dc83fd0e70f4d522a534bc601df5e05b81d564
Date: Fri Jun 11 11:30:47 2021 +0100
gdb/remote: handle target dying just before a stepi
And:
commit 079f190d4cfc6aa9c934b00a9134bc0fcc172d53
Date: Thu Mar 9 10:45:03 2023 +0100
[gdb/testsuite] Fix gdb.server/server-kill.exp for remote target
The first of these commits fixed an issue in GDB and tried to extend
the gdb.server/server-kill.exp test to cover the GDB fix.
Unfortunately, the changes to gdb.server/server-kill.exp were not
correct, and were causing problems when trying to run with the
remote-gdbserver-on-localhost board file.
The second commit reverts some of the gdb.server/server-kill.exp
changes introduced in the first commit so that the test will now work
correctly with the remote-gdbserver-on-localhost board file.
The second commit is just about GDB's testing infrastructure -- it's
not about the original fix to GDB from the first commit, the actual
GDB change was fine.
While reviewing the second commit I wanted to check that the problem
fixed in the first commit is still being tested by the
gdb.server/server-kill.exp script, so I reverted the change to
breakpoint.c that is the core of the first commit and ran the test
script ..... and saw no failures.
The first commit is about GDB discovering that gdbserver has died
while trying to insert a breakpoint. As soon as GDB spots that
gdbserver is gone we mourn the remote inferior, which ends up deleting
all the breakpoints associated with the remote inferiors. We then
throw an exception which is caught in the insert breakpoints code, and
we try to display an error that includes the breakpoint number
.... but the breakpoint has already been deleted ... and so GDB
crashes.
After digging a little, what I found is that today, when the test does
'stepi' the first thing we end up doing is calculating the frame-id as
part of the stepi logic, it is during this frame-id calculation that
we mourn the remote inferior, delete the breakpoints, and throw an
exception. The exception is caught by the top level interpreter loop,
and so we never try to print the breakpoint number which is what
caused the original crash.
If I add an 'info frame' command to the test script, prior to killing
gdbserver, then now when we 'stepi' GDB already has the frame-id
calculated, and the first thing we do is try to insert the
breakpoints, this will trigger the original bug.
In order to reproduce this experiment you'll need to change a function
in breakpoint.c, like this:
static void
rethrow_on_target_close_error (const gdb_exception &e)
{
return;
}
Then run gdb.server/server-kill.exp with and without this patch. You
should find that without this patch there are zero test failures,
while with this patch there will be one failure like this:
(gdb) PASS: gdb.server/server-kill.exp: test_stepi: info frame
Executing on target: kill -9 4513 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 4513
stepi
../../src/gdb/breakpoint.c:2863: internal-error: insert_bp_location: Assertion `bl->owner != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
...
|
|
Fix test-case gdb.server/server-kill-python.exp for remote host using
gdb_remote_download.
Tested on x86_64-linux.
|
|
Fix test-case gdb.server/sysroot.exp for remote host, by:
- using gdb_remote_download, and
- disabling the "local" scenario for remote host/target, unless
remote host == remote target.
Tested on x86_64-linux.
|
|
Require non-remote host for test-case gdb.server/multi-ui-errors.exp, because
it uses "spawn -pty", which creates a pty on build, which gdb cannot use on
remote host.
Tested on x86_64-linux.
|
|
Fix test-case gdb.server/solib-list.exp for remote host using
gdb_remote_download.
Likewise in another test-case.
Tested on x86_64-linux.
|
|
Fix test-case gdb.server/file-transfer.exp for remote host using
gdb_remote_download and host_standard_output_file.
Tested on x86_64-linux.
|
|
remote-gdbserver-on-localhost
With test-case gdb.server/non-existing-program.exp and native, I have reliably:
...
(gdb) builtin_spawn gdbserver stdio non-existing-program^M
stdin/stdout redirected^M
/bin/bash: line 0: exec: non-existing-program: not found^M
During startup program exited with code 127.^M
Exiting^M
PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
...
But with target board remote-gdbserver-on-localhost I sometimes have:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l remote-target localhost gdbserver \
stdio non-existing-program^M
stdin/stdout redirected^M
/bin/bash: line 0: exec: non-existing-program: not found^M
During startup program exited with code 127.^M
Exiting^M
Connection to localhost closed.^M^M
PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
...
and sometimes the exact same output, but a FAIL instead.
Fix this by replacing "Exiting\r\n$" with "Exiting\r\n" in the regexps.
Tested on x86_64-linux.
|
|
This changes many tests to use 'require' when checking target_info.
In a few spots, the require is hoisted to the top of the file, to
avoid doing any extra work when the test is going to be skipped
anyway.
|
|
Fix test-cases for target board remote-gdbserver-on-localhost by using
gdb_remote_download.
Tested on x86_64-linux.
|
|
With test-case gdb.server/unittest.exp and a build with --disable-unit-tests I
get:
...
(gdb) builtin_spawn /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver \
--selftest^M
Selftests have been disabled for this build.^M
UNSUPPORTED: gdb.server/unittest.exp: unit tests
...
but with target board remote-stdio-gdbserver I get instead:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \
/data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M
Selftests have been disabled for this build.^M
Connection to localhost closed.^M^M
FAIL: gdb.server/unittest.exp: unit tests
...
Fix this by making the regexp less strict.
Tested on x86_64-linux.
|
|
Fix test-case gdb.server/sysroot.exp with target board
remote-gdbserver-on-localhost, by:
- using gdb_remote_download, and
- disabling the "local" scenario for remote host.
Tested on x86_64-linux.
|
|
Test-case gdb.server/multi-ui-errors.exp fails for target board
remote-gdbserver-on-localhost with REMOTE_TARGET_USERNAME=remote-target:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
Executing on target: kill -9 6447 (timeout = 300)
builtin_spawn [open ...]^M
XYZ1ZYX
sh: line 0: kill: (6447) - Operation not permitted
...
The problem is that the kill command:
...
remote_exec target "kill -9 $gdbserver_pid"
...
intended to kill gdbserver instead tries to kill the ssh client session in
which the gdbserver runs, and fails because it's trying as the remote target
user (remote-target on localhost) to kill a pid owned by the the build user
($USER on localhost).
Fix this by getting the gdbserver pid using the ppid trick from
server-kill.exp.
Likewise in gdb.server/server-kill-python.exp.
Tested on x86_64-linux.
|
|
In commit 80dc83fd0e7 ("gdb/remote: handle target dying just before a stepi")
an observation is made that test-case gdb.server/server-kill.exp claims to
kill gdbserver, but actually kills the inferior. Consequently, the commit
adds testing of killing gdbserver alongside.
The problem is that:
- the original observation is incorrect (possibly caused by misreading getppid
as getpid)
- consequently, the test-case doesn't test killing the inferior, instead it
tests killing gdbserver twice
- the method to get the gdbserver PID added in the commit doesn't work
for target board remote-gdbserver-on-localhost, it returns the
PID of the ssh client session instead.
Fixing the method for getting the inferior PID gives us fails, and there's no
evidence that killing the inferior ever worked.
So, fix this by reverting the commit and just killing gdbserver, using the
original method of getting the gdbserver PID which does work for target board
remote-gdbserver-on-localhost.
Tested on x86_64-linux.
|
|
Test-case gdb.server/connect-with-no-symbol-file.exp fails with target board
remote-gdbserver-on-localhost.
The problem is here:
...
set target_exec [gdb_remote_download target $binfile.bak $binfile]
...
A "gdb_remote_download target" copies from build to target. So $binfile is
assumed to be a target path, but it's actually a build path.
Fix this by:
- fist copying $binfile.bak to $binfile, and
- simply doing [gdb_remote_download target $binfile].
Then, $binfile.bak is created here:
...
# Make sure we have the original symbol file in a safe place to copy from.
gdb_remote_download host $binfile $binfile.bak
...
and since "gdb_remote_download host" copies from build to host, $binfile.bak
is assumed to be a host path, but it's actually a build path. This happens to
cause no problems in this configuration (because build == host), but it would
for a remote host configuration.
So let's fix this by making build rather than host the "safe place to copy
from".
Tested on x86_64-linux.
|
|
This patch applies the appropriate FIXME notes described in commit 5b6d1e4
"Multi-target support".
"You'll notice that remote.c includes some FIXME notes. These refer to
the fact that the global arrays that hold data for the remote packets
supported are still globals. For example, if we connect to two
different servers/stubs, then each might support different remote
protocol features. They might even be different architectures, like
e.g., one ARM baremetal stub, and a x86 gdbserver, to debug a
host/controller scenario as a single program. That isn't going to
work correctly today, because of said globals. I'm leaving fixing
that for another pass, since it does not appear to be trivial, and I'd
rather land the base work first. It's already useful to be able to
debug multiple instances of the same server (e.g., a distributed
cluster, where you have full control over the servers installed), so I
think as is it's already reasonable incremental progress."
Using this patch it is possible to configure per-remote targets'
feature packets.
Given the following setup for two gdbservers:
~~~~
gdbserver --multi :1234
gdbserver --disable-packet=vCont --multi :2345
~~~~
Before this patch configuring of range-stepping was not possible for one
of two connected remote targets with different support for the vCont
packet. As one of the targets supports vCont, it should be possible to
configure "set range-stepping". However, the output of GDB looks like:
(gdb) target extended-remote :1234
Remote debugging using :1234
(gdb) add-inferior -no-connection
[New inferior 2]
Added inferior 2
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) target extended-remote :2345
Remote debugging using :2345
(gdb) set range-stepping on
warning: Range stepping is not supported by the current target
(gdb) inferior 1
[Switching to inferior 1 [<null>] (<noexec>)]
(gdb) set range-stepping on
warning: Range stepping is not supported by the current target
~~~~
Two warnings are shown. The warning for inferior 1 should not appear
as it is connected to a target supporting the vCont package.
~~~~
(gdb) target extended-remote :1234
Remote debugging using :1234
(gdb) add-inferior -no-connection
[New inferior 2]
Added inferior 2
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) target extended-remote :2345
Remote debugging using :2345
(gdb) set range-stepping on
warning: Range stepping is not supported by the current target
(gdb) inferior 1
[Switching to inferior 1 [<null>] (<noexec>)]
(gdb) set range-stepping on
(gdb)
~~~~
Now only one warning is shown for inferior 2, which is connected to
a target not supporting vCont.
The per-remote target feature array is realized by a new class
remote_features, which stores the per-remote target array and
provides functions to determine supported features of the target.
A remote_target object now has a new member of that class.
Each time a new remote_target object is initialized, a new per-remote
target array is constructed based on the global remote_protocol_packets
array. The global array is initialized in the function _initialize_remote
and can be configured using the command line. Before this patch the
command line configuration affected current targets and future remote
targets (due to the global feature array used by all remote
targets). This behavior is different and the configuration applies as
follows:
- If a target is connected, the command line configuration affects the
current connection. All other existing remote targets are not
affected.
- If not connected, the command line configuration affects future
connections.
The show command displays the current remote target's configuration. If no
remote target is selected the default configuration for future
connections is shown.
If we have for instance the following setup with inferior 2 being
selected:
~~~~
(gdb) info inferiors
Num Description Connection Executable
1 <null> 1 (extended-remote :1234)
* 2 <null> 2 (extended-remote :2345)
~~~~
Before this patch, if we run 'set remote multiprocess-feature-packet', the
following configuration was set:
The feature array of all remote targets (in this setup the two connected
targets) and all future remote connections are affected.
After this patch, it will be configured as follows:
The feature array of target with port :2345 which is currently selected
will be configured. All other existing remote targets are not affected.
The show command 'show remote multiprocess-feature-packet' will display
the configuration of target with port :2345.
Due to this configuration change, it is required to adapt the test
"gdb/testsuite/gdb.multi/multi-target-info-inferiors.exp" to configure the
multiprocess-feature-packet before the connections are created.
To inform the gdb user about the new behaviour of the 'show remote
PACKET-NAME' commands and the new configuration impact for remote
targets using the 'set remote PACKET-NAME' commands the commands'
outputs are adapted. Due to this change it is required to adapt each
test using the set/show remote 'PACKET-NAME' commands.
|
|
This changes some tests to use require with 'is_remote', rather than
an explicit test. This adds uniformity helps clean up more spots
where a test might exit early without any notification.
|
|
A number of tests will exit early without saying why. This patch adds
"unsupported" at spots like this that I could readily find.
There are definitely more of these; for example dw2-ranges.exp fails
silently because a compilation fails. I didn't attempt to address
these as that is a much larger task.
|
|
A few tests work on two different targets that can't be detected with
a single call to istarget -- that proc only accepts globs, not regular
expressions.
This patch introduces a new is_any_target proc and then converts these
tests to use it in a 'require'.
|
|
This changes skip_shlib_tests to invert the sense, and renames it to
allow_shlib_tests.
|
|
This changes skip_python_tests to invert the sense, and renames it to
allow_python_tests.
|
|
This changes skip_gdbserver_tests to invert the sense, and renames it
to allow_gdbserver_tests.
|
|
This changes gdb_skip_xml_test to invert the sense, and renames it to
allow_xml_test.
|
|
This changes various tests to use "require" for the Python feature.
|
|
This changes some tests to use "require !skip_gdbserver_tests".
|
|
This changes some tests to use "require can_spawn_for_attach".
|
|
This changes some tests to use "require !skip_shlib_tests".
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
