Rainer Orth [Sun, 31 Aug 2025 10:14:36 +0000 (12:14 +0200)]
ld: Move Solaris/sparcv9 TEXT_START_ADDR to elf64_sparc_sol2.sh
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.
Simon Marchi [Fri, 29 Aug 2025 20:05:27 +0000 (16:05 -0400)]
gdb/solib-svr4: update default debug base in svr4_solib_ops::current_sos
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>
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>
GDB: aarch64-linux: Implement GCS support in displaced stepping
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>
GDB, gdbserver: aarch64-linux: Initial Guarded Control Stack support
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>
Simon Marchi [Thu, 28 Aug 2025 15:10:51 +0000 (11:10 -0400)]
gdb/objfiles: use filtered_iterator as objfile::section_iterator
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>
- 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.
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.
gdb: Enable displaced stepping with shadow stack on amd64 linux.
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>
gdb: Implement amd64 linux shadow stack support for inferior calls.
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>
gdb, gdbarch: Enable inferior calls for shadow stack support.
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>
gdb: Handle shadow stack pointer register unwinding for amd64 linux.
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>
gdb: amd64 linux coredump support with shadow stack.
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
gdb, gdbserver: Add support of Intel shadow stack pointer register.
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>
gdb, gdbserver: Use xstate_bv for target description creation on x86.
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>
gdbserver: Add assert in x86_linux_read_description.
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>
gdbserver: Add optional runtime register set type.
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>
We need it for testing coredump files, too. So include it in this patch series.
Abridged-by: Christina Schimpe <christina.schimpe@intel.com> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
---
This is the patch mentioned above:
Simon Marchi [Wed, 27 Aug 2025 14:38:13 +0000 (10:38 -0400)]
gdb/objfiles: make objfile::sections yield references
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>.
Tom de Vries [Fri, 29 Aug 2025 15:31:58 +0000 (17:31 +0200)]
[gdb/testsuite] Fix overlapping CUs in gdb.dwarf2/dw2-linkage-name-trust.exp
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
Tom de Vries [Fri, 29 Aug 2025 15:31:58 +0000 (17:31 +0200)]
[gdb/testsuite] Fix overlapping CUs in gdb.dwarf2/dw2-entry-points.exp
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
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 8bb8f834672 ("Fix gdb.interrupt race"), which
introduced the lock, making PR python/32167 a regression since gdb 15.1.
Commit 8bb8f834672 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>
H.J. Lu [Thu, 28 Aug 2025 21:15:18 +0000 (14:15 -0700)]
readelf: Add --got-contents option
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.
x86: add "udb" opcode (permanent official #UD in 64-bit mode)
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>
Simon Marchi [Mon, 25 Aug 2025 17:02:12 +0000 (13:02 -0400)]
gdb/gdb-gdb.gdb.in: skip gdb::ref_ptr<.*>::get
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>
Simon Marchi [Mon, 25 Aug 2025 15:44:22 +0000 (11:44 -0400)]
gdb/testsuite: use gdb_test_no_output when dumping in gdb.base/dump.exp
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>
Fix documentation of -list-[target-]features results
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.
testsuite: add untested in case OS corefile is not found
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>
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>
Tom de Vries [Thu, 28 Aug 2025 09:36:29 +0000 (11:36 +0200)]
[gdb/testsuite] Use build_executable in gdb.tui/tui-missing-src.exp
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].
gdb/record: Support wfi, sfence.vma, sret and mret instructions in risc-v
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>
Tom de Vries [Thu, 28 Aug 2025 09:24:42 +0000 (11:24 +0200)]
[gdb/testsuite] Fix require dwarf2_support check in some test-cases, some more
The Linaro CI reported a regression in test-case
gdb.dwarf2/macro-source-path-clang14-dw4.exp due to recent commit 81e5a23c7b8
("[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.
H.J. Lu [Wed, 27 Aug 2025 20:17:07 +0000 (13:17 -0700)]
readelf: Update "-D -r" to dump DT_RELR
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.
Simon Marchi [Wed, 6 Aug 2025 19:28:19 +0000 (15:28 -0400)]
gdb/testsuite: get real executable in gdb.gdb/index-file.exp
Similar to a previous patch, if the gdb executable is in fact a libtool
wrapper, we need to get the path to the real executable to load it in
the top-level gdb.
With this change, the test runs on Cygwin, although I do see two
failures:
FAIL: gdb.gdb/index-file.exp: debug_names files are identical
FAIL: gdb.gdb/index-file.exp: debug_str files are identical
Change-Id: Ie06d1ece67e61530e5b664e65b5ef0edccaf6afa Reviewed-By: Keith Seitz <keiths@redhat.com>
Simon Marchi [Wed, 6 Aug 2025 19:28:18 +0000 (15:28 -0400)]
gdb/testsuite: turn thread events off in selftests
When running gdb.gdb/selftest.exp on Cygwin, the test eventually times
out on this command:
(gdb) PASS: gdb.gdb/selftest.exp: printed version as pointer
continue
Continuing.
[New Thread 4804.0x1728]
[New Thread 4804.0x2f24]
[New Thread 4804.0x934]
[New Thread 4804.0x23a8]
[New Thread 4804.0x2cf4]
[New Thread 4804.0x1408]
[New Thread 4804.0x2c90]
[New Thread 4804.0xc58]
[New Thread 4804.0x1d40]
[New Thread 4804.0x1824]
GNU gdb (GDB) 17.0.50.20250530-git
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) [New Thread 4804.0x2c64]
[New Thread 4804.0x23c4]
[New Thread 4804.0x2814]
[Thread 4804.0x1200 exited with code 0]
[Thread 4804.0x293c exited with code 0]
[Thread 4804.0x2c9c exited with code 0]
FAIL: gdb.gdb/selftest.exp: xgdb is at prompt (timeout)
The problem is the new thread notification, and the fact that the test
expects the prompt to be the last thing in the buffer. To avoid the
thread events interfering with the test, disable them, they are not
useful here.
With this patch, gdb.gdb/selftest.exp mostly runs fine on Cygwin, the
only remaining problem appears to be:
(gdb) PASS: gdb.gdb/selftest.exp: send ^C to child process
signal SIGINT
Continuing with signal SIGINT.
PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process, top GDB message
FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process, bottom GDB message (timeout)
Change-Id: I0b1df0503c1961c042c8de559b4d223c5d3cb95c Reviewed-By: Keith Seitz <keiths@redhat.com>
Simon Marchi [Wed, 27 Aug 2025 19:55:45 +0000 (15:55 -0400)]
gdb/testsuite: use libtool to launch selftests
When building GDB on Cygwin, gdb/gdb.exe is a libtool wrapper (which
happens to be a PE executable). The real executable is at
gdb/.libs/gdb.exe. The "does gdb have debug info test" that
_selftest_setup does is bogus, because it loads the libtool wrapper
(which doesn't have debug info), doesn't see any debug info, and thus
the test is skipped.
The "correct" way to deal with libtool wrappers is to run the shell
command you want to run under `libtool --mode=execute`. That will
replace any path resembling to a libtool wrapper with the real
executable path. But it will also add to the environment the library
paths necessary for this executable to find the libraries it needs.
Therefore, modify the `do_self_tests` proc to:
- run the top-level GDB commands under `libtool --mode=execute`
- pass the path to the inferior GDB on the command-line of the
top-level, so that it gets replaced with the real executable's path
However, the "file" command was previously used to detect the presence
of debug info in the GDB executable. It's not easy to implement this
check when loading the executable directly on the command line. So, add
a separate proc, _selftest_check_executable_debug_info, that spawns a
temporary GDB and does the debug info check through the file command.
This proc uses libtool to obtain the path to the real executable.
When building, we use the bundled libtool.m4 at the top of the tree.
This means that the libtool system package, and therefore the libtool
binary, might not be available. Check for the presence of the libtool
binary first, and only do the conversion if it is found. If it is not
found, the test should still work on platforms that don't require the
conversion.
With this commit, the test runs on Cygwin, even though there are
failures later.
Change-Id: Ie7b712cdc84671a5a017655a7e41687ff23f906c Reviewed-By: Keith Seitz <keiths@redhat.com>
This is done so that the installation is relocatable (the whole ROCm
directory can be copied around) and things still work. For instance,
the rocgdb executable needs to be able to find the libraries it
needs, such as `librocm-dbgapi.so.0`. The relative runpath allows
that.
2. For testing, we run the testsuite against the gdb executable
installed from one of those packages. It is possible to ./configure
the testsuite directory on its own, and then do:
$ make check RUNTESTFLAGS="GDB=/opt/rocm/bin/rocgdb"
3. The selftests (such as gdb.gdb/selftest.exp) copy the GDB under test
to the standard output directory, before trying to debug it.
The problem is that the gdb executable under test that has been copied
can't find the libraries it needs.
With this patch, I propose that we don't copy the gdb executable, but
debug it in place instead. The comment removed in this patch says "in
case this OS doesn't like to edit its own text space", and has been
there since forever in some form. But it's not clear if there is a host
OS (where we intend to run this test) that needs this nowadays. I would
bet that there isn't. If there is in fact a GDB host OS (where we
intend to run this test) that needs it, we can reinstate the copying,
but as an opt-in operation.
Another situation where this change helps is on Windows, where
gdb/gdb.exe is a libtool wrapper (the real executable is at
gdb/.libs/gdb.exe). Copying gdb/gdb.exe doesn't accomplish anything
useful. The next patch does further changes to account for the libtool
wrapper case.
I tested on Linux and Cygwin, more testing would be welcome.
Change-Id: Id4148517d4fc4ecdd49f099c12003e3d16c6a93d Reviewed-By: Keith Seitz <keiths@redhat.com>
Tom Tromey [Wed, 27 Aug 2025 19:29:22 +0000 (13:29 -0600)]
Fix formatting of gdbarch_components.py
pre-commit pointed out that gdbarch_components.py had a minor
formatting issue, according to the official version of 'black'. This
patch corrects the oversight.
Alan Modra [Wed, 27 Aug 2025 08:06:57 +0000 (17:36 +0930)]
objcopy "strip without global symbol" test
This binutils test fails with -fsanitize. NOSANITIZE_CFLAGS isn't
available in the binutils testsuite, and importing it over from ld
requires a huge amount of tcl code to be moved. So I chose to simply
add -fno-sanitize=all if -fsanitize= is seem in CFLAGS.
* testsuite/binutils-all/objcopy.exp
(objcopy_test_without_global_symbol): Add -fno-sanitize=all to
flags if -fsanitize= is found in CFLAGS_FOR_TARGET. Tidy use
of objfile.
* testsuite/binutils-all/tek2.obj: Change to a 3 byte data file
that triggers tekhex error fixed by commit bf0f85df1254.
* testsuite/binutils-all/ar.exp: Adjust to suit.
* testsuite/binutils-all/objcopy.exp (objcopy_tek2bin): New proc.
Alan Modra [Tue, 26 Aug 2025 09:49:44 +0000 (19:19 +0930)]
objcopy "Unable to recognise the format of the input file"
This bogus error comes up when trying something like
objcopy -O binary .../binutils/testsuite/binutils-all/tek2.obj xxx
This is an annoying message, as HJ said in
https://sourceware.org/pipermail/binutils/2002-August/021354.html
and removed it for some cases, eg. I can make it go away by specifying
-I tekhex. The message is also untrue, as objcopy does in fact know
the format of the input file.
I think the message should be limited to ELF input files that are
being handled by the elf64-little, elf64-big, elf32-little or
elf32-big targets, due to libbfd being compiled with limited target
support. I'm also changing the message a litle.
* objcopy.c (copy_object): Change "Unable to recognise format"
message to "Unable to recognise architecture" and only report
this error for ELF objects lacking their proper target support.
* testsuite/binutils-all/x86-64/x86-64.exp: Update to suit.
After commit 5e83077d552e we no longer choose a "plugin" target in
objcopy so ibfd->target_defaults can again be used to test whether the
user supplied a target.
PR 33230
* objcopy.c (copy_file): Revert change adding a target_defaulted
variable and passing down to..
(copy_archive, copy_object): ..here. Remove target_defaulted
parameter. Use ibfd->target_defaulted.
gdb: allow gdb.Color to work correctly with pagination
Which added gdb.python/py-color-pagination.exp. Bug PR gdb/33321 was
then created as the test was failing on some hosts. Turns out, this
is same expect bug.
The fix presented here is the same as for e579b537353cd91cb8, avoid
using optional regexp substrings at the start of a regexp, and instead
use two separate regexp patterns. With this change in place, the test
now passes on all hosts.
There's no change in what is being tested after this commit.
Tom de Vries [Wed, 27 Aug 2025 08:49:19 +0000 (10:49 +0200)]
[gdb/testsuite] Fix gdb.server/non-existing-program.exp on msys2-ucrt64
On msys2-ucrt64, with test-case gdb.server/non-existing-program.exp I get:
...
(gdb) quit^M
gdb_caching_proc allow_xml_test caused gdb_exit to be called
gdb_caching_proc allow_xml_test marked as called
gdb_caching_proc get_mount_point_map marked as called
builtin_spawn gdbserver stdio non-existing-program^M
Error creating process "non-existing-program " (error 2): \
The system cannot find the file specified.^M^M
Exiting^M^M
FAIL: gdb.server/non-existing-program.exp: gdbserver exits cleanly
...
This happens because this regexp fails to match:
...
# This is what we get on Windows.
-re "Error creating process\r\n\r\nExiting\r\n" {
...
put R_386_TLS_DESC and R_X86_64_TLSDESC relocation in .rela.tls/.rel.tls
section, instead of .rel.plt/.rela.plt section.
Tested with glibc/i686 and glibc/x86-64 compiled with -mtls-dialect=gnu2
as well as GCC 16 configured with --with-tls=gnu2.
bfd/
PR ld/28387
* elf32-i386.c (elf_i386_relocate_section): Put R_386_TLS_DESC
in rel_tls_desc instead of elf.srelplt.
* elf64-x86-64.c (elf_x86_64_relocate_section): Put
R_X86_64_TLSDESC in rel_tls_desc instead of elf.srelplt.
* elfxx-x86.c (elf_x86_allocate_dynrelocs): Use rel_tls_desc,
instead of elf.srelplt, for GOT_TLS_GDESC_P.
(_bfd_elf_x86_get_reloc_section): New function.
(_bfd_x86_elf_late_size_sections): Use rel_tls_desc, instead of
elf.srelplt, for GOT_TLS_GDESC_P. Remove next_tls_desc_index.
(_bfd_x86_elf_link_setup_gnu_properties): Allocate
.rela.tls/.rel.tls section for rel_tls_desc.
* elfxx-x86.h (elf_x86_link_hash_table): Add rel_tls_desc.
Remove next_tls_desc_index.
(_bfd_elf_x86_get_reloc_section): New.
(elf_backend_get_reloc_section): Likewise.
Andrew Burgess [Tue, 26 Aug 2025 15:56:07 +0000 (16:56 +0100)]
gdb/python: return gdbpy_ref<> from gdbpy_create_ptid_object
Update gdbpy_create_ptid_object (python/py-infthread.c) to return a
gdbpy_ref<> rather than a 'PyObject *'. This reduces the chances that
a caller will leak an object, though no such memory leaks are fixed in
this commit, this is just a code improvement patch.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Thu, 21 Aug 2025 12:42:44 +0000 (13:42 +0100)]
gdb: use existing argument more in rename_vmcore_idle_reg_sections
In corelow.c, in the function rename_vmcore_idle_reg_sections, the
argument ABFD holds the core file bfd pointer. When this function is
called current_program_space->core_bfd() is passed as the argument
value.
Within this function, we sometimes use the function argument, and
sometimes access current_program_space->core_bfd() directly.
This is confusing, and unnecessary. Lets not do that.
I've renamed the argument to cbfd (for Core file BFD), and then
updated the function to make use of this argument throughout. This
reduces the number of accesses to global state, which is, I think, a
good thing.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Thu, 21 Aug 2025 12:13:59 +0000 (13:13 +0100)]
gdb: more current_program_space->core_bfd() removal
This commit changes the signature of the gdbarch_core_info_proc method
so that it takes a 'struct bfd *' as an extra argument. This argument
is used to pass through the core file bfd pointer.
Now, in corelow.c, when calling gdbarch_core_info_proc, we can pass
through current_program_space->core_bfd() as the argument. Within the
implementations, (Linux and FreeBSD) we can use this argument rather
than having to access the core file through current_program_space.
This reduces the use of global state, which I think is a good thing.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Thu, 21 Aug 2025 11:58:30 +0000 (12:58 +0100)]
gdb: use current_program_space->core_bfd() a little less
The function linux_read_core_file_mappings is passed an argument CBFD,
which is the BFD for the core file. In
core_target::build_file_mappings, where the function is called, we
pass current_program_space->core_bfd() as the argument.
However, in linux_read_core_file_mappings, in some places we use the
CBFD argument, and in other places we directly use
current_program_space->core_bfd(). This is confusing, and
unnecessary. Lets not do that.
Standardise on just using CBFD. This removes some references to
global state in favour of passing the global state in as an argument,
I think this is a good thing.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Tue, 26 Aug 2025 19:38:22 +0000 (21:38 +0200)]
[gdb/tdep] Add XOP support in amd64_get_insn_details
Implement support for XOP instructions [1] in amd64_get_insn_details.
The encoding scheme is documented here [2]. Essentially it's a variant of the
VEX3 encoding scheme, with:
- 0x8f as the first byte instead of 0xc4, and
- an opcode map >= 8.
The changes are roughly the same as the XOP part of an earlier submission [3],
hence the tag.
The only real difference is that that patch proposed to implement xop_prefix_p
using:
...
return pfx[0] == 0x8f && (pfx[1] & 0x38);
...
which tries to resolve the conflict between the XOP prefix (starts with 0x8f)
and the POP instruction (opcode 0x8f) by detecting that it's not a POP
instruction.
Instead, use the way AMD has resolved this conflict in the specification, by
checking for opcode map >= 8:
...
gdb_byte m = pfx[1] & 0x1f;
return pfx[0] == 0x8f && m >= 8;
...
Tested on x86_64-linux.
Co-Authored-By: Jan Beulich <jbeulich@suse.com> Reviewed-By: Klaus Gerlicher<klaus.gerlicher.@intel.com>
[1] https://en.wikipedia.org/wiki/XOP_instruction_set
[2] https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/programmer-references/43479.pdf
[3] https://sourceware.org/pipermail/gdb-patches/2019-February/155347.html
Andrew Burgess [Sun, 24 Aug 2025 20:09:40 +0000 (21:09 +0100)]
gdb/python: fix an unlikely memory leak
I noticed a possible memory leak in gdbpy_create_ptid_object, in
py-infthread.c. We create a Tuple, and hold the reference in a
'PyObject*' local.
If we then fail to create any of the tuple contents we perform an
early exit, returning nullptr, this will leak the Tuple object.
Currently, we create the Tuple as the first action in the function,
but we don't really need the tuple until the end of the function.
In this commit I have:
1. Moved creation of the Tuple until the end of the function, just
before we need it.
2. Stored the Tuple reference in a gdbpy_ref<>. This is not
strictly needed any more, but is (I think) good practice as
future changes to the function will not need to worry about
releasing the Tuple object.
3. Taken the opportunity to replace a NULL with nullptr in this
function.
4. Inlined the local variable declarations to the point of first
use.
There should be no user visible changes after this commit.
No tests as I have no idea how to make gdb_py_object_from_longest (and
friends) fail, and so trigger the memory leak. I suspect we'd never
actually see this leak in the real world, but it doesn't hurt to clean
these things up.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Hui Li [Tue, 26 Aug 2025 01:45:57 +0000 (09:45 +0800)]
gdb: LoongArch: Improve loongarch_scan_prologue for correct backtrace
(1) Description of Problem:
When debugging the following code, the execution result of
the backtrace command is incorrect.
$ cat test.S
.text
.globl fun1
.type fun1, @function
fun1:
or $r12,$r0,$r0
or $r4,$r12,$r0
jr $r1
.globl fun
.type fun, @function
fun:
addi.d $r3,$r3,-16
st.d $r1,$r3,8
bl fun1
or $r12,$r4,$r0
or $r4,$r12,$r0
ld.d $r1,$r3,8
addi.d $r3,$r3,16
jr $r1
.globl main
.type main, @function
main:
addi.d $r3,$r3,-16
st.d $r1,$r3,8
bl fun
nop
ld.d $r1,$r3,8
addi.d $r3,$r3,16
jr $r1
$ gcc test.S -o test
$ gdb test
...
(gdb) b fun1
Breakpoint 1 at 0x748
(gdb) r
Breakpoint 1, 0x0000555555554748 in fun1 ()
(gdb) bt
#0 0x0000555555554748 in fun1 ()
#1 0x0000555555554758 in fun ()
#2 0x0000555555554758 in fun ()
#3 0x0000555555554758 in fun ()
....
--Type <RET> for more, q to quit, c to continue without paging
(2) Root Cause Analysis:
The return address of fun() in r1(ra) is saved on the stack:
addi.d $r3,$r3,-16
st.d $r1,$r3,8
The bl instruction in fun () will call the fun1 () and save
the value of pc+4 to r1(ra).
bl fun1
or $r12,$r4,$r0
Because registers such as fp and ra saved in the stack of the sub-function
are not recorded in current code. When trace back fun() to main(), the pc
of the previous frame to be read from ra register instead of the saved location
on the stack. At this time, the value of ra register in fun() is already the
address of the next instruction after the bl. So it is impossible to trace
back to the main().
(3) Solution:
Record the location of ra, fp, s0 to s8 on the stack to ensure the correct
execution of backtrace.
(4) Test:
$ gdb test
...
(gdb) b fun1
Breakpoint 1 at 0x748
(gdb) r
Breakpoint 1, 0x0000555555554748 in fun1 ()
(gdb) bt
#0 0x0000555555554748 in fun1 ()
#1 0x0000555555554758 in fun ()
#2 0x0000555555554778 in main ()
Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Hui Li [Tue, 26 Aug 2025 01:38:37 +0000 (09:38 +0800)]
gdb: LoongArch: Improve loongarch_scan_prologue to record stack information
(1) Description of Problem:
When debugging the following code, the execution result of
nexti command is incorrect.
$ cat test.S
.text
.globl fun
.type fun, @function
fun:
or $r12,$r0,$r0
or $r4,$r12,$r0
jr $r1
.globl main
.type main, @function
main:
addi.d $r3,$r3,-16
st.d $r1,$r3,8
bl fun
or $r12,$r4,$r0
or $r4,$r12,$r0
ld.d $r1,$r3,8
addi.d $r3,$r3,16
jr $r1
$ gcc test.S -o test
$ gdb test
...
(gdb) set disassemble-next-line on
(gdb) start
...
Temporary breakpoint 1, 0x0000555555554754 in main ()
=> 0x0000555555554754 <main+8>: 57ffefff bl -20 # 0x555555554740 <fun>
(gdb) ni
0x0000555555554740 in fun ()
=> 0x0000555555554740 <fun+0>: 0015000c move $t0, $zero
(2) Root Cause Analysis:
In the internal execution flow of the ni command, a single-step will be
executed first. After that, it will enter process_event_stop_test (),
some conditions are judged in this function.
Here, it will be judged whether a sub-function has been called based on
whether the frame id before the single step is not equal to the current
frame id and whether there is a calling relationship.
If a sub-function is called at this time and the current operation is nexti,
it will not stop immediately. Instead, insert_step_resume_breakpoint_at_caller()
will be called to complete the execution of the sub-function and then stop.
In above debugging examples, the executable program being debugged is compiled
from an asm source file that does not contain dwarf information. Therefore, the
frame id of the function is calculated by loongarch_frame_unwind rather than
dwarf2_frame_unwind. However, loongarch_scan_prologue() has not yet recorded
stack information in loongarch_frame_cache, this will cause problems in some
operations related to the frame id information.
(3) Solution:
Improve loongarch_scan_prologue() to record the stack information in
loongarch_frame_cache. And improve the loongarch_frame_unwind_stop_reason()
through the information recorded in loongarch_frame_cache.
(4) Test:
After this patch:
$ gdb test
(gdb) set disassemble-next-line on
(gdb) start
Temporary breakpoint 1, 0x0000555555554754 in main ()
=> 0x0000555555554754 <main+8>: 57ffefff bl -20 # 0x555555554740 <fun>
(gdb) ni
0x0000555555554758 in main ()
=> 0x0000555555554758 <main+12>: 0015008c move $t0, $a0
(gdb) ni
0x000055555555475c in main ()
=> 0x000055555555475c <main+16>: 00150184 move $a0, $t0
Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Hui Li [Tue, 26 Aug 2025 01:35:11 +0000 (09:35 +0800)]
gdb: LoongArch: Refactor member functions of loongarch_frame_unwind
In the current code, loongarch_frame_unwind is a LoongArch prologue unwinder,
it contains the required member functions, but they do not calculate a valid
frame id through prologue of a function frame. Refactor these functions and
use loongarch_frame_cache to record the information of the function frame.
No functional change intended.
Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Klaus Gerlicher [Fri, 8 Aug 2025 15:20:33 +0000 (17:20 +0200)]
amd64-tdep: need_modrm = 1 for VEX/EVEX instructions, except vzeroall/vzeroupper
VEX and EVEX-encoded instructions generally require a ModR/M byte, with the
notable exception of vzeroall and vzeroupper (opcode 0x77), which do not
use ModR/M.
This change sets need_modrm = 1 for VEX instructions, and adds an exception
for instructions where *insn == 0x77, following Intel’s SDM.
EVEX has no exceptions and thus always sets need_modrm to 1.
Additionally, the legacy twobyte_has_modrm table cannot be used for VEX and
EVEX instructions, as these encodings have different requirements and
exceptions. The logic is now explicit for VEX/EVEX handling.
Add vpblendw to selftest amd64_insn_decode.
The Intel SDM says the following:
1. Intel® 64 and IA-32 Architectures Software Developer’s Manual
Section 2.2.1.2 — Instruction Prefixes
"The VEX prefix is a multi-byte prefix that replaces several legacy prefixes
and opcode bytes. The VEX prefix is not an opcode; it is a prefix that
modifies the instruction that follows."
Section 2.2.1.3 — Opcode Bytes
"The opcode byte(s) follow any instruction prefixes (including VEX). The
opcode specifies the operation to be performed."
Section 2.2.2 — Instruction Format
"If a VEX prefix is present, it is processed as a single prefix, and the
opcode bytes follow immediately after the VEX prefix."
Source: Intel® SDM Vol. 2A, Section 2.2.1.2 and 2.2.2 (See Vol. 2A,
PDF pages 2-4, 2-5, and 2-7)
Tom de Vries [Tue, 26 Aug 2025 10:24:19 +0000 (12:24 +0200)]
[gdb/testsuite] Fix require dwarf2_support check in some test-cases
On x86_64-freebsd, I ran into trouble with test-case
gdb.dwarf2/macro-source-path-clang14-dw4.exp (and similar), and I managed to
reproduce the problem on x86_64-linux by making dwarf2_support return 0.
The failure looks like:
...
UNSUPPORTED: $exp: require failed: dwarf2_support
UNRESOLVED: $exp: testcase aborted due to invalid command name: do_test
ERROR: tcl error sourcing $exp.
...
I fixed a similar problem in commit 3e488d8ccd0 ("[gdb/testsuite] Fix
gdb.dwarf2/dw-form-strx-out-of-bounds.exp with make-check-all.sh").
Fix this by moving "require dwarf2_support" from
gdb.dwarf2/macro-source-path.exp.tcl to the files including it.
Jan Beulich [Tue, 26 Aug 2025 08:43:06 +0000 (10:43 +0200)]
ld/PE: don't emit relocations for weak absolute symbols
First we should check the flag alone, not the entire flags value
matching BSF_WEAK. And then using "else if()" is inappropriate here: A
weak symbol can very well also be absolute, and hence wouldn't want a
relocation emitted despite being defined.
Jan Beulich [Tue, 26 Aug 2025 08:42:31 +0000 (10:42 +0200)]
ld/ELF: explicitly place .note.gnu.property
x86 gas may produce .note.gnu.property by default. Hence the default
linker script would better also deal with that section, rather than
causing diagnostics when using --orphan-handling=. Replace all mis-
spellings that have accumulated.
To avoid needlessly relaxing expectations for two tests when run for
PPC 64-bit ELF targets, suppress the linker generating EH frame data
there.
Jan Beulich [Tue, 26 Aug 2025 08:42:03 +0000 (10:42 +0200)]
ld: entry size and merge/strings attributes propagation
While commit 9c0adb10c7fc ("elf: Clear entsize when clearing
SEC_MERGE|SEC_STRINGS") addressed the particular issue reported in
PR ld/33291, it didn't go quite far enough to deal with related aspects
as well:
As indicated in other recent commits, the three properties can be
largely independent (ELF generally being the target here): Entry size
doesn't require either of merge/strings, and strings also doesn't
require merge. Commit 98e6d3f5bd4e ("gas/ELF: allow specifying entity
size for arbitrary sections") uncovered issues with ld's handling.
Zap entry size when it doesn't match between input sections. In that
case SEC_MERGE and SEC_STRINGS also need to be removed, as their
underlying granularity is lost. Then deal with SEC_MERGE and
SEC_STRINGS separately.
Otoh record entry size from the first input independent of SEC_MERGE.
Kevin Buettner [Sun, 24 Aug 2025 03:54:30 +0000 (20:54 -0700)]
Fix tekhex format related gdb.base/dump.exp failures
On s390x, a big-endian machine, I'm seeing these test failures:
FAIL: gdb.base/dump.exp: array as memory, tekhex; file restored ok
FAIL: gdb.base/dump.exp: array as memory, tekhex; value restored ok
FAIL: gdb.base/dump.exp: array as value, tekhex; file restored ok
FAIL: gdb.base/dump.exp: array as value, tekhex; value restored ok
FAIL: gdb.base/dump.exp: array copy, tekhex; file restored ok
FAIL: gdb.base/dump.exp: array copy, tekhex; value restored ok
FAIL: gdb.base/dump.exp: array partial, tekhex; file restored ok
FAIL: gdb.base/dump.exp: array partial, tekhex; value restored ok
FAIL: gdb.base/dump.exp: dump array as memory, tekhex
FAIL: gdb.base/dump.exp: dump array as value, tekhex
FAIL: gdb.base/dump.exp: dump struct as memory, tekhex
FAIL: gdb.base/dump.exp: dump struct as value, tekhex
FAIL: gdb.base/dump.exp: reload array as memory, tekhex; value restored ok
FAIL: gdb.base/dump.exp: reload array as value, tekhex; value restored ok
FAIL: gdb.base/dump.exp: reload struct as memory, tekhex; value restored ok
FAIL: gdb.base/dump.exp: reload struct as value, tekhex; value restored ok
FAIL: gdb.base/dump.exp: struct as memory, tekhex; file restored ok
FAIL: gdb.base/dump.exp: struct as memory, tekhex; value restored ok
FAIL: gdb.base/dump.exp: struct as value, tekhex; file restored ok
FAIL: gdb.base/dump.exp: struct as value, tekhex; value restored ok
FAIL: gdb.base/dump.exp: struct copy, tekhex; file restored ok
FAIL: gdb.base/dump.exp: struct copy, tekhex; value restored ok
It turns out that there's a subtle bug in move_section_contents in
bfd/tekhex.c. The bug is that when attempting to write a buffer that
starts with a zero byte, the function will return false, an error
condition, without writing anything. But it also doesn't set
bfd_error, so GDB ends up displaying whatever the last unrelated error
was, e.g.:
warning: writing dump file '.../intstr1.tekhex' (No such file or directory)
When I investigated this, the bfd error was set during failure to
open a separate debug file for the test case, which is totally
unrelated to this problem.
The reason this fails on big endian machines is that the test case
writes out structs and arrays of int initialized to small values. On
little endian machines, the small integer is the first byte, so the
error doesn't occur. On big endian machines, a zero byte occurs
first, triggering the error.
On the GDB side of things, I've made a one line change to the test
case to cause the error to also happen on little endian machines. I
simply shift value of the first field in the struct left by 16 bits.
That leaves at least one zero byte on both sides of the non-zero part
of the int. I shifted it by 16 because, for a moment, there was a
question in my mind about what would happen with a second zero byte,
but it turns out that it's not a problem.
On the bfd side of things, take a look at move_section_contents() and
find_chunk() in tekhex.c. The scenario is this: we enter
move_section_contents with locationp pointing at a character buffer
whose first byte is zero. The 'get' parameter is false, i.e. we're
writing, not reading. The other critical fact is that the
abfd->tdata.tekhex_data->data is NULL (0).
I'm going to go through the execution path pretty much line by line
with commentary below the line(s) just executed.
char *location = (char *) locationp;
bfd_vma prev_number = 1; /* Nothing can have this as a high bit. */
I can't say that the comment provides the best explanation about
what's happening, but the gist is this: later on, chunk_number will
have it's low bits masked away, therefore no matter what it is, it
can't possibly be equal to prev_number when it's set to 1.
/* Get high bits of address. */
bfd_vma chunk_number = addr & ~(bfd_vma) CHUNK_MASK;
bfd_vma low_bits = addr & CHUNK_MASK;
Use CHUNK_MASK, which is 0x1fff, to obtain the chunk number, i.e.
whatever's left after masking off the low 13 bits of addr, and
low_bits, which are the low 13 bits of addr. chunk_number matters for
understanding this bug, low_bits does not. Remember that no matter
what addr is, once you mask off the low 13 bits, it can't be equal to 1.
bool must_write = !get && *location != 0;
!get is true, *location != 0 is false, therefore the conjunction is
false, and furthermore must_write is false. I.e. even though we are
writing, we don't transfer zero bytes to the chunk - this is why
must_write is false. (The reason this works is that a chunk, once
allocated, is zero'd as part of the allocation using bfd_zalloc.
Therefore we can skip transferring zero bytes and, if enough of them
are skipped one after another, chunk allocation simply doesn't happen.
That's a good thing.)
if (chunk_number != prev_number || (!d && must_write))
For the reason provided above, chunk_number != prev_number is true.
The other part of the disjunction doesn't matter since the first part
is true. This means that the if-block is entered.
/* Different chunk, so move pointer. */
d = find_chunk (abfd, chunk_number, must_write);
find_chunk is entered with must_write set to false. Now, remember
where we left off here, because we're going to switch to find_chunk.
d is set to NULL since abfd->tdata.texhex_data->data is NULL (one of
the conditions for the scenario).
vma &= ~CHUNK_MASK;
while (d && (d->vma) != vma)
d = d->next;
d is NULL, so the while loop doesn't execute.
if (!d && create)
...
d is NULL so !d is true, but create is false, so the condition
evaluates to false, meaning that the if-block is skipped.
return d;
find_chunk returns NULL, since d is NULL.
Back in move_section_contents:
if (!d)
return false;
d is NULL (because that's what find_chunk returned), so
move_section_contents returns false at this point.
Note that find_section_contents has allocated no memory, nor even
tried to transfer any bytes beyond the first (zero) byte. This
is a bug.
The key to understanding this bug is to observe that find_chunk can
return NULL to indicate that no chunk was found. This is especially
important for the read (get=true) case. But it can also be NULL
to indicate a memory allocation error. I toyed around with the
idea of using a different value to distinguish these cases, i.e.
something like (struct data_struct *) -1, but although bfd contains
plenty of code where -1 is used to indicate various interesting
conditions for scalars, there's no prior art where this is done
for a pointer. Therefore the idea was discarded in favor of
modifying this statement:
if (!d)
return false;
to:
if (!d && must_write)
return false;
This works because, in find_chunk, the only way to return a NULL
memory allocation error is for must_write / create to be true. When
it is true, if bfd_zalloc successfully allocates a chunk, then that
(non-NULL) chunk will be returned at the end of the function. When it
fails, it'll return NULL early. The point is that when bfd_zalloc()
fails and returns NULL, must_write (in move_section_contents) / create
(in find_chunk) HAD to be true. That provides us with an easy test
back in move_section_contents to distinguish a memory-allocation-NULL
from a block-not-found-NULL.
The other NULL return case happens when the end of the function is
reached when either searching for a chunk to read or attempting to
find a chunk to write when abfd->tdata.tekhex_data->data is NULL. But
for the latter case, must_write was false, which does not (now, with
the above fix) trigger the early return of false.
(Alan Modra approved the bfd/tekhex.c change.) Approved-By: Simon Marchi <simon.marchi@efficios.com> (GDB)
We can't put a breakpoint in the middle of a ll/sc atomic sequence,
handle the instructions sc.q, llacq.{w/d}, screl.{w/d} newly added
in the LoongArch Reference Manual v1.10 so a ll/sc atomic sequence
using them won't loop forever being debugged.
Signed-off-by: Xi Ruoyao <xry111@xry111.site> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Alan Modra [Sat, 23 Aug 2025 03:37:40 +0000 (13:07 +0930)]
PR 33302, Symbols truncated on i386pep target
Commit 012d44268695 effectively made peXXigen.c _bfd_XXi_swap_aux_out
always use the COFF E_FILNMLEN of 14. The problem was that the auxent
x_fname field was defined in include/coff/external.h using a length of
14. Later, E_FILNMLEN is redefined to 18 in coff/pe.h. This no doubt
falsely tripped memory checking tools. AUXESZ is 18, so no actual
buffer overrun.
This patch defines x_fname as an 18 char field, the full auxent, and
uses E_FILNMLEN when accessing.
PR 33302
include/
* coff/external.h (union external_auxent): Make x_fname
AUXESZ chars.
bfd/
* coffswap.h (coff_swap_aux_in): Correct #error message.
(coff_swap_aux_out): Likewise. Use E_FILNMLEN when copying
to ext field.
* peXXigen.c (_bfd_XXi_swap_aux_in): Add #error. Style fix.
(_bfd_XXi_swap_aux_out): Add #error. Don't use sizeof, use
E_FILNMLEN when copying to ext field.
gas
* testsuite/gas/pe/long_file_symbol.d,
* testsuite/gas/pe/long_file_symbol.s: New test.
* testsuite/gas/pe/pe.exp: Run it.
Alan Modra [Sat, 23 Aug 2025 07:09:51 +0000 (16:39 +0930)]
Tidy include/coff/external.h and internal.h
Mostly whitespace fixes and wrap of long comment lines, removal of block
comments and moving a few defines around. Nothing much to see here,
but AUXESZ before union external_auxent is needed by the next patch.
* coff/external.h: Whitespace fixes, wrap long comment lines,
remove header style comments. Move some defines.
(E_FILNMLEN): Remove #ifndef.
(_ETEXT): Don't define.
(SYMENT, AUXENT): Don't define, make them typedefs.
* coff/internal.h: Whitespace fixes, wrap long comment lines,
remove header style comments. Move some defines.
(signed): Don't define.
Alan Modra [Sat, 23 Aug 2025 06:57:12 +0000 (16:27 +0930)]
bfd/pe*.c including bfd/coff*.c
The model of a coff-<arch>.c file providing older COFF support, with a
pe-<arch>.c file defining some macros then including the coff-<arch>.c
file to provide PE support has been followed by a number of
architectures.
Some of them have PE specific code in their coff-<arch>.c files,
unconditionally compiled. ie. they are not for old COFF support, and
there was no reason to follow the model. They now get an error if
they are compiled stand-alone rather than being included from
pe-<arch>.c or pei-<arch>.c.
* coff-aarch64.c (COFF_WITH_peAArch64): Don't define here.
(COFF_WITH_PE): Error if not defined.
* coff-ia64.c (COFF_WITH_PE): Error if not defined.
* coff-loongarch64.c (COFF_WITH_peLoongArch64): Don't define here.
(COFF_WITH_PE): Error if not defined.
* coff-mcore.c (COFF_WITH_PE): Error if not defined.
* coff-riscv64.c (COFF_WITH_PE): Error if not defined.
* pei-aarch64.c: Remove duplicate includes.
* pei-loongarch64.c: Likewise.
* pei-riscv64.c: Likewise.
* pei-x86_64.c: Likewise.
Andrew Burgess [Wed, 18 Jun 2025 14:02:29 +0000 (15:02 +0100)]
gdb: allow gdb.Color to work correctly with pagination
This commit allows gdb.Color objects to be used to style output from
GDB commands written in Python, and the styled output should work
correctly with pagination.
There are two parts to fixing this:
First, GDB needs to be able to track the currently applied style
within the page_file class. This means that style changes need to be
achieved with calls to pager_file::emit_style_escape.
Now usually, GDB does this by calling something like fprintf_styled,
which takes care to apply the style for us. However, that's not
really an option here as a gdb.Color isn't a full style, and as the
gdb.Color object is designed to be converted directly into escape
sequences that can then be printed, we really need a solution that
works with this approach.
However pager_file::puts already has code in place to handle escape
sequences. Right now all this code does is spot the escape sequence
and append it to the m_wrap_buffer. But in this commit I propose that
we go one step further, parse the escape sequence back into a
ui_file_style object in pager_file::puts, and then we can call
pager_file::emit_style_escape.
If the parsing doesn't work then we can just add the escape sequence
to m_wrap_buffer as we did before.
But wait, how can this work if a gdb.Color isn't a full style? Turns
out that's not a problem. We only ever emit the escape sequence for
those parts of a style that need changing, so a full style that sets
the foreground color will emit the same escape sequence as a gdb.Color
for the foreground. When we convert the escape sequence back into a
ui_file_style, then we get a style with everything set to default,
except the foreground color.
I had hoped that this would be all that was needed. But unfortunately
this doesn't work because of the second problem...
... the implementation of the Python function gdb.write() calls
gdb_printf(), which calls gdb_vprintf(), which calls ui_file::vprintf,
which calls ui_out::vmessage, which calls ui_out::call_do_message, and
finally we reach cli_ui_out::do_message. This final do_message
function does this:
If we imagine the case where we are emitting a style, triggered from
Python like this:
gdb.write(gdb.Color('red').escape_sequence(True))
the STYLE in this case will be the default ui_file_style(), and STR
will hold the escape sequence we are writing.
After the first change, where pager_file::puts now calls
pager_file::emit_style_escape, the current style of STREAM will have
been updated. But this means that the final emit_style_escape will
now restore the default style.
The fix for this is to avoid using the high level gdb_printf from
gdb.write(), and instead use gdb_puts instead. The gdb_puts function
doesn't restore the default style, which means our style modification
survives.
There's a new test included. This test includes what appears like a
pointless extra loop (looping over a single value), but this makes
sense given the origin of this patch. I've pulled this commit from a
longer series:
I want to get this bug fix merged before GDB 17 branches, but the
longer series is not getting reviews, so for now I'm just merging this
one fix. Once the rest of the series gets merged, I'll be extending
the test, and the loop (mentioned above) will now loop over more
values.
H.J. Lu [Sat, 23 Aug 2025 21:04:52 +0000 (14:04 -0700)]
x86: Distinguish no PLT build and run test names
Change no PLT build and run test names from
PASS: No PLT (dynamic 1a)
...
PASS: No PLT (dynamic 1a)
to
PASS: Build no PLT (dynamic 1a)
...
PASS: Run no PLT (dynamic 1a)
in ld.log.
* testsuite/ld-i386/no-plt.exp (run_cc_link_tests): Change
"No PLT" to "Build no PLT" in no PLT build test names.
(run_ld_link_exec_tests): Change "No PLT" to "Run no PLT" in no
PLT run test names.
* testsuite/ld-x86-64/no-plt.exp (run_cc_link_tests): Change
"No PLT" to "Build no PLT" in no PLT build test names.
(run_ld_link_exec_tests): Change "No PLT" to "Run no PLT" in no
PLT run test names.
H.J. Lu [Sat, 23 Aug 2025 16:35:50 +0000 (09:35 -0700)]
x86-64: Use the GOT indirection in no-plt-check1.S
There is
cmpq %rax, func_p(%rip)
in no-plt-check1.S which requires copy relocation when func_p, a function
pointer, is defined in a shared library. Use the GOT indirection to
access func_p
Indu Bhagat [Sat, 23 Aug 2025 19:09:44 +0000 (12:09 -0700)]
libsframe: use offsets to FDE and FRE sub-sections
In SFrame format, the SFrame FDEs begin at an offset 'sfh_fdeoff' from
the end of the SFrame header. Similarly, the SFrame FREs begin at an
offset 'sfh_freoff' from the end of the SFrame header.
While the GNU assembler generates these subsections such that sfd_fdeoff
is zero, the correct way to decode the SFrame section (conforming with
the specification) is to use both sfh_fdeoff and sfh_freoff in
sframe_decode.
libsframe/
* sframe.c (sframe_decode): Use offsets to SFrame FDE and FRE
sub-sections as applicable.
Tom de Vries [Sat, 23 Aug 2025 06:44:34 +0000 (08:44 +0200)]
[gdb/testsuite] Require cooked index in two test-cases
After running the testsuite with target board cc-with-gdb-index I ran found
failures in test-cases:
- gdb.dwarf2/backward-spec-inter-cu.exp
- gdb.dwarf2/forward-spec-inter-cu.exp
Tom de Vries [Sat, 23 Aug 2025 06:15:51 +0000 (08:15 +0200)]
[gdb/symtab] Turn complaints in create_addrmap_from_gdb_index into warnings
Rather than issuing a complaint, which is off by default, warn when returning
false in create_addrmap_from_gdb_index, informing the user that the .gdb_index
was ignored, and why.
Tom de Vries [Sat, 23 Aug 2025 04:11:41 +0000 (06:11 +0200)]
[gdb] Make addrmap_mutable::set_empty return bool
Function addrmap_mutable::set_empty has the follow behavior (shortened
comment):
...
/* In the mutable address map MAP, associate the addresses from START
to END_INCLUSIVE that are currently associated with NULL with OBJ
instead. Addresses mapped to an object other than NULL are left
unchanged. */
void set_empty (CORE_ADDR start, CORE_ADDR end_inclusive,
void *obj);
...
Change the return type to bool, and return true if the full range
[START, END_INCLUSIVE] is mapped to OBJ.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Sat, 23 Aug 2025 04:11:41 +0000 (06:11 +0200)]
[gdb/symtab] Bail out of create_addrmap_from_gdb_index on error
Currently, in create_addrmap_from_gdb_index, when finding an incorrect entry
in the address table of a .gdb_index section:
- a (by default silent) complaint is made,
- the entry is skipped, and
- the rest of the entries is processed.
This is the use-what-you-can approach, which make sense in general.
But in the case that the .gdb_index section is incorrect while the other debug
info is correct, this approach prevents gdb from building a correct cooked
index (assuming there's no bug in gdb that would cause an incorrect index to
be generated).
Instead, bail out of create_addrmap_from_gdb_index on finding errors in the
address table.
I wonder about the following potential drawback of this approach: in the case
that the .gdb_index section is incorrect because the debug info is incorrect,
this approach rejects the .gdb_index section and spents time rebuilding a
likewise incorrect index. But I'm not sure if this is a real problem.
Perhaps gdb will refuse to generate such an index, in which case this is a
non-issue.
Tested on aarch64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Sam James [Thu, 3 Jul 2025 10:08:59 +0000 (11:08 +0100)]
gas: add --enable-default-sframe configure option
SFrames make the most sense when userland as a whole is built with them,
so add a --enable-default-sframe configure flag to facilitate distributors
and vendors doing that.
The primary motivation for a configure-time flag is that we don't support
SFrame for 32-bit x86 but some packaging uses the same flags (with some
added on top) for multilib builds (to support old binaries like games),
and simply adding `-Wa,--gsframe` to the standard build flags isn't an
option (*).
That aside, I believe it'll be helpful for testing and eventual adoption
in any case.
In summary, combined with the recent --gsframe=[yes|no] support (**):
* Configured with --enable-default-sframe and nothing is passed
=> SFrames (previously no SFrames)
* Configured with --enable-default-sframe and --gsframe=yes is passed
=> SFrames (no change from before)
* Configured with --enable-default-sframe and --gsframe=no is passed
=> No SFrames (no change from before)
* Configured with --enable-default-sframe and --gsframe is passed
=> SFrames (no change from before)
* Configured with --disable-default-sframe and nothing is passed
=> No SFrames (no change from before)
* Configured with --disable-default-sframe and --gsframe=yes is passed
=> SFrames (no change from before)
* Configured with --disable-default-sframe and --gsframe=no is passed
=> No SFrames (no change from before)
* Configured with --disable-default-sframe and --gsframe is passed
=> SFrames (no change from before)
I've introduced a sframe_as_bad macro on Indu's suggestion. A following
patch uses its sibling sframe_as_warn heavily and having symmetry plus
the macro as a form of documentation of intent seems useful.
(*) It gets added to multilib builds too and then we hit the
`.sframe not supported for target` error in gas/dw2gencfi.c.
(**) I've verbosely listed --gsframe=yes but it's the same as --gsframe.
gas/
PR gas/33126
* as.c (enum gen_sframe_option): Initialize if DEFAULT_SFRAME.
* config.in (DEFAULT_SFRAME): New.
* configure: Regenerate.
* configure.ac: Add --enable-default-sframe.
* doc/as.texi: Document --enable-default-sframe.
* dw2gencfi.c (cfi_finish): Don't warn if SFrames are enabled
by default but unavailable for this target.
* gen-sframe.h (sframe_as_bad): New macro.
projects / thirdparty / binutils-gdb.git / log
