| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix clean_restart <absolute filename> in gdb.arch/arm*.exp.
Tested on:
- arm-linux, target boards unix/-marm and unix/-mthumb
- aarch64-linux
|
|
Fix clean_restart <absolute filename> in gdb.arch/aarch64*.exp.
Tested on aarch64-linux, M1 system.
There's a large number (44) of unsupported, for the following reasons:
- allow_aarch64_gcs_tests
- allow_aarch64_mops_tests
- allow_aarch64_sve_tests / target does not support SVE
- memory tagging unsupported
Consequently, we mostly use the simple substitution:
...
clean_restart $binfile
->
clean_restart
gdb_load $binfile
...
|
|
Fix clean_restart <absolute filename> in gdb.arch/i386*.exp.
Tested on x86_64-linux, with target board unix/-m32 and gcc 15.
The only unsupported test-case is gdb.arch/i386-avx512.exp, which isn't
changed by this commit.
|
|
Fix clean_restart <absolute filename> in gdb.arch/amd64*.exp.
Tested on x86_64-linux, with kernel version 6.16.3.
The only unsupported test-case is gdb.arch/amd64-lam.exp, which isn't changed
by this commit.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.ada.
Tested on x86_64-linux with gcc 14.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.compile.
Tested on x86_64-linux, fedora rawhide.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.cp.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.debuginfod.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.disasm.
The changed test-cases:
- gdb.disasm/am33.exp
- gdb.disasm/hppa.exp
- gdb.disasm/mn10300.exp
- gdb.disasm/sh3.exp
are unsupported for me, but the changes are trivial.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.dwarf2.
Tested on x86_64-linux using gcc-14.
Tested these test-cases on x86_64-linux with target board unix/-m32:
- gdb.dwarf2/valop.exp
- gdb.dwarf2/callframecfa.exp
- gdb.dwarf2/implptr.exp
- gdb.dwarf2/watch-notconst.exp
- gdb.dwarf2/pieces.exp
- gdb.dwarf2/pieces-optimized-out.exp
Tested these test-cases on x86_64-linux with target board fission-dwp:
- gdb.dwarf2/dwp-symlink.exp
- gdb.dwarf2/dwp-sepdebug.exp
Tested test-case gdb.dwarf2/gdb-index-tilde.exp on x86_64-linux by disabling a
too strict home directory check, see PR testsuite/33364.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.fortran.
Tested on x86_64-linux, with gcc 14.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.gdb.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.guile.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.linespec.
Tested on x86_64-linux.
|
|
Fix mi_clean_restart <absolute filename> in the test-cases in gdb.mi.
Tested on x86_64-linux.
Also tested test-case gdb.mi/mi-dprintf.exp with target boards
native-gdbserver and native-extended-gdbserver.
Since test-case gdb.mi/mi-regs.exp requires istarget "sparc-*-*", I didn't
test the trivial change in that test-case.
|
|
Fix mi_clean_restart <absolute filename> in the test-cases in gdb.trace.
Tested on x86_64-linux, with target boards unix, native-gdbserver and
native-extended-gdbserver.
|
|
We can't put a breakpoint in the middle of a ll/sc atomic sequence,
so look for the end of the sequence and put the breakpoint there,
it has been handled in the commit 208b57e53ed9 ("gdb: LoongArch:
Deal with atomic sequence").
Especially, maybe there is a conditional branch instruction in the
middle of a ll/sc atomic sequence, its destination address may be
current pc + 4 which is inside the atomic sequence, it should not
put a breakpoint in its destination address in this case, this has
been handled in the commit a4242dc3f5fa ("gdb: LoongArch: Improve
the handling of atomic sequence").
Additionally, if there is a conditional branch instruction in the
middle of a ll/sc atomic sequence, its destination address may be
not current pc + 4 but still inside the atomic sequence, it should
not put a breakpoint in its destination address in this case.
So in order to avoid putting a breakpoint in the middle of a ll/sc
atomic sequence in any case, just look for the start and end of the
sequence, and restrict the breakpoint outside of the atomic sequence.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
In the current loongarch_deal_with_atomic_sequence(), it is just a loop
through a ll/sc atomic instruction sequence, the instructions before the
condition branch are not actually executed, thus the condition register
value is not proper to determine the destination address.
Add a new function cond_branch_destination_address() to calculate the
destination address of a condition branch instruction under an assumed
true condition, then only put a breakpoint at this address when it is
outside of the ll/sc atomic instruction sequence.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.multi.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.objc.
Tested on x86_64-linux, using 'lappend options "nowarnings"' in
gdb_compile_shlib_pthreads. See also PR testsuite/24807.
|
|
In test-case gdb.opencl/callfuncs.exp I noticed:
...
clean_restart [standard_testfile $testfile]
...
This doesn't have the desired effect of starting gdb with $testfile because
standard_testfile doesn't return anything.
Fix this by using "clean_restart $testfile".
While we're at it:
- move standard_testfile to the start of the file
- drop the redundant 'set testfile "callfuncs"'
- use standard_testfile .cl to properly define $srcfile
- use $srcfile instead of $testfile.cl
Tested on x86_64-linux, using the demonstrator patch in PR testsuite/33363.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33363
|
|
The test gdb.base/gcore-memory-usage is meant to show that the memory
requirements of GDB's gcore command don't grow with the memory usage
of the inferior. It was using hardcoded values for memory, but the
values were too small when building GDB with address sanitizer. This
commit fixes one of the failures by increasing the limit on the first
gcore call.
But, rather than just increasing the hardcoded limit for the second
call, we instead save the amount of memory used in the first call and
ensure that the second call doesn't use more memory than the first.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33148
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.opt.
Tested on x86_64-linux using gcc 14.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.perf.
Tested on x86_64-linux using check-perf.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.python.
Tested on x86_64-linux.
|
|
Since commit 3cb6bc13e328 ("gdb/progspace: add solib_ops pointer in
program_space"), and with the previous patch applied ("gdb/remote: use
scoped_restore_current_program_space in remote_unpush_target"), we get
this failure:
$ make check TESTS="gdb.server/extended-remote-restart.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
In gdb.log:
(gdb) PASS: gdb.server/extended-remote-restart.exp: kill: 0, follow-child 1: disconnect
target extended-remote localhost:2348
Remote debugging using localhost:2348
/home/smarchi/src/binutils-gdb/gdb/progspace.h:240: internal-error: set_solib_ops: Assertion `m_solib_ops == nullptr' failed.
When connecting to a remote that has one or more inferior already
running, the remote target (the GDB-side code) tries to re-use existing
GDB inferiors that are unused. The problem is that the program space of
the inferior that gets re-used unexpectedly has its solib_ops set.
I think that the problem is that when connecting to a remote target that
has multiple inferiors, target_pre_inferior only gets called for the
currently selected (client-side) inferior. It happens here:
#0 target_pre_inferior () at /home/smarchi/src/wt/amd/gdb/target.c:2454
#1 0x0000559c832a350a in target_preopen (from_tty=1) at /home/smarchi/src/wt/amd/gdb/target.c:2510
#2 0x0000559c82e1b8f1 in remote_target::open_1 (name=0x50200006eb58 ":2345", from_tty=1, extended_p=1) at /home/smarchi/src/wt/amd/gdb/remote.c:6171
#3 0x0000559c82e18a5d in extended_remote_target::open (name=0x50200006eb58 ":2345", from_tty=1) at /home/smarchi/src/wt/amd/gdb/remote.c:5446
#4 0x0000559c8329a43e in open_target (args=0x50200006eb58 ":2345", from_tty=1, command=0x512000072c40) at /home/smarchi/src/wt/amd/gdb/target.c:839
I think that target_pre_inferior should be called for the other
inferiors that gain execution as a result of connecting to the remote
target, to make sure inferior or program space-specific data from
previous executions gets cleared. target_pre_inferior is what clears
any previous solib_ops.
It is possible to observe the problem by adding this print in
target_pre_inferior:
printf (">>> target_pre_inferior called for inferior %d\n",
current_inferior ()->num);
Then, starting a gdbserver:
$ gdbserver --multi localhost:2345
Then, this gdb command that starts two remote inferiors, disconnects
(leaving gdbserver and the inferiors running), then reconnects:
$ ./gdb -nx --data-directory=data-directory -q \
-ex 'set sysroot /' \
-ex 'target extended-remote :2345' \
-ex 'file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'set remote exec-file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'b main' \
-ex r \
-ex 'add-inferior' \
-ex 'inferior 2' \
-ex 'file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'run' \
-ex 'inferior 1' \
-ex 'disconnect' \
-ex 'echo About to reconnect\n' \
-ex 'target extended-remote :2345'
>>> target_pre_inferior called for inferior 1
Remote debugging using :2345
Reading symbols from /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart...
Breakpoint 1 at 0x11fc: file /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c, line 50.
>>> target_pre_inferior called for inferior 1
Starting program: /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart
Breakpoint 1, main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
[New inferior 2]
Added inferior 2 on connection 1 (extended-remote :2345)
[Switching to inferior 2 [<null>] (<noexec>)]
Reading symbols from /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart...
>>> target_pre_inferior called for inferior 2
Starting program: /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart
Thread 2.1 "extended-remote" hit Breakpoint 1.2, main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
[Switching to inferior 1 [process 2591936] (/home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart)]
[Switching to thread 1.1 (Thread 2591936.2591936)]
#0 main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
Ending remote debugging.
About to reconnect
>>> target_pre_inferior called for inferior 1
Remote debugging using :2345
main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
We can see that target_pre_inferior is only called for inferior 1 when
reconnecting (after the "About to reconnect" message).
After adding the call to target_pre_inferior in remote_add_inferior, we
get (just the last bit):
About to reconnect
>>> target_pre_inferior called for inferior 1
Remote debugging using :2345
>>> target_pre_inferior called for inferior 1
>>> target_pre_inferior called for inferior 2
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
(No debugging symbols found in /lib/x86_64-linux-gnu/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)
main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
The duplicate calls to target_pre_inferior for inferior 1 are due to the
existing call in target_preopen. It might be possible to get rid of it:
with the call I added in remote_target::remote_add_inferior, I presume
it's now unnecessary for the remote target to have the call in
target_preopen as well. But since target_preopen is used by other
targets, I prefer to leave it there to be safe, for the moment. Calling
target_pre_inferior multiple times should not be a problem, as it should
be idempotent.
However, once I added that, test gdb.server/stop-reply-no-thread.exp
started failing, with this in the logs:
target remote localhost:2347
Remote debugging using localhost:2347
Remote 'g' packet reply is too long (expected 560 bytes, got 820 bytes): 000000... <truncated>
It became apparent that the new call to target_pre_inferior would wipe a
previously fetched target description. I fixed that by adding calls to
target_find_description in two callers of remote_add_inferior. I'm not
100% sure of what I'm doing here, but it seems somewhat correct that
when we map a remote inferior to an existing client-side inferior, we
wipe out any previous target description (which would have been left by
a previous execution) and fetch a new one.
The other call to remote_add_inferior is in
extended_remote_target::attach, where there is already a call to
target_find_description shortly after.
Change-Id: I85426bfff286a67d5fb74bbf978df80060ee6deb
|
|
Since commit 3cb6bc13e328 ("gdb/progspace: add solib_ops pointer in
program_space"), this fails with an internal error:
$ make check TESTS="gdb.server/extended-remote-restart.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
In gdb.log:
(gdb) PASS: gdb.server/extended-remote-restart.exp: kill: 1, follow-child 0: disconnect
target extended-remote localhost:2347
Remote debugging using localhost:2347
/home/smarchi/src/binutils-gdb/gdb/progspace.h:240: internal-error: set_solib_ops: Assertion `m_solib_ops == nullptr' failed.
The issue is that remote_unpush_target uses
scoped_restore_current_inferior to save the context, which only restores
the current inferior on exit. But it then uses
switch_to_inferior_no_thread, which switches the inferior and the
program space. The program space is therefore left unrestored. This
can leave the current inferior and current program space out of sync.
With two inferiors, let's say we enter with current inferior == 1 and
current program space == 1. When calling switch_to_inferior_no_thread
for inferior 2, we set the current inferior to 2 and current program
space to 2. On exit, only the original inferior is restored, so we end
up with current inferior == 1 and current program space == 2.
The problem can be observed manually by starting two remote inferiors
and disconnecting while inferior 1 is selected:
$ ./gdb -nx --data-directory=data-directory -q \
-ex 'set sysroot /' \
-ex 'target extended-remote | gdbserver --multi --once -' \
-ex 'file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'set remote exec-file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'b main' \
-ex r \
-ex 'add-inferior' \
-ex 'inferior 2' \
-ex 'file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'run' \
-ex 'inferior 1' \
-ex 'disconnect'
Then, connecting top-gdb to that gdb, we see the inconsistency:
(top-gdb) p current_inferior_.m_obj.num
$1 = 1
(top-gdb) p current_program_space.num
$2 = 2
When the test tries to connect to a remote target again, GDB maps the
remote inferior to inferior 1, but tries to set the solib_ops of program
space 2, which already has an solib_ops set, causing the internal error.
Fix this by using scoped_restore_current_program_space in addition to
scoped_restore_current_inferior. With this patch applied, we get:
(top-gdb) p current_inferior_.m_obj.num
$1 = 1
(top-gdb) p current_program_space.num
$2 = 1
With this patch, we then hit another internal error, fixed by the
following patch.
Change-Id: If916f581a223d6611f7f23a9cbbf1825d2cdd0ba
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Fix clean_restart <absolute filename> in the test-case in gdb.replay.
Tested on x86_64-linux, with target boards unix, native-gdbserver and
native-extended-gdbserver.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.reverse.
Tested on:
- x86_64-linux, target boards unix and unix/-m32
- aarch64-linux
- ppc64le-linux
- s390x-linux
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.rocm.
Since these test-cases are unsupported for me, do the simple substitution:
...
clean_restart $binfile
->
clean_restart
gdb_load $binfile
...
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.server.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.testsuite.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.threads.
Tested on x86_64-linux.
|
|
Tom de Vries ran the testsuite on msys2-ucrt64 with mount point map:
...
/bin C:/msys64/usr/bin
/c C:
/ C:/msys64
...
and ran into the problem that host_file_normalize didn't translate:
...
/home/user/gdb/build/gdb/testsuite/temp/n/x
...
into:
...
C:/msys64/home/user/gdb/build/gdb/testsuite/temp/n/x
...
The problem is that host_file_normalize_mingw mishandles a
file/directory under the root mount point. A simpler reproducer is
"/foo". If we add that as a test to
gdb.testsuite/mount-point-map.exp, we see:
input: /foo
expected: C:/msys64/foo/
got: /foo
FAIL: gdb.testsuite/mount-point-map.exp: /foo
For a mount point that ends in /, this line in
host_file_normalize_mingw:
} elseif {[string index $filename $mount_len] eq "/"} {
... is always false, because the character at $mount_len is the one
_after_ the slash.
Notice that the "/" mount point is the only one that ends in "/".
This is even if you try to create one explicitly with a trailing /.
On MSYS2:
$ mount c:/foo /foo/
mount: warning - /foo/ does not exist.
$ mount
C:/foo on /foo type ntfs (binary,user)
...
So fix this by special casing the "/" mount point.
And then... while playing with fixing this, I noticed I had done
something strange with this case:
if {[string length $filename] == $mount_len} {
return "$win_filename/"
The intent was to append the slash when the mount is a drive letter,
like 'cygpath -ma' does:
$ cygpath -ma /c
C:/
Other cases do not get a trailing slash:
$ cygpath -ma /c/foo
C:/foo
I think this is because on Windows, every drive letter has a current
directory, and really "C:" means "current directory of drive letter
C:", not "root of C:". Resolving it to "C:/" makes it unambiguous.
However, I mishandled that in a63213cd374d ('MSYS2+MinGW testing: Unix
<-> Windows path conversion'). The original version of that patch
when I posted it to the mailing list only supported drive mounts,
which turned out incorrect, and then I generalized it to work with all
mount points before it was merged. In the process, I inadvertently
made the code append the slash whenever the input filename matches a
mount exactly, any mount.
I also now noticed that TCL's "file normalize" on Linux always removes
the trailing slash, and since host_file_normalize is an abstraction
for it, I think host_file_normalize_mingw should do the same.
Likewise for duplicate slashes, "file normalize" gets rid of them.
Fix all this in host_file_normalize_mingw, and add corresponding tests
to gdb.testsuite/mount-point-map.exp.
I smoke tested this here with a few of the testcases that required
tweaking in the patch that added host_file_normalize, like
gdb.base/source-dir.exp and gdb.base/fullname.exp and they still pass.
Tom ran gdb.testsuite/mount-point-map.exp on both x86_64-linux and
msys2-ucrt64, and it passed in both cases.
Change-Id: I852a8662f0cb8b0ee4e683e9b157618cf6955477
|
|
Proc host_file_normalize is structured like this:
...
proc host_file_normalize {filename} {
if {[ishost *-*-mingw*]} {
...
}
return [file normalize $filename]
...
so a testcase exercising the mingw specific part can only be run on a
mingw host.
Factor out a new proc host_file_normalize_mingw, which can be used on
any host platform.
Add testcase gdb.testsuite/mount-point-map.exp, exercising
host_file_normalize_mingw.
Tested on aarch64-linux, x86-64-linux, msys2-ucrt64, and msys2-mingw.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Ia130de5c12c940852b6367c422d04896863bfc02
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.trace.
Tested on x86_64-linux, with target boards unix, native-gdbserver and
native-extended-gdbserver.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.tui.
Tested on x86_64-linux.
|
|
PR gdb/33069 reports the following behavior:
...
$ gdb -q ls -ex starti -ex "b *1"
Reading symbols from ls...
(No debugging symbols found in ls)
Starting program: /usr/bin/ls
Program stopped.
0x00007ffff7fe4f00 in _start () from /lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x1
(gdb) p (int)strlen("abc")
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1
Command aborted.
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(malloc@plt) will be abandoned.
When the function is done executing, GDB will silently stop.
[1]+ Stopped gdb -q ls -ex starti -ex "b *1"
$ fg
gdb -q ls -ex starti -ex "b *1"
(gdb)
...
with gdb being unresponsive to further input.
PR gdb/33068 reports a similar problem, but using gdbserver, and in that case
gdb doesn't go into the background, but is likewise unresponsive.
This is a regression since commit b1c0ab20809 ("gdb: avoid double stop after
failed breakpoint condition check"), and consequently since release gdb 14.1.
The commit changed this in run_inferior_call:
...
if (current_ui->prompt_state == PROMPT_BLOCKED)
- current_ui->unregister_file_handler ();
- else
- current_ui->register_file_handler ();
+ {
+ if (call_thread->thread_fsm ()->finished_p ())
+ async_disable_stdin ();
+ else
+ async_enable_stdin ();
+ }
...
which means current_ui->register_file_handler is no longer called in the
current_ui->prompt_state == PROMPT_NEEDED case.
Fix this by:
- restoring this behavior, fixing the unresponsiveness, and
- adding target_terminal::ours alongside it, fixing the problem that gdb goes
into the background.
Add a new test-case gdb.base/infcall-failure-2.exp, a regression test for the
unresponsiveness issue. The problem of gdb going into the background did not
reproduce in the test-case.
Tested on x86_64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33068
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33069
|
|
Fix:
$ gdb/check-include-guards.py gdb/arch/aarch64-gcs-linux.h
gdb/arch/aarch64-gcs-linux.h:20: wrong symbol in ifndef
Change-Id: I7586d5c22abe11501f59439df2b4a73bff7d201e
|
|
Change-Id: Ib15ecd6c03fce9d50a0121bbcb910e2fa05cc5f9
|
|
Change-Id: Ifb1dab85891200cadb4b4f59661450a03b0c6abd
|
|
Commit d33a66a31134 ("gdb/solib-svr4: fix wrong namespace id for dynamic
linker") regressed test gdb.base/break-probes.exp with the native-gdbserver
board:
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/break-probes.exp ...
FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited)
FAIL: gdb.base/break-probes.exp: call (int) foo(23)
In the logs, we see this:
Stopped due to shared library event:
Inferior unloaded target:/lib64/ld-linux-x86-64.so.2
Inferior loaded target:/lib64/ld-linux-x86-64.so.2
When we should see this:
Stopped due to shared library event (no libraries added or removed)
In the unexpected output, GDB claims that the inferior unloaded and then
loaded the dynamic linker. This is obviously not true.
Commit d33a66a31134 changed the svr4_same function to consider the debug
bases the solibs come from. Two solibs with the same inferior address but
different debug base (such as the multiple solibs representing the dynamic
linker in all the namespaces) now compare unequal.
That commit also introduced a mechanism to update the debug base of an
existing solib (more precisely, field lm_info_svr4::debug_base) when that
value becomes known. The solib for the dynamic linker view in the default
namespace starts with a debug base of 0, and is then changed to have the
real debug base address later on.
With the particular code path taken when connecting to a remote target,
nothing triggers the update of the debug base of the dynamic linker solib
initially created with a debug base of 0. So when
svr4_solib_ops::current_sos returns a list with an solib for the dynamic
linker with the real debug base value, the core sees this as an unload and
a load.
This happens specifically when debuggin remotely, because,
svr4_solib_ops::current_sos_direct takes the "using_xfer" branch, which
doesn't do any svr4_solib_ops::default_debug_base call. In local, we don't
take that branch, which leads us to a call to default_debug_base.
The way I propose to fix it is to add a call to
svr4_solib_ops::default_debug_base at the beginning of
svr4_solib_ops::current_sos. The rationale to put it there is that if the
core is requesting a fresh list of libraries, and then compare that list
with what it had previously, then we better make sure that the core's list
has received the debug base update, if one is needed.
Change-Id: If09c5a7b3d956e18d4b9514466226267c85f12a6
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Add NEWS entry and new sections to the "Configuration-Specific Information"
and "Standard Target Features" parts of the manual.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
The GCSPR is almost always updated implicitly by the hardware, so the
compiler doesn't generate DWARF unwind information for it. Therefore add
an unwinding function that calculates the value of the GCSPR in the
previous frame based on its value in this frame. Some sanity checking is
done by confirming that the calculated value is within a Guarded Control
Stack memory area.
This function is the same as amd64_linux_dwarf2_prev_ssp, written by
Christina Schimpe to unwind Intel's SSP register.
The gdb.arch/aarch64-gcs-return.exp testcase is lightly adapted from
gdb.arch/amd64-shadow-stack-cmds.exp.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
When doing displaced step on a branch and link instruction with the Guarded
Control Stack enabled, it's necessary to manually push and pop the GCS
entry for the function call since GDB writes a simple branch instruction
rather than a branch and link instruction in the displaced step buffer.
The testcase exercises GCS with displaced stepping by putting the
breakpoint on the bl instruction to force GDB to copy it to the
displaced stepping buffer. In this situation GDB needs to manually
manage the Guarded Control Stack.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
The signal frame can have a GCS context, so teach GDB how to use it.
Also, there's a new SEGV sigcode when the inferior does an illegal
memory access in the Guarded Control Stack, so display a message when
that is the case.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
Add the org.gnu.gdb.aarch64.gcs feature with the GCSPR register, and the
org.gnu.gdb.aarch64.gcs.linux feature with "registers" to represent the
Linux kernel ptrace and prctl knobs that enable and lock specific GCS
functionality.
This code supports GCS only in Linux userspace applications, so the
GCSPR that is exposed is the one at EL0.
Also, support for calling inferior functions is enabled by adding an
implementation for the shadow_stack_push gdbarch method.
If for some reason a target description contains the
org.gnu.gdb.aarch64.gcs feature but not the
org.gnu.gdb.aarch64.gcs.linux feature then GCS support is disabled and
GDB continues the debugging session. Features that need GCS
support (for example, calling inferior functions) will not work and the
inferior will get a segmentation fault signal instead. There's a
testcase for this scenario but it only checks the native debugging case,
even though in practice this problem would only occur in remote
debugging with a broken stub or gdbserver. I tested manually with a
gdbserver hacked to send a broken target description and it worked as
described.
Testcases gdb.arch/aarch64-gcs.exp, gdb.arch/aarch64-gcs-core.exp and
gdb.arch/aarch64-gcs-wrong-tdesc.exp are included to cover the added
functionality.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
objfile::section_iterator looks like a good candidate to be implemented
with filtered_iterator. Following the enhancements to filtered_iterator
in the previous patch, it's pretty straighforward.
I removed the non-const version of objfile::sections, because it didn't
seem useful to have the two methods returning the exact same type and
value. Having just the const version achieves the same thing.
Change-Id: I2f29c2fb3f95605cb816cc1ff8935c10e0496052
Approved-By: Tom Tromey <tom@tromey.com>
|
|
It's currently not possible to use filtered_iterator with a pointer as
the base iterator type. This patch makes it possible. The indended
usage is:
Foo array[12];
Foo *begin = array;
Foo *end = array + ARRAY_SIZE (array);
filtered_iterator<Foo *, FooFilter> (begin, end);
Here are the things that needed changing:
- Give filtered_iterator a constructor where the caller provides
already constructed begin and end iterators. filtered_iterator
currently assumes that default-constructing a BaseIterator will
produce a valid "end" iterator. This is not the case if BaseIterator
is a pointer. The caller needs to pass in the end of the array /
region to iterate on as the end.
- Typedefs of member types like wouldn't work:
typedef typename BaseIterator::value_type value_type;
The compiler would complain that it's not possible to apply `::` to
type `BaseIterator` (aka `Foo *`). Use std::iterator_traits to fix
it [1].
- Similarly, the compiler would complain about the use of
`BaseIterator::operator*` in the return type of
`filtered_iterator::operator*`. Fix this by using `decltype(auto)`
as the return type. This lets the compiler deduce the return type
from the return statement. Unlike `auto`, `decltype(auto)` perfectly
preserves the "cvref-ness" of the deduced return type. If the return
expression yields a `Foo &`, then the function will return a `Foo &`
(which is what we want), whereas it would return a `Foo` if we used
just `auto`.
Improve the filtered_iterator unit tests to run the same tests but with
pointers as iterators. Because the filtered_iterator objects are
initialized differently in the two scenarios, I chose to copy the
existing code and adapt it. It would probably be possible to add a
layer of abstraction to avoid code duplication, but it would end up more
complicated and messy. If we ever add a third scenario, we can revisit
that.
[1] https://en.cppreference.com/w/cpp/iterator/iterator_traits.html
Change-Id: Id962ffbcd960a705a82bc5eb4808b4fe118a2761
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently, if displaced stepping is active and the single stepped instruction
is a call instruction, the return address atop the stack is the address
following the copied instruction. However, to allow normal program execution
it has to be the address following the original instruction. Due to that
reason, the return address is corrected in amd64_displaced_step_fixup and
i386_displaced_step_fixup.
For programs that are shadow-stack enabled we see a control-protection
exception, as the address on the shadow stack does not match the address
atop the stack.
Fix this by correcting the shadow stack top address as well.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Luis Machado <luis.machado@arm.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
