Hannes Domani [Thu, 7 May 2026 18:54:54 +0000 (20:54 +0200)]
Implement native TLS support on Windows
GCC 16 introduced native TLS variables on Windows, so this adds
debugger support for them.
The fetch_tls_load_module_address gdbarch method is used to get the
address of _tls_index of the OBJFILE, which is then forwarded as LM_ADDR
to windows_get_thread_local_address.
The TLS slot for a module can be found in
TIB->thread_local_storage[_tls_index].
Tom de Vries [Sat, 23 May 2026 08:16:57 +0000 (10:16 +0200)]
[gdb/testsuite] Improve dwarf assembly for implicit const in .debug_names
In the assembly generated for the dwarf assembly for test-case
gdb.dwarf2/debug-names-tu-dwarf5.exp, there's this bit:
...
.uleb128 0x2003 /* DW_IDX_GNU_language */
.uleb128 0x21 /* DW_FORM_flag_present */
.sleb128 0x0002 /* DW_LANG_C */
...
As it happens, 0x21 is not DW_FORM_flag_present, but DW_FORM_implicit_const,
and the following entry is the value of the attribute.
Fix the comment, and make the relation between the two entries more clear by
printing:
...
.uleb128 0x2003 /* DW_IDX_GNU_language */
.uleb128 0x21 /* DW_FORM_implicit_const */
.sleb128 0x0002 /* DW_FORM_implicit_const value: DW_LANG_C */
...
Tom de Vries [Sat, 23 May 2026 08:16:57 +0000 (10:16 +0200)]
[gdb/testsuite] Add missing type_offset in gdb.dwarf/debug-names-tu.exp
With llvm-dwarfdump we run into this warning:
...
$ llvm-dwarfdump -a -v debug-names-tu > /dev/null
warning: DWARF type unit at offset 0x00000028 has its relocated type_offset \
0x00000028 pointing inside the header
...
Fix this by adding the missing type_offset.
Likewise in gdb.dwarf2/debug-names-bad-cu-index.exp.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34157
Tom de Vries [Fri, 22 May 2026 13:11:56 +0000 (15:11 +0200)]
[binutils] Handle implicit const in .debug_names
I tried to use readelf to read the debug info for gdb test-case
gdb.dwarf2/debug-names-tu-dwarf5.exp, and ran into some trouble reading the
.debug_names section:
...
$ readelf -w debug-names-tu-dwarf5
...
Symbol table:
[ 1] #eddb6232 _start: <0><1> DW_TAG_subprogram DW_IDX_compile_unit=0
[ 2] #53a2ae86 struct_with_int_member:readelf: Warning: Unrecognized form: 0
readelf: Error: end of data encountered whilst reading LEB
<0x3><2> DW_TAG_structure_type DW_IDX_type_unit=0 DW_IDX_GNU_language=0 DW_IDX_type_unitreadelf: Warning: Unrecognized form: 0
readelf: Error: end of data encountered whilst reading LEB
...
The .debug_names abbreviation table contains a DW_FORM_implicit_const entry:
...
.uleb128 0x2003 /* DW_IDX_GNU_language */
.uleb128 0x21 /* DW_FORM_implicit_const */
.sleb128 0x0002 /* DW_FORM_implicit_const value: DW_LANG_C */
...
and readelf doesn't support this.
Add support for DW_FORM_implicit_const in display_debug_names, such that we
get the expected:
...
Symbol table:
[ 1] #eddb6232 _start: <0><1> DW_TAG_subprogram DW_IDX_compile_unit=0
[ 2] #53a2ae86 struct_with_int_member: <0x3><2> DW_TAG_structure_type \
DW_IDX_type_unit=0 DW_IDX_GNU_language=2
...
Jan Beulich [Fri, 22 May 2026 06:49:12 +0000 (08:49 +0200)]
x86/disasm: rework comment handling
Model this after operand handling, such that comments can be emitted in
the same order as operands. %rip-relative address comments remain
separate for now. While there correct style for the symbols associated
with immediates: These aren't "comment starts", but symbol names.
The thread_local g_complaint_interceptor pointer is unnecessary. The
complaint_interceptor constructor registers itself as the warning hook
via m_saved_warning_hook (this), so when complaint_internal dispatches
through the warning hook, it lands in complaint_interceptor::warn with
'this' already pointing at the registered interceptor. Inside warn,
g_complaint_interceptor and 'this' always refer to the same object.
Replace g_complaint_interceptor->m_complaints with m_complaints in
complaint_interceptor::warn and remove g_complaint_interceptor.
Change-Id: I75565a5f2c0e51363f36be0e3544210c10bb5491 Approved-By: Tom Tromey <tom@tromey.com>
Location is heap block of size 32 at 0x7208000004c0 allocated by main thread:
...
#11 __static_initialization_and_destruction_0 /home/simark/src/binutils-gdb/gdb/complaints.c:31 (gdb+0xf0df04) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
...
This points to clear_complaints touching the global counters map in the
main thread without holding a lock, while a background thread touched
the map in a worker thread while holding the lock complaint_mutex.
Fix this by holding the complaint_mutex lock in clear_complaints.
Change-Id: Id2fe442486bcdf57156aacdc9253055702c07600 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 20 May 2026 18:19:29 +0000 (14:19 -0400)]
gdb/dwarf: track whether the all_units vector is sorted
dwarf2_find_unit performs a binary search over dwarf2_per_bfd::all_units
using std::lower_bound. Before calling std::lower_bound, we want to
make sure that all_units is properly sorted.
Track the state of whether all_units is considered sorted with a new
dwarf2_per_bfd::all_units_sorted flag, and assert it in
dwarf2_find_unit. This will help catch bugs where we call
dwarf2_find_unit on a non sorted vector, for instance what was fixed by
commit fbaef7de7701 ("gdb/dwarf: fix order of operations when reading
.debug_names").
The flag is set:
- At initialization time, because an empty vector is sorted.
- Whenever the vector is cleared, for the same reason (added a helper
method for that).
- After sorting in dwarf2_per_bfd::sort_all_unit.
It is cleared:
- Whenever a unit is appended to all_units. To keep this centralized,
add a new dwarf2_per_bfd::add_unit helper that appends the unit and
clears the flag.
- Whenever a unit's sort key (section / sect_off) is modified. That is
done in dwarf2_per_cu::set_section and dwarf2_per_cu::set_sect_off.
Note that the flag is cleared when appending a unit even if the vector
would by chance already be sorted. This is good, because it will catch
mistakes even on machines where a problem with std::lower_bound would
not manifest.
I checked that this patch would have caught the problem before commit fbaef7de7701:
Simon Marchi [Wed, 20 May 2026 18:19:28 +0000 (14:19 -0400)]
gdb/dwarf: change signatured_type_up to include deleter type
We currently have:
using dwarf2_per_cu_up = std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>;
using signatured_type_up = std::unique_ptr<signatured_type>;
Meaning that it's not possible to pass a signatured_type_up as a
dwarf2_per_cu_up, even though the target types are related (it is
possible to pass a `signatured_type *` as a `dwarf2_per_cu *`).
If we give signatured_type_up the same deleter as dwarf2_per_cu_up, then
it becomes possible to pass a signatured_type_up as a dwarf2_per_cu_up.
This lets us avoid releasing a signatured_type_up only to create a
dwarf2dwarf2_per_cu_up immediately after in some spots. The only
downside is that we can't use make_unique anymore, but it's already the
case for dwarf2_per_cu_up.
Swap the order of things in add_type_unit so that we don't need a
special holder variable.
Change-Id: Iee34e5d1711d601297f109e58cbaeccb5a0c6cde Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 8 May 2026 16:44:59 +0000 (10:44 -0600)]
Add test for Ada abs operator
There were no tests in the tree for the Ada abs operator, meaning that
ada_abs was never invoked during a test. This patch adds a new basic
test for this.
Note that operator overloading of 'abs' does seem to be tested.
Tom Tromey [Fri, 8 May 2026 16:36:26 +0000 (10:36 -0600)]
Test attributes with array types
While looking at code coverage, I noticed that gdb was not testing the
case where certain attributes were applied to an Ada array type. This
patch adds some new tests, improving the coverage.
gdb/amd-dbgapi-target: suppress a repeated stop request
Sending a second stop request to an AMD GPU thread before fetching the
event caused by the first request leads to an error:
wave_stop for wave_1 failed (The wave has an outstanding stop request)
Prevent sending a new stop request if there already is an outstanding
one. The fix is in amd_dbgapi_target::stop.
A regression test is included. The test uses non-stop mode and
executes the "interrupt" command twice, because in non-stop mode this
command uses the 'stop' target op, where the fix is applied.
To be able to execute two interrupt commands repeatedly, we define a
user command.
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Abdul Basit Ijaz [Tue, 21 Apr 2026 12:05:08 +0000 (14:05 +0200)]
gdb: Handle TYPE_CODE_COMPLEX in valprint_check_validity.
When printing complex variables with partial optimization (e.g., real
part available but imaginary part optimized out), GDB incorrectly
reported the entire variable as <optimized out> instead of showing
available components.
The issue occurred because valprint_check_validity () only exempted
TYPE_CODE_UNION, TYPE_CODE_STRUCT, and TYPE_CODE_ARRAY from the
optimized-out check, but not TYPE_CODE_COMPLEX. Complex types, like
structures, can have components with different availability.
A new test gdb.dwarf2/complex-partial-optimized.exp is added to verify
that available components are printed.
Simon Marchi [Tue, 19 May 2026 20:09:10 +0000 (16:09 -0400)]
gdb/dwarf: fix order of operations when reading .debug_names
PR 34149 shows a hard to reproduce bug. The problem sometimes shows up
when reading in `.debug_names` indexes, manifesting like this:
warning: Section .debug_names has incorrect entry in CU table, ignoring .debug_names.
This is shown even if the CU table in the `.debug_names` index
accurately describes the CUs in `.debug_info`.
The bug was introduced by commit b301725d35c1 ("gdb/dwarf: read foreign
type units").
Before b301725d35c1, the steps when reading a `.debug_names` index were:
- call to create_all_units(), which filled the all_units vector by
walking `.debug_info` and `.debug_types` and then sorted it.
- calls to the build_and_check_* functions, which do some lookups in
the all_units vector, requiring it to be sorted.
- call to create_all_units(), which still fills the all_units vector by
walking `.debug_info` and `.debug_types`, but does not sort it
anymore.
- calls to the build_and_check_* functions, which do some lookups in
the all_units vector, requiring it to be sorted (oops)
- call to create_foreign_type_units_from_debug_names(), which may add
more items to the all_units vector.
- call to finalize_all_units(), to sort the all_units vector.
The sorting of all_units was taken out of create_all_units() on purpose.
Because create_foreign_type_units_from_debug_names() may add more units,
we don't want to sort the vector in create_all_units() and then sort it
again after create_foreign_type_units_from_debug_names().
The build_and_check_* functions do some lookups in the all_units vector
with dwarf2_find_unit(), which uses std::lower_bound() internally. This
happens while the all_units vector is not sorted according to the
sorting key, all_units_less_than(), which makes the search is bogus.
dwarf2_find_unit() might return "no such unit", when in fact, the given
unit exists. This leads build_and_check_cu_list_from_debug_names() to
believe that the list of CUs in the `.debug_names` index does not match
what was built from reading `.debug_info`, we get the warning shown
above, and the index gets wrongfully rejected.
For this bug to show up, it is necessary to have type units in a
`.debug_types`. The sorting key for units in the all_units vector is:
section pointer (`dwarf2_section_info *`), then the unit offset into the
section. If all units come from the same section (`.debug_info`), then
this bug does not show up because the all_units vector happens to be
sorted after create_all_units() runs. This happens for example in test
gdb.dwarf2/debug-names-bad-cu-index.exp, where we create some DWARF 4
units and then a `.debug_names` index out of them.
It must also happen for the `dwarf2_section_info *` for `.debug_types`
to be "less than" the `dwarf2_section_info *` for `.debug_info`,
otherwise the all_units also happens to be sorted after
create_all_units() runs. This entirely depends on the whims of the
memory allocator.
I was not able to reproduce it in my normal GDB dev build, but I was
able in a "thread sanitizer" build, for some reason. Not because there
is an actual threading issue, but I think because it shuffled the memory
allocations in just the right way to make the bug happen. And then, it
only happened when doing "make check", I could not get it to reproduce
when running interactively. Using -D_GLIBCXX_DEBUG was immensely
useful, because it pointed out that the "range must be sorted"
precondition for std::lower_bound() was not met, which made the problem
immediately obvious:
Error: elements in iterator range [first, last) are not partitioned by the
predicate __comp and value __val.
Knowing all this, is it easy to artificially reproduce the problem by
making create_all_units() reverse the all_units vector, like so:
// Reverse the all_units vector
std::reverse (per_objfile->per_bfd->all_units.begin (),
per_objfile->per_bfd->all_units.end ());
The fix is to reorder the operations in this way
- call create_all_units(), to fill the all_units vector by walking
`.debug_info` and `.debug_types`
- call create_foreign_type_units_from_debug_names(), which may add more
items to the all_units vector.
- call finalize_all_units(), to sort the all_units vector.
- call the build_and_check_* functions, which is fine now that
all_units is sorted.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34149
Change-Id: I315f391605af549b55341a167683d2dc6203bcea Approved-By: Tom Tromey <tom@tromey.com>
Alan Modra [Tue, 12 May 2026 00:27:16 +0000 (09:57 +0930)]
PR 30308 again
Commit 22f8905d9f38 reintroduced pr30308. This fix resolves equates
safely in the presence of symbol loops by using symbol_equated_to.
Symbols aren't prematurely modified, by copying their value
expressions before i386_intel_simplify does its work. I figure that
it is safer to do this for all symbols rather than just the particular
case of equates, so the in_equate parameter can disappear.
Tom de Vries [Wed, 20 May 2026 06:31:12 +0000 (08:31 +0200)]
[gdb/tui] Allow second tui enable if first fails
Commit fb23d7ba4a2 ("[gdb/tui] Handle error in tui_enable") handles a
particular error during tui_enable, but doesn't allow trying to enable TUI
again.
I tried to get this to work, but didn't manage because I didn't understand the
interaction between endwin and the "tui_batch_rendering defer" destructor:
- first endwin restores the shell terminal mode
- then the defer destructor calls doupdate, restoring program terminal mode.
Fix this by checking for tui_active in ~tui_batch_rendering.
Tom de Vries [Wed, 20 May 2026 06:31:12 +0000 (08:31 +0200)]
[gdb/tui] Factor out require_tui_terminal
I noticed this bit of code in tui_enable:
...
/* Check required terminal capabilities. The MinGW port of
ncurses does have them, but doesn't expose them through "cup". */
cap = tigetstr ((char *) "cup");
if (cap == NULL || cap == (char *) -1 || *cap == '\0')
{
endwin ();
delscreen (s);
error (_("Cannot enable the TUI: "
"terminal doesn't support cursor addressing [TERM=%s]"),
gdb_getenv_term ());
}
...
At this point in tui_enable, we need endwin and delscreen to clean up after
newterm, but the check can be done before newterm.
Fix this by factoring out a new function require_tui_terminal, and moving the
code there.
Andrew Burgess [Thu, 14 May 2026 16:47:01 +0000 (17:47 +0100)]
gdb/testsuite: add a test to check for Python traits static_assert
The previous two commits added a new type trait which can be used
within a static_assert to check the properties of a struct used by GDB
to implement Python objects.
The previous commit fixed a bug in GDB which this trait check exposed.
This commit adds a new test gdb.gdb/python-traits-check.exp which
checks that every struct in the Python/ directory that inherits from
PyObject, has a suitable static_assert in place.
Adding this test should mean that if someone adds a new Python object
type to GDB, and they forget to add the static_assert, then this test
should give a failure, which should remind them to add the required
static_assert. The static_assert will then check that their new
struct is compliant.
Andrew Burgess [Thu, 14 May 2026 09:42:59 +0000 (10:42 +0100)]
gdb/python: fix use of frame_info_ptr within pending_frame_object
The previous commit added a type trait which identifies types that
should not be used within Python objects, that is, types that are not
trivially default constructible. As a result of this, it was
discovered that pending_frame_object includes a frame_info_ptr field.
The problem with frame_info_ptr is that its constructor registers the
new frame_info_ptr with the global frame_list. It is by this
registration that invalidation of frame_info_ptr objects is performed.
As Python is written in C, C++ constructors are not called, so when a
pending_frame_object is created the constructor for the nested
frame_info_ptr field is never run, and the frame_info_ptr is never
registered with the global frame_list. As a result the frame_info_ptr
will never be invalidated if the frame cache is flushed, this can then
lead to problems where we make use of the 'frame_info *' within the
frame_info_ptr, even though it is no longer valid.
In this commit I change the frame_info_ptr within pending_frame_object
to a 'frame_info_ptr *' and allocate the frame_info_ptr object on the
heap, releasing the object, and resetting the point to NULL, when we
are done with it. As the pending_frame_object only needs to remain
valid for the duration of frame_unwind_python::sniff, the 'new' and
'delete' both performed within the function.
We can now check that a pending_frame_object is valid by checking if
the 'frame_info_ptr *' is NULL or not. As the frame_info_ptr is
created in a valid state, and the point is set back to NULL when we
are done with it, we no longer need to compare the frame_info_ptr
object itself against NULL.
The remaining changes in this patch are to dereference the
'frame_info_ptr *' in places where we need the actual object. In some
cases I need to move the dereference later within a function, after a
validity check, in order to avoid dereferencing a NULL pointer.
Finally, I can add the static_assert that guarantees that
pending_frame_object is now safe for allocation by Python.
I discovered this bug while looking at PR gdb/32120. That bug is
about a user's custom frame unwinder that triggers a flush of the
frame cache during the sniffer phase (the
RemoteTargetConnection.send_packet call switches thread, which
triggers the frame cache flush). While looking at that bug I noticed
that the frame_info_ptr within the pending_frame_object wasn't being
reset when the frame cache was flushed. Fixing this does not resolve
the user's issue, but I thought it was still worth tagging this commit
with the bug link.
Andrew Burgess [Thu, 14 May 2026 08:39:57 +0000 (09:39 +0100)]
gdb/python: add type traits check for all PyObject sub-classes
All of our custom Python types are created as structs, like this:
struct some_new_type : public PyObject
{
... various fields ...
};
Then instances of this struct are created by calling PyObject_New,
either directly within GDB's C++ code, or within Python when a user's
Python script creates an instance of that class.
The problem is that Python is written in C, and PyObject_New doesn't
call any constructors for `some_new_type`, nor for any of the fields
within `some_new_type`.
If `some_new_type` is Plain Old Data (POD), then this is fine. Or, to
be more C++ specific, if `some_new_type` is trivially default
constructable, then we're fine.
But if a field within `some_new_type` has a non-trivial constructor,
then we're in trouble as that constructor will never be run.
An example of a problematic field type is frame_info_ptr. The
constructor for this type registers the new object with a central
management object, recording the `this` pointer, using this type within
`some_new_type` will not work as expected; frame invalidation will not
show up within the frame_info_ptr as you might expect.
And so, this type trait exists. Whenever a struct is created to define
a new Python type we should add a line like:
This will fail if any field of `some_new_type` are unsuitable for this
use.
We don't actually check is_trivially_default_constructible here. Some
types, e.g. ui_file_style::color, have non-trivial (or no default)
constructors, but are still safe to use within `some_new_type` because
their constructors just initialise data fields; there's nothing
"special" that the constructor does that cannot be achieved by
assigning the fields after creation with PyObject_New.
What actually matters is that the type is trivially destructible
(Python won't call C++ destructors, so destructors with side effects,
like deregistering from a list, would be skipped) and trivially
copyable (Python may copy objects with memcpy). Types like
frame_info_ptr, whose constructors and destructors have side effects
such as registering with a central management object, will be caught
because they are neither trivially destructible nor trivially copyable.
Simple POD types like ui_file_style are trivially destructible and
copyable, so pass this trait.
This commit adds the new type trait, and makes use of it in all cases
but one, pending_frame_object in python/py-unwind.c, has a field of
type frame_info_ptr, which is currently broken. This will be fixed,
and the static_assert added, in the next commit.
Alan Modra [Sat, 16 May 2026 00:57:26 +0000 (10:27 +0930)]
Re: binutils/configure: look for msgpack-c.pc (in addition to msgpack.pc)
Commit 520c7eefed7f results in the following if both msgpack-c and
msgpack are missing.
checking for msgpack-c... no
checking for msgpack... no
configure: error: Package requirements (msgpack) were not met:
Package 'msgpack', required by 'virtual:world', not found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables MSGPACK_CFLAGS
and MSGPACK_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make[2]: *** [Makefile:920: config.status] Error 1
make[2]: Leaving directory '/build/gas/all/binutils'
make[1]: *** [Makefile:4123: all-binutils] Error 2
binutils/
* configure.ac <msgpack>: Tell PKG_CHECK_MODULES that errors
will be handled by its caller.
* configure: Regenerate.
bfd/
* bfd-in2.h: Regenerate.
Tom Tromey [Thu, 7 May 2026 18:08:40 +0000 (12:08 -0600)]
Handle DW_AT_encoding on DW_TAG_enumeration_type
A user pointed out a problem when printing certain values from an Ada
enumeration type. Investigation showed that the problem was that some
enumeration constants were emitted using DW_FORM_data1, and were
incorrectly sign-extended by gdb.
First, this is yet another instance of a general problem with DWARF.
See https://sourceware.org/bugzilla/show_bug.cgi?id=32680 for the
analysis.
Meanwhile, it turns out that GCC implements an extension to handle
this scenario. In particular, in non-strict mode, it will emit
DW_AT_encoding using either DW_ATE_signed or DW_ATE_unsigned. This
was done back in 2017 by Pierre-Marie, in support of Ada -- but then
somehow nothing was ever implemented on the gdb side. For this see
GCC commit f76f096e ("DWARF: add DW_AT_encoding attributes for
DW_TAG_enumeration_type DIEs").
This patch adds the missing code to gdb. The included test case shows
the bug that was originally reported. I've also included the snippet
from Pierre-Marie's commit message for good measure.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 Approved-By: Andrew Burgess <aburgess@redhat.com>
I came across this code:
...
if (c)
return v;
else
Py_RETURN_NONE;
...
and realized I couldn't easily rewrite it into "return c ? v : ...".
Probably something like this would work:
...
return c ? v : ([] { Py_RETURN_NONE; } ());
...
but it made me wonder if we can get rid of Py_RETURN_NONE.
The only point of it seems to be to increase the reference count on the
Py_None object for older python versions.
Add a refcount-safe wrapper py_none (returning a gdbpy_ref), with the aim of
replacing all uses of Py_RETURN_NONE with "return py_none ().release ()".
Likewise for Py_RETURN_TRUE/Py_RETURN_FALSE/Py_RETURN_NOTIMPLEMENTED.
Simon Marchi [Thu, 7 May 2026 19:23:12 +0000 (15:23 -0400)]
binutils/configure: look for msgpack-c.pc (in addition to msgpack.pc)
msgpack.pc was renamed to msgpack-c.pc in this commit [1]. This means
that we now find both in the wild. For example Debian Bookworm has
msgpack.pc [2] while Debian Trixie has msgpack-c.pc [3].
Update the check in configure.ac to check for both. Nothing in the code
needs to change.
Alice Carlotti [Thu, 7 May 2026 06:08:53 +0000 (07:08 +0100)]
aarch64: Add new qualifier AARCH64_OPND_QLF_UNUSED
Replace QLF_NIL with QLF_UNUSED for qualifier sequence list padding.
This splits apart distinct qualifier meanings, and simplifies detection
of empty qualifier sequences.
Alice Carlotti [Thu, 29 Jan 2026 12:44:10 +0000 (12:44 +0000)]
aarch64: Add new qualifier ARCH64_OPND_QLF_UNKNOWN
Some uses of AARCH64_OPND_QLF_NIL actually represent an unknown operand
qualifier. The F_STRICT flag was added to disable the wild card
behaviour for most SVE instructions, but this just makes the code less
consistent and more confusing.
Add a new qualifer to indicate that the real qualifier is currently
unknown, and use this in any place where we need the wildcard behaviour
(and in a few other places where UNKNOWN is more descriptive than NIL).
For consistency (and as an extra check during development), change the
default qualifier value during parsing to AARCH64_OPND_QLF_ERR, and add
explicit qualifier assignments to each non-failure code path.
Alice Carlotti [Thu, 29 Jan 2026 12:10:43 +0000 (12:10 +0000)]
aarch64: Return QLF_ERR for error conditions
In vectype_to_qualifier and get_qualifier_from_partial_encoding, return
AARCH64_OPND_QLF_ERR instead of AARCH64_OPND_QLF_NIL to indicate an
error condition.
Alice Carlotti [Thu, 29 Jan 2026 12:14:33 +0000 (12:14 +0000)]
aarch64: Add QLF_ERR to aarch64_opnd_qualifiers
Add an entry to aarch64_opnd_qualifiers for AARCH64_OPND_QLF_ERR. This
should never be used (otherwise we would previously have had
out-of-bounds memory accesses), but it makes the array length match the
enum length, and might be slightly more robust.
Alice Carlotti [Thu, 29 Jan 2026 16:32:19 +0000 (16:32 +0000)]
aarch64: Append explicit NILs to qualifier sequences
For some opcodes, the NIL qualifier on the final operand was set
implicitly via empty initialisation of the unspecified entries in the
list of qualifier sequences. Make this assignment explicit, to avoid
depending on the numerical value of AARCH64_OPND_QLF_NIL.
Alice Carlotti [Fri, 1 May 2026 16:25:13 +0000 (17:25 +0100)]
aarch64: Make FPIMM0 qualifiers consistent
Two entries in the opcode table used QLF_S_H for the FPIMM0 operand
instead of the QLF_NIL operand used elsewhere. There is no good reason
for this inconsistency, so change them to use QLF_NIL as well.
Alice Carlotti [Fri, 30 Jan 2026 12:13:06 +0000 (12:13 +0000)]
aarch64: Fix qualifier sequences for cinc/cinv/cneg
The three-operand cinc/cinv/cneg instructions were incorrectly specified
with the same qualifier sequences as the four-operand variants, which
resulted in their third operand having an incorrect qualifier specified.
This works fine while AARCH64_OPND_QLF_NIL is treated as a wildcard, but
will break when that behaviour is removed.
Alice Carlotti [Thu, 29 Jan 2026 12:17:24 +0000 (12:17 +0000)]
aarch64: Fix ldst_lo12_determine_real_reloc_type
Add fallback handling for an invalid choice of opd0_qlf, instead of
hitting an assert when trying to use X registers in byte or half
instructions.
Additionally, simplify the code by inlining the relevant parts of
aarch64_get_expected_qualifer, and by deducing the array index directly
from the qualifier enum values (instead of looking up the element size
and computing its log).
This makes aarch64_get_expected_qualifier unused, so remove it.
Alice Carlotti [Fri, 30 Jan 2026 17:11:29 +0000 (17:11 +0000)]
aarch64: Add F_REQUIRES_SP and eliminate QLF_SP and QLF_WSP
Add a new opcode flag F_REQUIRES_SP and use that to enforce the
requirement for at least one SP operand in the mov (to/from SP) opcode.
This requirement was the only reason for the existence of the QLF_SP and
QLF_WSP qualifiers. Delete them, and remove the confusing code that
would switch between SP and non-SP qualifiers in the middle of qualifier
matching.
Alice Carlotti [Fri, 30 Jan 2026 12:04:06 +0000 (12:04 +0000)]
aarch64: Fix use of wrong zero enum value
aarch64_get_expected_qualifier was incorrectly comparing an
aarch64_opnd_qualifier_t against AARCH64_OPND_NIL instead of
AARCH64_OPND_QLF_NIL (these are the zero values of two different enums).
A previous patch incorrectly addressed the type mismatch by casting the
qualifier to (enum aarch64_opnd).
Fix it properly by removing the cast and updating the comparison to use
AARCH64_OPND_QLF_NIL.
Andrew Burgess [Fri, 8 May 2026 14:13:16 +0000 (15:13 +0100)]
gdb: use value::embedded_offset in check_pieced_synthetic_pointer
This commit builds on the previous two commits. You should go and
read them both for context.
Looking at the users of value::bits_synthetic_pointer, all callers but
two are now passing either the offset of a field within the value, or
hard-coded zero as they want to ask about the entire value.
The two exceptions are in coerce_pieced_ref (in dwarf2/expr.c) and in
value_addr (in valops.c) where we still pass value::embedded_offset.
The problem is that some of the other callers, where we currently pass
just a field offset, might also have a non-zero embedded offset,
specifically, the call in cp_print_value_fields is in this category.
In cp_print_value_fields we are printing fields from a value which is
potentially a base class contained within an instance of a derived
class, this will be represented by a non-zero embedded_offset, which
is currently not taken into account.
Additionally, the two callers that currently pass the
value::embedded_offset don't scale the embedded offset from bytes to
bits.
The failure to scale from bytes to bits is interesting, I originally
tried to create some tests that exposed this, but constantly failed.
It turns out, that in both these locations, in all code paths that I
could find, the value::embedded_offset will always be zero. For
example in coerce_pieced_ref, a reference cannot be a base class, and
so we never expect to see a non-zero embedded_offset in this case.
Similarly, in value_addr, the use of value::bits_synthetic_pointer is
within a block that only applies to reference types, which means the
embedded_offset will be zero.
Now within check_pieced_synthetic_pointer we already add the
value::offset into the bit_offset which is passed in. Remember, after
the previous two commits, the incoming bit_offset is (almost) always
the offset of a field within the value. The almost here is the two
cases mentioned above.
I propose that within check_pieced_synthetic_pointer we should take
into account both value::offset and value::embedded_offset. Then the
two cases that currently pass value::embedded_offset can be changed to
just pass zero.
With this done, and the previous two commits, we now have a consistent
model. value::bits_synthetic_pointer expects the (bit) offset of a
field within the value to check. In many cases this will be zero
meaning we want to check from the start of the value, but in some
cases it can be non-zero.
Then within value::bits_synthetic_pointer implementations, like
check_pieced_synthetic_pointer, we will take the value::offset and
value::embedded_offset into account, remembering to scale them from
bytes to bits.
I have also changed indirect_pieced_value to also take the
embedded_offset into account. I have done this for consistency rather
than necessity. I believe that the embedded_offset will always be
zero within indirect_pieced_value. The indirect_pieced_value function
is only called from value_ind (in valops.c), and only operates on
TYPE_CODE_PTR types (checked for in indirect_pieced_value). As a
TYPE_CODE_PTR cannot be the base class for a derived type, then we
don't expect to ever see a TYPE_CODE_PTR value with a non-zero
embedded_offset. But, having indirect_pieced_value take the embedded
offset into account is simple enough, and future proofs the code.
In both check_pieced_synthetic_pointer and indirect_pieced_value I
have changed uses of '8' to 'TARGET_CHAR_BIT', I was already touching
some of these lines, and I think TARGET_CHAR_BIT is clearer, but one
line in indirect_pieced_value was just updated to use TARGET_CHAR_BIT,
this is done for consistency.
The gdb.dwarf2/multi-piece-inherited-bitfield.exp test fails without
this patch, this exposes the case where the embedded_offset is
non-zero and we were previously failing to take this into account.
The gdb.dwarf2/multi-piece-primitive-field.exp test was something I
wrote while trying to exercise the coerce_pieced_ref code path some
more. It is an inheritance based version of the existing test, I was
wondering if this would result in a value with a non-zero
embedded_offset, but due to how the fields are extracted from the
aggregate prior to calling coerce_pieced_ref the embedded_offset is
always zero in this function.
Andrew Burgess [Fri, 8 May 2026 20:25:11 +0000 (21:25 +0100)]
gdb: remove embedded_offset argument that is always 0
For the background and motivation for this patch you should read the
previous commit.
The goal of this commit started as similar to the previous one; rename
the embedded_offset argument to generic_val_print_ref. To do this I
started tracing back which values are passed into this function so I
could make sure the new argument name matched the usage.
But it turns out that the only value that is ever passed to this
function is zero.
I believe that, like the last commit, the embedded_offset is actually
representing the offset of a field within a value. However, in all of
the use cases, the "field" being accessed is the entire value, hence
why we always pass 0, we are asking about the whole value starting
from the very beginning.
Given this, I couldn't bring myself to rename the argument. Let's just
remove it. It turns out that there's a bunch of functions in
valprint.c that take an argument called embedded_offset, which are
always zero.
This commit removes the argument, and updates the code to assume zero.
There should be no user visible changes after this commit.
This passes the result from value::embedded_offset as the first argument.
Though it's not clear from value.h, the number returned by
value::embedded_offset is a byte offset.
The value::bits_synthetic_pointer call can end up calling
check_pieced_synthetic_pointer, with the first argument to
value::bits_synthetic_pointer becoming the second argument to
check_pieced_synthetic_pointer. The second argument to
check_pieced_synthetic_pointer is called BIT_OFFSET, a value in bits.
Looking at how this argument is used confirms that it is expected to be
a value in bits, not bytes.
The fix should be easy, multiply the embedded offset by
TARGET_CHAR_BIT, but I think things are a little more complex than
this.
I started looking at how value::bits_synthetic_pointer is used, there
are only 7 uses, and they can be grouped as follows:
gdb/dwarf2/expr.c
gdb/valops.c
These call value::embedded_offset directly within the call to
value::bits_synthetic_pointer.
gdb/opencl-lang.c
This function is used as a wrapper that implements a
lval_funcs::check_synthetic_pointer callback, it adjusts the
arguments and then calls value::bits_synthetic_pointer. As such we'd
not expect to see embedded offset mentioned here as that would (we
assume) be handled by the caller.
gdb/valprint.c (in generic_val_print_ref)
This call passes an argument called 'embedded_offset', but the
function generic_val_print_ref is only used in one place, and the
embedded_offset is always passed as zero.
gdb/valprint.c (in valprint_check_validity)
This call also passes an argument called 'embedded_offset'. This
function is used in two places. In common_val_print the
embedded_offset is always passed as zero, but in
valprint_check_validity (in cp-valprint.c) the embedded_offset being
passed is the offset of a field within the value, not the value's
embedded_offset within some larger value.
gdb/cp-valprint.c
gdb/p-valprint.c
As with the call to valprint_check_validity in cp-valprint.c, these
two direct calls to value::bits_synthetic_pointer pass the offset of a
field within the value, rather than the value's embedded_offset.
What I see in the above is some confusion. In some places we are
passing the value::embedded_offset, while in other places we are
passing the offset of a field within the value itself.
If we consider the direct call to value::bits_synthetic_pointer in
gdb/cp-valprint.c, where a field offset is passed, then it should be
possible, that if we can create an object with a non-zero
embedded_offset (which isn't accounted for in this code path), then we
should see some bugs in GDB, and indeed, this is what I do see.
My plan for fixing this is to have the offset passed to
value::bits_synthetic_pointer always be a field offset within the value,
the value::embedded_offset will then be handled directly within the
various value::bits_synthetic_pointer implementations.
This commit is a small refactor in preparation for this fix.
I believe part of the confusion here is that we have functions that
take arguments called embedded_offset, when the value they should
accept is no longer the embedded offset.
So in this commit I propose renaming the embedded_offset argument to
field_byte_offset in valprint_check_validity. This is purely a
mechanical rename, there should be no user visible changes after this
commit.
The problem is that coerce_pieced_ref makes the following claim:
/* gdb represents synthetic pointers as pieced values with a single
piece. */
gdb_assert (closure != NULL);
gdb_assert (closure->pieces.size () == 1);
But this is not really true. If an aggregate type contains a synthetic
pointer, then it is possible that the aggregate type will have a
computed location consisting of multiple pieces. When GDB prints the
fields of that aggregate type these fields are extracted by calling
value::primitive_field. Within value::primitive_field the location of
the field is set by calling value::set_component_location.
When the parent value that holds the field has a computed location, the
field value gains a reference to the parent value's closure, this can be
seen in copy_pieced_value_closure in dwarf2/expr.c.
What this means is that, if the aggregate value has a multi-piece
computed location, then the synthetic pointer field will also have a
reference to that same multi-piece computed location, even if there is
really only a single piece that describes the synthetic pointer itself.
Some parts of GDB are already aware of this. If we look at
check_pieced_synthetic_pointer which implements the
value::bits_synthetic_pointer function, you'll see that this function
searches through all of the pieces to find the piece that covers the
value we are looking for, it then checks if that piece is an implicit
pointer location. But back in coerce_pieced_ref, after calling
value::bits_synthetic_pointer, we still make the assertion that there
will be just a single piece.
Fix this by copying the search through all pieces logic into
coerce_pieced_ref (see note on efficiency below). We now search through
all the pieces looking for a piece that describes the location of the
synthetic pointer, and we then use that piece to form the pointer's
value.
There are some assertions in the new code, these align with how
check_pieced_synthetic_pointer operates.
In addition, there is an error for the case where multiple pieces are
used to describe the location of a synthetic pointer. This case is
technically allowed by check_pieced_synthetic_pointer, but supporting
this would require changes to indirect_synthetic_pointer, so I propose
leaving that until we see such a case in the wild.
On efficiency, you'll notice that check_pieced_synthetic_pointer
performs a search through all the location pieces, and
coerce_pieced_ref also has to search through the pieces. It would be
nice if this could be avoided in order to avoid multiple searches.
Currently though coerce_pieced_ref calls
value->bits_synthetic_pointer, which is an API that should be agnostic
to the underlying implementation, i.e. shouldn't need to know that the
implementation is computed, so passing pieces back would be harder.
Maybe coerce_pieced_ref could avoid the value::bits_synthetic_pointer
call, and instead call check_pieced_synthetic_pointer directly, or
some related helper function, and could get the pieces back that way.
But this breaks the cleanly structured API that we currently have.
For now I'm leaving things as they are. My assumption is that the
number of pieces used to represent a value is pretty low, so the
search is actually pretty cheap.
There's a new test that uses the DWARF assembler to create a
representative example of a multi-piece aggregate that contains a
synthetic pointer member variable. This test triggers the assertion
before this commit.
Matthieu Longo [Mon, 30 Mar 2026 16:08:03 +0000 (17:08 +0100)]
gdb/python: work around missing symbols not yet part of Python limited API
Most Python API usages in GDB can be migrated to the limited API, except
the following:
- PEP-741's configuration structures and functions, which use opaque
types. They were originally intended to be part of the Python limited
API, but some Python core maintainers opposed their inclusion at the
time.
- PyOS_ReadlineFunctionPointer, a global variable storing a function
used to override PyOS_StdioReadline(). The signature has remained
unchanged for a long time.
- PyRun_InteractiveLoop, used to read and execute Python statements when
embedding an interactive interpreter. Its signature has also remained
stable for a long time.
Since no limited API alternatives exist for these, and given their long
history of ABI stability, one approach is to expose them in a GDB header
and rely on their continued stability. While this is not without risk,
it seems acceptable given the arguments above. This would remove the
remaining obstacles preventing GDB from being agnostic to the Python
version available at runtime.
That said, issues should be opened on CPython issue tracker to request
that these functions be included in the limited API in future versions.
Last but not least, GDB does not need to officially support the Python
limited API. The '--enable-py-limited-api' option can remain experimental,
with appropriate forewarnings about its limitations and guarantees.
This patch adds a new header, python-limited-api-missing.h, which
exposes symbols not yet part of the Python limited API.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
Matthieu Longo [Tue, 24 Mar 2026 13:29:01 +0000 (13:29 +0000)]
gdb/python: migrate Python initialization to use the new config API (PEP 741)
GDB currently initializes CPython using the PyConfig C API introduced in
Python 3.8 (PEP 597). From an ABI stability perspective, this API has a
major drawback: it exposes a plain structure whose fields may be added or
removed between Python versions. As a result, it was excluded from the
Python limited API.
Python 3.14 introduced a new configuration API (PEP 741) that avoids
exposing plain structures and instead, operates via opaque pointers.
This design makes it much more suitable for inclusion in the Python
limited API. Indeed, this was the original intent of the PEP-741 author.
However, CPython maintainers ultimately decided otherwise.
Since GDB aims at using the CPython stable API to avoid rebuilding for
each Python version, the absence of a configuration API in the limited
C API constitutes a blocker. Nevertheless, this can be worked around by
using PEP-741 configuration API, whose design is compatible with the
limited C API. It is relatively safe to assume that this API will stay
around for some time.
In this perspective, this patch adds support for using the PEP-741 config
API starting from Python 3.14. When Py_LIMITED_API is defined, the
required functions are exposed as external symbols via a workaround header.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
Jan Beulich [Fri, 15 May 2026 07:48:19 +0000 (09:48 +0200)]
RISC-V: make EFI app testcase consistent
Along the lines of what 43720b0cdd2a ("RISC-V: avoid ld crashes due to
bogus use by testcases") did, options passed to the assembler want to fit
those passed to the linker.
8 byte alignment is required for ldr relocation. Addresses are placed in IAT.
The size of the chunk on AArch64 is 8 bytes.
If IAT is not aligned to 8 bytes, the relocation issue appears.
This patch fixes this issue by aligning IAT to 8 bytes for PE32+.
binutils/ChangeLog:
* dlltool.c (make_head): Apply alignment to IAT.
(make_delay_head): Apply alignment to Delay IAT.
(main): Adjust 8 byte alignment for PE32+.
Jan Beulich [Fri, 15 May 2026 07:46:15 +0000 (09:46 +0200)]
RISC-V: improve .insn documentation
First of all, the "type" form of .insn does not permit (not even
optionally) a comma after the type, much like for ordinary insns a comma
is not permitted between insn mnemonic and first operand. The example
given actually properly shows that already.
While there, also update the .word related text: Mapping symbols have been
in use for quite some time.
Markus Metzger [Mon, 11 May 2026 08:53:21 +0000 (08:53 +0000)]
gdb: use all_threads() in for_each_thread()
In for_each_thread(), we use all_threads_safe(), which allows deleting the
thread. This it not needed in the cases where it is currently used and it
causes the iterator to get corrupted when threads are deleted in a nested
all_threads_safe() iteration.
One such scenario is as follows:
- remote debugging in non-stop mode
- one thread has hit a breakpoint
- one thread exited but GDB does not know about it, yet
- resume with 'continue -a'
- the continue command uses for_each_thread() to proceed threads individually
- the stopped thread starts an inline step-over (displaced stepping disabled)
- update_thread_list() learns about the exit and deletes the thread
- the safe iterator's m_next still points to the deleted thread
Alan Modra [Sun, 10 May 2026 23:51:27 +0000 (09:21 +0930)]
_bfd_elf_create_got_section .rela.got
_bfd_elf_create_got_section creates .rela.got or .rel.got before it
creates .got. This normally isn't a problem, but in some tests that
use a script to map uninteresting sections to a .junk section, if it
happens to be the first section so mapped then .junk becomes RELA
rather than the usual PROGBITS. Using a linker created dynobj makes
this more likely as the linker created bfd is put first on
link_info.input_bfds.
Alan Modra [Sun, 10 May 2026 23:50:52 +0000 (09:20 +0930)]
hppa64: get_opd in elf64_hppa_mark_exported_functions
late_size_sections is too late to be creating a dynamic section, as it
won't be mapped to an output section. So don't pretend that this will
do anything useful, and instead omit the traversal if opd_sec is NULL.
This bug showed up when using a linker-created dynobj.
* elf64-hppa.c (elf64_hppa_mark_exported_functions): Don't
attempt to create .opd here.
(elf64_hppa_late_size_sections): Only mark exported functions
for space in .opd if .opd exists.
(elf64_hppa_finalize_dynreloc): Make the test for a discared
other_rel_sec robust.
Alan Modra [Sun, 10 May 2026 23:50:29 +0000 (09:20 +0930)]
alpha: handle discarded got section
This fixes testsuite failures I noticed when changing dynobj to be
linker created, but I think the bug could be triggered by suitably
crafted linker scripts without any dynobj changes.
* elf64-alpha.c (elf64_alpha_final_link): Don't attempt to
write out a got section that has been discarded.
Alan Modra [Sun, 10 May 2026 23:48:29 +0000 (09:18 +0930)]
frv: elf32_frvfdpic_late_size_sections
This function runs passes over frvfdpic_relocs_info if dynobj is set,
which is OK since the two variables are both non-NULL or both NULL in
the current linker. That may change in the future, so test
frvfdpic_relocs_info directly rather than dynobj.
* elf32-frv.c (elf32_frvfdpic_late_size_sections): Omit dynobj
test. Instead test frvfdpic_relocs_info.
projects / thirdparty / binutils-gdb.git / log
