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 b1c0ab2080 ("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.
Commit d33a66a311 ("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 d33a66a311 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>
The XSAVE function set is organized in state components, which are a set of
registers or parts of registers. So-called XSAVE-supported features are
organized using state-component bitmaps, each bit corresponding to a
single state component.
The Intel Software Developer's Manual uses the term xstate_bv for a
state-component bitmap, which is defined as XCR0 | IA32_XSS. The control
register XCR0 only contains a state-component bitmap that specifies user state
components, while IA32_XSS contains a state-component bitmap that specifies
supervisor state components.
Until now, XCR0 is used as input for target description creation in GDB.
However, a following patch will add userspace support for the CET shadow
stack feature by Intel. The CET state is configured in IA32_XSS and consists
of 2 state components:
- State component 11 used for the 2 MSRs controlling user-mode
functionality for CET (CET_U state)
- State component 12 used for the 3 MSRs containing shadow-stack pointers
for privilege levels 0-2 (CET_S state).
Reading the CET shadow stack pointer register on linux requires a separate
ptrace call using NT_X86_SHSTK. To pass the CET shadow stack enablement
state we would like to pass the xstate_bv value instead of xcr0 for target
description creation. To prepare for that, we rename the xcr0 mask
values for target description creation to xstate_bv. However, this
patch doesn't add any functional changes in GDB.
Future states specified in IA32_XSS such as CET will create a combined
xstate_bv_mask including xcr0 register value and its corresponding bit in
the state component bitmap. This combined mask will then be used to create
the target descriptions.
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
On x86 the PTRACE_GETREGSET request is currently only used for the xstate regset.
The size of the xstate regset is initialized to 0 such that it can be reset to
the appropriate size once we know it is supported for the current target
in x86_linux_read_description.
However, this configuration would not just affect the xstate regset but any regset
with PTRACE_GETREGSET request that is added in the future. The new regset would be
misconfigured with the xstate regset size. To avoid this we add an assert for
unsupported regsets and check explicitly for the note type of the register set.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Some register sets can be activated and deactivated by the OS during the runtime of
a process. One example register is the Intel CET shadow stack pointer. This patch
adds a new type of register set to handle such cases. We shouldn't deactivate these
regsets and should not show a warning if the register set is not active but supported
by the kernel. However, it is safe to deactivate them, if they are unsupported by the
kernel. To differentiate those scenarios we can use the errno returned by the ptrace
call.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
I wrote this as a preparatory patch while attempting to make
objfile::section_iterator use filtered_iterator. It turned out not so
easy, so I have put it aside for now. But now I have this patch, so I
thought I'd send it by itself.
Since the `obj_section *` yielded by the iterator can't be nullptr, I
think it makes sense for the iterator to yield references instead.
Just like you would get if you iterated on an std::vector<obj_section>.
Change-Id: I7bbee50ed52599e64c4f3b06bdbbde597feba9aa
When running test-case gdb.dwarf2/dw2-linkage-name-trust.exp with target board
cc-with-gdb-index, I get:
...
(gdb) file dw2-linkage-name-trust^M
Reading symbols from dw2-linkage-name-trust...^M
warning: .gdb_index address table has a range (0x4006ac - 0x4006cc) that \
overlaps with an earlier range, ignoring .gdb_index^M
(gdb) delete breakpoints^M
...
Fix this by compiling with nodebug.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/33315
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33315
When running test-case gdb.dwarf2/dw2-entry-points.exp with target board
cc-with-gdb-index, I get:
...
(gdb) file dw2-entry-points^M
Reading symbols from dw2-entry-points...^M
warning: .gdb_index address table has a range (0x40066c - 0x4006e4) that \
overlaps with an earlier range, ignoring .gdb_index^M
(gdb) delete breakpoints^M
...
Fix this by copying function bar_helper to barso_helper, and using it where
appropriate.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/33315
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33315
For background, see this thread:
https://inbox.sourceware.org/gdb-patches/20250612144607.27507-1-tdevries@suse.de
Tom describes the issue clearly in the above thread, here's what he
said:
Once in a while, when running test-case gdb.base/bp-cmds-continue-ctrl-c.exp,
I run into:
...
Breakpoint 2, foo () at bp-cmds-continue-ctrl-c.c:23^M
23 usleep (100);^M
^CFAIL: $exp: run: stop with control-c (unexpected) (timeout)
FAIL: $exp: run: stop with control-c
...
This is PR python/32167, observed both on x86_64-linux and powerpc64le-linux.
This is not a timeout due to accidental slowness, gdb actually hangs.
The backtrace at the hang is (on cfarm120 running AlmaLinux 9.6):
...
(gdb) bt
#0 0x00007fffbca9dd94 in __lll_lock_wait () from
/lib64/glibc-hwcaps/power10/libc.so.6
#1 0x00007fffbcaa6ddc in pthread_mutex_lock@@GLIBC_2.17 () from
/lib64/glibc-hwcaps/power10/libc.so.6
#2 0x000000001067aee8 in __gthread_mutex_lock ()
at /usr/include/c++/11/ppc64le-redhat-linux/bits/gthr-default.h:749
#3 0x000000001067afc8 in __gthread_recursive_mutex_lock ()
at /usr/include/c++/11/ppc64le-redhat-linux/bits/gthr-default.h:811
#4 0x000000001067b0d4 in std::recursive_mutex::lock ()
at /usr/include/c++/11/mutex:108
#5 0x000000001067b380 in std::lock_guard<std::recursive_mutex>::lock_guard ()
at /usr/include/c++/11/bits/std_mutex.h:229
#6 0x0000000010679d3c in set_quit_flag () at gdb/extension.c:865
#7 0x000000001066b6dc in handle_sigint () at gdb/event-top.c:1264
#8 0x00000000109e3b3c in handler_wrapper () at gdb/posix-hdep.c:70
#9 <signal handler called>
#10 0x00007fffbcaa6d14 in pthread_mutex_lock@@GLIBC_2.17 () from
/lib64/glibc-hwcaps/power10/libc.so.6
#11 0x000000001067aee8 in __gthread_mutex_lock ()
at /usr/include/c++/11/ppc64le-redhat-linux/bits/gthr-default.h:749
#12 0x000000001067afc8 in __gthread_recursive_mutex_lock ()
at /usr/include/c++/11/ppc64le-redhat-linux/bits/gthr-default.h:811
#13 0x000000001067b0d4 in std::recursive_mutex::lock ()
at /usr/include/c++/11/mutex:108
#14 0x000000001067b380 in std::lock_guard<std::recursive_mutex>::lock_guard ()
at /usr/include/c++/11/bits/std_mutex.h:229
#15 0x00000000106799cc in set_active_ext_lang ()
at gdb/extension.c:775
#16 0x0000000010b287ac in gdbpy_enter::gdbpy_enter ()
at gdb/python/python.c:232
#17 0x0000000010a8e3f8 in bpfinishpy_handle_stop ()
at gdb/python/py-finishbreakpoint.c:414
...
What happens here is the following:
- the gdbpy_enter constructor attempts to set the current extension language
to python using set_active_ext_lang
- set_active_ext_lang attempts to lock ext_lang_mutex
- while doing so, it is interrupted by sigint_wrapper (the SIGINT handler),
handling a SIGINT
- sigint_wrapper calls handle_sigint, which calls set_quit_flag, which also
tries to lock ext_lang_mutex
- since std::recursive_mutex::lock is not async-signal-safe, things go wrong,
resulting in a hang.
The hang bisects to commit 8bb8f83467 ("Fix gdb.interrupt race"), which
introduced the lock, making PR python/32167 a regression since gdb 15.1.
Commit 8bb8f83467 fixes PR dap/31263, a race reported by ThreadSanitizer:
...
WARNING: ThreadSanitizer: data race (pid=615372)
Read of size 1 at 0x00000328064c by thread T19:
#0 set_active_ext_lang(extension_language_defn const*) gdb/extension.c:755
#1 scoped_disable_cooperative_sigint_handling::scoped_disable_cooperative_sigint_handling()
gdb/extension.c:697
#2 gdbpy_interrupt gdb/python/python.c:1106
#3 cfunction_vectorcall_NOARGS <null>
Previous write of size 1 at 0x00000328064c by main thread:
#0 scoped_disable_cooperative_sigint_handling::scoped_disable_cooperative_sigint_handling()
gdb/extension.c:704
#1 fetch_inferior_event() gdb/infrun.c:4591
...
Location is global 'cooperative_sigint_handling_disabled' of size 1 at 0x00000328064c
...
SUMMARY: ThreadSanitizer: data race gdb/extension.c:755 in \
set_active_ext_lang(extension_language_defn const*)
...
The problem here is that gdb.interrupt is called from a worker thread, and its
implementation, gdbpy_interrupt races with the main thread on some variable.
The fix presented here is based on the fix that Tom proposed, but
fills in the missing Mingw support.
The problem is basically split into two: hosts that support unix like
signals, and Mingw, which doesn't support signals.
For signal supporting hosts, I've adopted the approach that Tom
suggests, gdbpy_interrupt uses kill() to send SIGINT to the GDB
process. This is then handled in the main thread as if the user had
pressed Ctrl+C. For these hosts no locking is required, so the
existing lock is removed. However, everywhere the lock currently
exists I've added an assert:
gdb_assert (is_main_thread ());
If this assert ever triggers then we're setting or reading the quit
flag on a worker thread, this will be a problem without the mutex.
For Mingw, the current mutex is retained. This is fine as there are
no signals, so no chance of the mutex acquisition being interrupted by
a signal, and so, deadlock shouldn't be an issue.
To manage the complexity of when we need an assert, and when we need
the mutex, I've created 'struct ext_lang_guard', which can be used as
a RAII object. This object either performs the assertion check, or
acquires the mutex, depending on the host.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32167
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Approved-By: Tom Tromey <tom@tromey.com>
Add --got-contents option to readelf, inspired by the -G option on Solaris,
to display contents of GOT sections:
$ readelf --got-contents libfoo.so
Global Offset Table '.got' contains 1 entry:
Index: Address Reloc Sym. Name + Addend/Value
0: 000000200340 R_X86_64_GLOB_DAT foo + 0
Global Offset Table '.got.plt' contains 4 entries:
Index: Address Reloc Sym. Name + Addend/Value
0: 000000200348 200220
1: 000000200350 0
2: 000000200358 0
3: 000000200360 R_X86_64_JUMP_SLO bar + 0
When --got-content options are used:
1. Allocate an array, all_relocations, to hold all relocations.
2. Update dump_relr_relocations and dump_relocations to scan relocations
and cache them in all_relocations. Don't display relocations if not
requested.
3. Add process_got_section_contents to display contents of GOT sections
by matching the GOT entry offset against the cached relocations.
4. Update process_mips_specific to only display the GOT related contents
for --got-contents.
binutils/
* NEWS: Mention "readelf --got-contents".
* readelf.c (do_got_section_contents): New.
(elf_relocation): Likewise.
(all_relocations_root): Likewise.
(all_relocations): Likewise.
(all_relocations_count): Likewise.
(update_all_relocations): Likewise.
(dump_relr_relocations): Add a bool argument to indicate if
relocations should be displayed. Populate all_relocations if
do_got_section_contents is true.
(dump_relocations): Likewise.
(long_option_values): Add OPTION_GOT_CONTENTS.
(options): Add --got-contents.
(usage): Show --got-contents.
(parse_args): Support --got-contents.
(display_relocations): Add a bool argument, dump_reloc, to
indicate if relocations should be displayed. Call
update_all_relocations. Pass dump_reloc to dump_relr_relocations
and dump_relocations.
(process_relocs): Check do_got_section_contents. Handle
do_got_section_contents for dynamic relocations.
(process_section_contents): Pass true to display_relocations.
(process_mips_specific): Add a bool argument, dump_got, to
indicate if only the GOT related contents should be displayed.
Display all MIPS specific information if dump_got is false.
(elf_relocation_cmp): New.
(display_elf_relocation_at): Likewise.
(process_got_section_contents): Likewise.
(process_object): Call process_got_section_contents.
* doc/binutils.texi: Document --got-contents.
ld/
* testsuite/ld-i386/binutils.exp: New file.
* testsuite/ld-i386/got-1.s: Likewise.
* testsuite/ld-i386/libgot-1a.rd: Likewise.
* testsuite/ld-i386/libgot-1b.rd: Likewise.
* testsuite/ld-i386/libgot-1c.rd: Likewise.
* testsuite/ld-i386/libgot-1d.rd: Likewise.
* testsuite/ld-x86-64/binutils.exp: Likewise.
* testsuite/ld-x86-64/got-1.s: Likewise.
* testsuite/ld-x86-64/libgot-1a-x32.rd: Likewise.
* testsuite/ld-x86-64/libgot-1a.rd: Likewise.
* testsuite/ld-x86-64/libgot-1b-x32.rd: Likewise.
* testsuite/ld-x86-64/libgot-1b.rd: Likewise.
* testsuite/ld-x86-64/libgot-1c-x32.rd: Likewise.
* testsuite/ld-x86-64/libgot-1c.rd: Likewise.
* testsuite/ld-x86-64/libgot-1d-x32.rd: Likewise.
* testsuite/ld-x86-64/libgot-1d.rd: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
The opcode D6 has been officially reserved as a single-byte permanent
undefined (#UD) opcode in 64-bit mode with the mnemonic UDB. This is
already the behavior of all known 64-bit implementations; this is thus
merely an official statement of forward compatibility and the
assignment of a mnemonic.
This will be documented in the next version of the Intel Software
Developer's Manual; in the meantime I DO speak officially for Intel on
this issue.
The x86 Advisory Council has ratified this decision, and so it is
expected to be honored across vendors, but I obviously cannot make any
official statement on any other vendor's behalf.
I am covered by the Intel-FSF copyright assignment for binutils.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
I think it's uninteresting to step into gdb::ref_ptr::get, so add a skip
entry for it. I am adding just one to get the party started, but there
are certainly more like this that we could skip.
Change-Id: Ib074535c96a62137de63bbe58ff168a1e913688f
Approved-By: Tom Tromey <tom@tromey.com>
I don't know if this is true on all platforms, but from what I can see
on Linux, the dump commands don't output anything. Use
gdb_test_no_output, which should be a bit more robust than checking for
some specific error patterns.
Change-Id: Idc82298c4752ba7808659dfea2f8324c8a97052d
Approved-By: Tom Tromey <tom@tromey.com>
The manual claims that the -list-features and -list-target-features MI
commands return their result in a field named "result". The field is
actually named "features", and always has been since the introduction of
these commands in 084344d and c6ebd6c. See mi_cmd_list_features and
mi_cmd_list_target_features in gdb/mi/mi-main.c.
Approved-By: Tom Tromey <tom@tromey.com>
Even though the core_find proc will log a warning, it's better to log
"untested" and then terminate the test. This will help to avoid
silently skipped tests, when running the testsuite. Most of the tests
already do that. This patch adds the missing ones.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
"pre-commit autoupdate" pointed out that a newer version of flake8 has
been released. This patch applies the update. No code changes were
needed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In this commit:
commit dbd05b9edc
Date: Wed Aug 20 10:45:09 2025 +0100
gdb/python: check return value of PyObject_New in all cases
I missed a call to PyObject_New in python/py-disasm.c, which this
commit addresses.
Unlike the previous commit, the call to PyObject_New in py-disasm.c is
contained within the scoped_disasm_info_object class, which makes it
harder to check for NULL and return.
So in this commit I've rewritten the scoped_disasm_info_object class,
moving the call to PyObject_New out into gdbpy_print_insn, which is
the only place that scoped_disasm_info_object was being used.
As scoped_disasm_info_object is no longer responsible for creating the
underlying Python object, I figured that I might as well move the
initialisation of that object out of scoped_disasm_info_object too.
With that done, the scoped_disasm_info_object now has just one task,
invalidating the existing disasm_info_object at the end of the scope.
So I renamed scoped_disasm_info_object to
scoped_invalidate_disasm_info, which reflects its only task.
I made a couple of other small adjustments that were requested during
review, these are both in the same code area: updating
disasm_info_fill to take an object reference rather than a pointer,
and removing the local variable insn_disas_obj from gdbpy_print_insn,
and inline its value at the one place it was used.
There should be no user visible changes after this commit. Except for
the PyObject_New call, which now has proper error checking. But in
the working case, nothing should have changed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
While looking at test-case gdb.tui/tui-missing-src.exp I noticed that
gdb_compile is used to compile multiple sources:
...
if { [gdb_compile "${srcfiles}" "${binfile}" \
executable {debug additional_flags=-O0}] != "" } {
...
meaning there are no separate compile and link steps, as is required for
fission [1].
Fix this by using build_executable instead.
Tested on aarch64-linux.
[1] https://gcc.gnu.org/wiki/DebugFission
During testing of bare-metal applications on QEMU for RISC-V, it was discovered
that the instructions wfi, sfence.vma, sret, and mret were not supported. This
patch introduces support for these instructions. Additionally, it wraps
fetch_instruction function in a try-catch block to gracefully handle errors
that may occur when attempting to read invalid address.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
The Linaro CI reported a regression in test-case
gdb.dwarf2/macro-source-path-clang14-dw4.exp due to recent commit 81e5a23c7b
("[gdb/testsuite] Fix require dwarf2_support check in some test-cases").
The problem is that the "require dwarf2_support" in its new location doesn't
work because proc dwarf2_support is not defined.
I didn't notice this because I tested all gdb.dwarf2 test-cases together, and
a different test-case had already imported the proc.
Fix this by moving load_lib dwarf.exp earlier.
Tested on x86_64-linux.
1. Update dump_relr_relocations to take relr_size, relr_entsize and
relr_offset, instead of a pointer to Elf_Internal_Shdr, as function
arguments.
2. Update process_relocs to call dump_relr_relocations if relocation
type is reltype_relr.
binutils/
PR binutils/33328
* readelf.c (dump_relr_relocations): Replace a pointer to
Elf_Internal_Shdr argument with relr_size, relr_entsize and
relr_offset.
(display_relocations): Update the dump_relr_relocations call.
(process_relocs): Call dump_relr_relocations if relocation type
is reltype_relr.
ld/
PR binutils/33328
* testsuite/ld-i386/dt-relr-1c.d: New file.
* testsuite/ld-i386/dt-relr-1d.d: Likewise.
* testsuite/ld-x86-64/dt-relr-1c-x32.d: Likewise.
* testsuite/ld-x86-64/dt-relr-1c.d: Likewise.
* testsuite/ld-x86-64/dt-relr-1d-x32.d: Likewise.
* testsuite/ld-x86-64/dt-relr-1d.d: Likewise.
* testsuite/ld-i386/i386.exp: Run PR binutils/33328 tests.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
