| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
"the weird alignment hackery" comment doesn't help anyone understand
the code. Explain what is going on. Replace the zero length
obstack_alloc with obstack_finish, which by inspection of obstack.h is
all the zero length alloc does.
* frags.c (frag_alloc): Comment. Replace zero length
obstack_alloc with obstack_finish.
(frag_new): Remove unnecessary obstack_finish.
* write.c (compress_frag, compress_debug): Likewise.
|
|
For better packing of struct frag.
* frags.h (struct frag <fr_type>): Use ENUM_BITFIELD.
|
|
These weren't wrong, but should use the BUNDLE_SIZE macros, in case
they ever change.
* config/tc-tilegx.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use
TILEGX_BUNDLE_SIZE_IN_BYTES.
* config/tc-tilepro.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use
TILEPRO_BUNDLE_SIZE_IN_BYTES.
|
|
Commit 7ca6020a4e52 "tidy target HANDLE_ALIGN" didn't account for
the "fix" amount emitted by visium_handle_align. This didn't show up
as a problem due to frag alignment hiding the error, until I started
messing with struct frag.
* config/tc-visium.h (MAX_MEM_FOR_RS_ALIGN_CODE): Correct.
|
|
* csky-dis.c (parse_csky_dis_options): Free copy of options.
|
|
|
|
opcodes/
* ppc-opc.c: (VXSEL5, VXSEL4, VXSEL3, VXSEL2, UIMM1): New defines.
(powerpc_opcodes): <vucmprhn, vucmprln, vucmprhb, vucmprlb,
vucmprhh, vucmprlh, vupkhsntob, vupklsntob, vupkint4tobf16,
vupkint8tobf16, vupkint4tofp32, vupkint8tofp32>: New instructions.
gas/
* gas/testsuite/gas/ppc/future.s: Add new testcases.
* gas/testsuite/gas/ppc/future.d: Likewise.
|
|
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
...
|
|
Update "readelf --got-contents" to report if no GOT section found.
* readelf.c (process_got_section_contents): Report if no GOT
section found.
* testsuite/binutils-all/readelf-got.d: New file.
* testsuite/binutils-all/readelf.exp: Run readelf-got.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.server.
Tested on x86_64-linux.
|
|
PR gas/15273
The apparent intent of the original code added in
https://sourceware.org/pipermail/binutils/2012-August/078044.html was
to emit an error message if the instruction was obsolete and only to
emit a deprecation warning if an error hadn't already been emitted.
However, when the insn has not yet been obsoleted, the code would
generate a warning with a (null) message body if the selected CPU was
'any'.
The previous fix for this bug was to remove the support for the
obsoletion message entirely, which was probably the wrong approach. A
better fix is to only call check_obsolete if obs_msg is non-null; we
can use this as a proxy for the instruction not being obsolete on any
architecture.
While we are here, fix an incorrect capitalization in the deprecation
message ('This' to 'this').
|
|
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.
|
|
The tests mentioned in PR33348 needs different care.
For FRED tests, we could simply remove them since there are
no operands and the tests are the same as AT&T Syntax.
For MOVRS tests, we allowed suffixes for AT&T suffixes although
we could tell the difference according to register operand to
align with legacy mov. Thus, the suffixes tests are needed for
AT&T Syntax while not needed for Intel Syntax. Adjust them
accordingly.
gas/ChangeLog:
PR ld/33348
* testsuite/gas/i386/x86-64-movrs-suffix.d: Describe the
test with more precise.
* testsuite/gas/i386/x86-64-movrs-suffix.s: Remove Intel
Syntax part.
* testsuite/gas/i386/x86-64.exp: Add MOVRS suffix tests.
* testsuite/gas/i386/x86-64-fred-intel.d: Removed.
* testsuite/gas/i386/x86-64-movrs-suffix-intel.d: Ditto.
|
|
When parsing FDEs in `.eh_frame` using `objdump -Wf`, it is necessary to
resolve `BFD_RELOC_LARCH_32_PCREL` to determine the address ranges of
the FDEs. Set the `pcrel_offset` field of `BFD_RELOC_LARCH_32_PCREL` to
help `objdump` correctly compute the address ranges of the FDEs.
Apply the same modification to BFD_RELOC_LARCH_64_PCREL.
|
|
|
|
Only the long option --gen-idx was recognized to generate aarch64-tbl-2.h
|
|
The cris ld testsuite uses readelf -a. The extra output now means
that a number of tests fail. Fix that by not using -a, but rather
the options corresponding to output checked in the dump files.
* testsuite/ld-cris/tls-local-63.d: Replace -a option with -r -s.
Remove now unnecessary #... and superfluous unwind message.
* testsuite/ld-cris/tls-local-64.d: Likewise.
* testsuite/ld-cris/tls-und-38.d: Likewise.
* testsuite/ld-cris/tls-und-42.d: Likewise.
* testsuite/ld-cris/tls-und-46.d: Likewise.
* testsuite/ld-cris/tls-und-50.d: Likewise.
* testsuite/ld-cris/weakref3.d: Replace -a with -S -r -s, and
remove unwind message.
* testsuite/ld-cris/weakref4.d: Likewise.
|
|
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
|
|
|
|
While looking at the Solaris versions of the program header p_vaddr and
p_align values of the text and data segments, I noticed that the
Solaris/sparcv9 version of TEXT_START_ADDR is defined in a shared file.
Since there's a Solaris/sparcv9 specific file now
(ld/emulparams/elf64_sparc_sol2.sh), it seems cleaner to move it there.
Tested on {sparcv9,sparc}-sun-solaris2.11 and
{sparc64,sparc}-unknown-linux-gnu.
2025-07-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
ld:
* emulparams/elf64_sparc.sh (TEXT_START_ADDR): Move ...
* emulparams/elf64_sparc_sol2.sh (TEXT_START_ADDR): ... here.
|
|
This is a copy-pasto.
Change-Id: I947772f6a694b33e393762dbf2931ebe2031c1c5
|
|
|
|
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>
|
|
This patch is required by the following commit
"gdb: Enable displaced stepping with shadow stack on amd64 linux."
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This patch enables inferior calls to support Intel's Control-Flow
Enforcement Technology (CET), which provides the shadow stack feature
for the x86 architecture.
Following the restriction of the linux kernel, enable inferior calls
for amd64 only.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Inferior calls in GDB reset the current PC to the beginning of the function
that is called. As no call instruction is executed the new return address
needs to be pushed to the shadow stack and the shadow stack pointer needs
to be updated.
This commit adds a new gdbarch method to push an address on the shadow
stack. The method is used to adapt the function 'call_function_by_hand_dummy'
for inferior call shadow stack support.
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Unwind the $pl3_ssp register.
We now have an updated value for the shadow stack pointer when
moving up or down the frame level. Note that $pl3_ssp can
become unavailable when moving to a frame before the shadow
stack enablement. In the example below, shadow stack is enabled
in the function 'call1'. Thus, when moving to a frame level above
the function, $pl3_ssp will become unavaiable.
Following the restriction of the linux kernel, implement the unwinding
for amd64 linux only.
Before this patch:
~~~
Breakpoint 1, call2 (j=3) at sample.c:44
44 return 42;
(gdb) p $pl3_ssp
$1 = (void *) 0x7ffff79ffff8
(gdb) up
55 call2 (3);
(gdb) p $pl3_ssp
$2 = (void *) 0x7ffff79ffff8
(gdb) up
68 call1 (43);
(gdb) p $pl3_ssp
$3 = (void *) 0x7ffff79ffff8
~~~
After this patch:
~~~
Breakpoint 1, call2 (j=3) at sample.c:44
44 return 42;
(gdb) p $pl3_ssp
$1 = (void *) 0x7ffff79ffff8
(gdb) up
55 call2 (3);
(gdb) p $pl3_ssp
$2 = (void *) 0x7ffff7a00000
(gdb) up
68 call1 (43i);
(gdb) p $pl3_ssp
$3 = <unavailable>
~~~
As we now have an updated value for each selected frame, the
return command is now enabled for shadow stack enabled programs, too.
We therefore add a test for the return command and shadow stack support,
and for an updated shadow stack pointer after a frame level change.
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Intel's Control-Flow Enforcement Technology (CET) provides the shadow
stack feature for the x86 architecture.
This commit adds support to write and read the shadow-stack node in
corefiles. This helps debugging return address violations post-mortem.
The format is synced with the linux kernel commit "x86: Add PTRACE
interface for shadow stack". As the linux kernel restricts shadow
stack support to 64-bit, apply the fix for amd64 only.
Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
---
The code and testcase are lightly adapted from:
[PATCH v3 5/9] GDB, gdbserver: aarch64-linux: Initial Guarded Control Stack support
https://sourceware.org/pipermail/gdb-patches/2025-June/218892.html
|
|
This patch adds the user mode register PL3_SSP which is part of the
Intel(R) Control-Flow Enforcement Technology (CET) feature for support
of shadow stack.
For now, only native and remote debugging support for shadow stack
userspace on amd64 linux are covered by this patch including 64 bit and
x32 support. 32 bit support is not covered due to missing Linux kernel
support.
This patch requires fixing the test gdb.base/inline-frame-cycle-unwind
which is failing in case the shadow stack pointer is unavailable.
Such a state is possible if shadow stack is disabled for the current thread
but supported by HW.
This test uses the Python unwinder inline-frame-cycle-unwind.py which fakes
the cyclic stack cycle by reading the pending frame's registers and adding
them to the unwinder:
~~~
for reg in pending_frame.architecture().registers("general"):
val = pending_frame.read_register(reg)
unwinder.add_saved_register(reg, val)
return unwinder
~~~
However, in case the python unwinder is used we add a register (pl3_ssp) that is
unavailable. This leads to a NOT_AVAILABLE_ERROR caught in
gdb/frame-unwind.c:frame_unwind_try_unwinder and it is continued with standard
unwinders. This destroys the faked cyclic behavior and the stack is
further unwinded after frame 5.
In the working scenario an error should be triggered:
~~~
bt
0 inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:49^M
1 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M
2 0x000055555555516e in inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:45^M
3 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M
4 0x000055555555516e in inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:45^M
5 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5
~~~
To fix the Python unwinder, we simply skip the unavailable registers.
Also it makes the test gdb.dap/scopes.exp fail. The shadow stack feature is
disabled by default, so the pl3_ssp register which is added with my CET
shadow stack series will be shown as unavailable and we see a TCL error:
~~
>>> {"seq": 12, "type": "request", "command": "variables", "arguments": {"variablesReference": 2, "count": 85}}
Content-Length: 129^M
^M
{"request_seq": 12, "type": "response", "command": "variables", "success": false, "message": "value is not available", "seq": 25}FAIL: gdb.dap/scopes.exp: fetch all registers success
ERROR: tcl error sourcing /tmp/gdb/testsuite/gdb.dap/scopes.exp.
ERROR: tcl error code TCL LOOKUP DICT body
ERROR: key "body" not known in dictionary
while executing
"dict get $val body variables"
(file "/tmp/gdb/testsuite/gdb.dap/scopes.exp" line 152)
invoked from within
"source /tmp/gdb/testsuite/gdb.dap/scopes.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /tmp/gdb/testsuite/gdb.dap/scopes.exp"
invoked from within
"catch "uplevel #0 source $test_file_name" msg"
UNRESOLVED: gdb.dap/scopes.exp: testcase '/tmp/gdb/testsuite/gdb.dap/scopes.exp' aborted due to Tcl error
~~
I am fixing this by enabling the test for CET shadow stack, in case we
detect that the HW supports it:
~~~
# If x86 shadow stack is supported we need to configure GLIBC_TUNABLES
# such that the feature is enabled and the register pl3_ssp is
# available. Otherwise the reqeust to fetch all registers will fail
# with "message": "value is not available".
if { [allow_ssp_tests] } {
append_environment GLIBC_TUNABLES "glibc.cpu.hwcaps" "SHSTK"
}
~~~
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
