Tom Tromey [Thu, 22 Jan 2026 20:31:12 +0000 (13:31 -0700)]
Remove alloca from lookup_cmd
lookup_cmd uses alloca to make a copy of a string, just for an error
message. However, it's just as easy to use "%.*s" (already used once
in undef_cmd_error) and to pass in a string_view, avoiding the need
for an alloca and a copy.
Matthieu Longo [Tue, 27 Jan 2026 12:33:42 +0000 (12:33 +0000)]
gdb: make remaining Python extension objects inherit from PyObject
Previous patches made some Python extension objects ipublicly inherit
directly or indirectly from PyObject.
In the interest of consistency, this patch makes all remaining Python
extension objects still not inheriting from PyObject do so.
Matthieu Longo [Sat, 25 Oct 2025 22:55:29 +0000 (23:55 +0100)]
gdb: cast all Python extension objects passed to gdbpy_ref_policy to PyObject*
When enabling the Python limited API, pointers to Python C extension
objects can no longer be implicitly converted to 'PyObject *' by the
compiler.
gdbpy_ref_policy is a templated class that provides a generic interface
for incrementing and decrementing the reference counter on the given
object. It is used as a specialisation of the policy parameter in
gdb::ref_ptr, together with PyObject as the parameter type. As a result,
gdbpy_ref_policy always expects an argument derived from PyObject.
This patch fixes the resulting compilation issue by adding an explicit
static_cast to 'PyObject *' before passing the value to Py_INCREF and
Py_DECREF. As a side effect, these casts enforce, at compile time, that
the template type passed to gdbpy_ref_policy is a subclass of PyObject.
To provide a clearer diagnostic when an incorrect type is used, a
static_assert is added to gdbpy_ref_policy, avoiding obscure errors
originating from the static_cast. Finally, all C Python extension types
passed to gdbpy_ref_policy are updated to inherit from PyObject.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
Matthieu Longo [Thu, 17 Jul 2025 17:36:41 +0000 (18:36 +0100)]
gdb: new setters and getters for __dict__, and attributes
GDB is currently using the Python unlimited API. Migrating the codebase
to the Python limited API would have for benefit to make a GDB build
artifacts compatible with older and newer versions of Python that they
were built with.
This patch prepares the ground for migrating the existing C extension
types from static types to heap-allocated ones, by removing the
dependency on tp_dictoffset, which is unavailable when using the limited
API.
One of the most common incompatibilities in the current static type
declarations is the tp_dictoffset slot, which specifies the dictionary
offset within the instance structure. Historically, the unlimited
API has provided two approaches to supply a dictionary for __dict__:
* A managed dictionary.
Setting Py_TPFLAGS_MANAGED_DICT in tp_flags indicates that the
instances of the type have a __dict__ attribute, and that the
dictionary is managed by Python.
According to the Python documentation, this is the recommended approach.
However, this flag was introduced in 3.12, together with
PyObject_VisitManagedDict() and PyObject_ClearManagedDict(), neither
of which is part of the limited API (at least for now). As a result,
this recommended approach is not viable in the context of the limited
API.
* An instance dictionary, for which the offset in the instance is
provided via tp_dictoffset.
According to the Python documentation, this "tp slot" is on the
deprecation path, and Py_TPFLAGS_MANAGED_DICT should be used instead.
Given the age of the GDB codebase and the requirement to support older
Python versions (>= 3.4), no need to argue that today, the implementation
of __dict__ relies on tp_dictoffset. However, in the context of the
limited API, PyType_Slot does not provide a Py_tp_dictoffset member, so
another approach is needed to provide __dict__ to instances of C extension
types.
Given the constraints of the limited API, the proposed solution consists
in providing a dictionary through a common base class, gdbpy__dict__wrapper.
This helper class owns a dictionary member corresponding to __dict__, and
any C extension type requiring a __dict__ must inherit from it. Since
extension object must also be convertible to PyObject, this wrapper class
publicly inherits from PyObject as well.
Access to the dictionary is provided via a custom getter defined in a
PyGetSetDef, similarily to what was previously done with gdb_py_generic_dict().
Because __dict__ participates in attribute look-up, and since this dictionary
is neither managed by Python nor exposed via tp_dictoffset, custom
implementations of tp_getattro and tp_setattro are required to correctly
redirect attribute look-ups to the dictionary. These custom implementations
— equivalent to PyObject_GenericGetAttr() and PyObject_GenericSetAttr() —
must be installed via tp_getattro / tp_setattro for static types, or
Py_tp_getattro / Py_tp_setattro for heap-allocated types.
- gdbpy__dict__wrapper: a base class for C extension objects that own a
__dict__.
- gdb_py_generic_dict_getter: a __dict__ getter for extension types
derived from gdbpy__dict__wrapper.
- gdb_py_generic_getattro: equivalent of PyObject_GenericGetAttr, but
fixes the look-up of __dict__.
- gdb_py_generic_setattro: equivalent of PyObject_GenericSetAttr, but
fixes the look-up of __dict__.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
Matthieu Longo [Mon, 5 Jan 2026 11:14:28 +0000 (12:14 +0100)]
gdbpy_registry: cast C extension type object to PyObject * before Py_XINCREF
When enabling the Python limited API, pointers to Python C extension
objects can no longer be implicitly converted to 'PyObject *' by the
compiler.
The lookup() method of gbdpy_registry returns a new reference to the
type object of the looked-up entry. It does so by calling Py_XINCREF()
to increment the reference counter of the returned type object. The
template parameter obj_type corresponds to the type of C extension
object type. With the Python limited API enabled, obj_type can no longer
be implicitly converted to 'PyObject *' when passed to Py_XINCREF().
This patch fixes the resulting compilation issue by adding an explicit
static_cast to 'PyObject *' before passing the value to Py_XINCREF().
As a side effect, this cast enforces, at compile time, that the template
type 'Storage::obj_type' passed to gdbpy_registry is a subclass of
PyObject. To provide a clearer diagnostic when an incorrect type is used,
a static_assert is added to gdbpy_registry, avoiding obscure errors
originating from the static_cast. Finally, the relevant C extension types
passed to gdbpy_registry are updated to inherit publicly from PyObject.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
Alan Modra [Wed, 28 Jan 2026 21:49:44 +0000 (08:19 +1030)]
PR 33852 Different objects for same input
Testcase:
$ cat aff.s
.quad x@ntpoff
$ gas/as-new -m64 aff.s -o t.o
with MALLOC_PERTURB_ this reliably shows uninitialised memory making
its way into the output.
R_390_TLS_LE64 howto was sized incorrectly, resulting in the
initialisation in s390_elf_cons zeroing only the first four bytes.
* elf64-s390.c (elf_howto_table <R_390_TLS_LE64>): Correct
size and bitsize.
This patch replaces PyImport_ExtendInittab () with its limited C
API equivalent, PyImport_AppendInittab (), a convenience wrapper
around PyImport_ExtendInittab ().
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
Matthieu Longo [Tue, 6 Jan 2026 13:12:38 +0000 (13:12 +0000)]
Python limited API: migrate Py_CompileStringExFlags and PyRun_SimpleString
This patch replaces Py_CompileStringExFlags () with its limited C API
equivalent, Py_CompileString (). The eval_python_command () helper is
now exposed through the private GDB Python API as a utility function.
PyRun_SimpleString () is replaced with eval_python_command () to avoid
code duplication.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
Alan Modra [Wed, 28 Jan 2026 07:38:09 +0000 (18:08 +1030)]
gas: segmentation fault in as_report_context
After input_scrub_end when next_saved_file is NULL, it is possible
that macro_nest will be non-zero on files with errors. If
output_file_close then has an error and reports it with as_fatal we
hit the segfault.
Rainer Orth [Tue, 27 Jan 2026 17:26:59 +0000 (18:26 +0100)]
ld: testsuite: Simplify emulation check in libgot tests
The x86 libgot-1 tests are the only ones in all testsuites that use a
new ld -V -m<emul under test> idiom to check whether to run the tests.
Rather than open-coding the check everywhere while relying on that
idiom, this patch introduces a new proc to directly check the ld -V
output for the emulation in question.
Tested on {x86_64,i686}-pc-linux-gnu and {amd64,i386}-pc-solaris2.11.
Tom de Vries [Tue, 27 Jan 2026 09:40:06 +0000 (10:40 +0100)]
[bfd] Fix data race in bfd_check_format_matches
At the start of bfd_check_format_matches, we have this read of_bfd_section_id:
...
unsigned int initial_section_id = _bfd_section_id;
...
In order to access the variable, it is required to hold the global BFD lock.
The function already contains code acquiring the lock:
...
/* Locking is required here in order to manage _bfd_section_id. */
if (!bfd_lock ())
{
bfd_cache_set_uncloseable (abfd, old_in_format_matches, NULL);
free (matching_vector);
return false;
}
...
so fix this by moving the read after it.
Simon Marchi [Thu, 8 Jan 2026 19:51:54 +0000 (14:51 -0500)]
gdb/testsuite: remove guile "test byte at sp, before flush" test
When I run:
$ while make check TESTS="gdb.guile/scm-ports.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"; do done
I eventually get:
FAIL: gdb.guile/scm-ports.exp: buffered=1: test byte at sp, before flush
I don't know why I only see this (or see this more often) with the
native-extended-gdbserver board, I guess because it changes the timing
of things. Also, this is with a debug/ASan/UBSan build of GDB, if that
matters. This is with guile 3.0.
This is what the test attempts to do:
1. create a rw memory port that is supposed to be buffered
2. write the byte at $sp with a new value, expecting that byte to only
be in the port's buffer
3. read the memory at $sp (using parse-and-eval, bypassing the rw
memory port), expecting to see the old byte value
4. flush the memory port, expecting that to write to new byte value at
$sp
5. read the memory at $sp (using parse-and-eval again), expecting to
see the new value
It is step 3 that fails. My hypothesis is that even if the memory port
we write to is buffered, the write to the underlying memory can happen
before the "before flush" test happens. The Guile Buffering doc [1]
says this:
If you write data to a buffered port, it probably doesn’t go out to
the mutable store directly. (This “probably” introduces some
indeterminism in your program: what goes to the store, and when,
depends on how full the buffer is. It is something that the user
needs to explicitly be aware of.) The data is written to the store
later – when the buffer fills up due to another write, or when
force-output is called, or when close-port is called, or when the
program exits, or even when the garbage collector runs.
Because of the mention of the garbage collector, I tried putting some
calls to gc-disable and gc-enable around that area, but it doesn't fix
it.
Given that the flushing behavior of the buffered port seems
non-deterministic, I think that the buffering behavior can't easily be
tested. I propose to get rid of that specific aspect of the test.
As suggested by Tom de Vries, replace the "test byte at sp, before
flush" test with a "test byte at sp, before write" one. I think this is
useful as a sanity check to help prove that the memory write did in fact
change the state of the program.
Tom Tromey [Mon, 26 Jan 2026 17:54:08 +0000 (10:54 -0700)]
Minor cleanups in expanded-symbol.[ch]
I found a typo in expanded-symbol.h, then noticed some formatting
mistakes and some other incorrect comments. This patch fixes all
these and removes some 'struct' keywords as well.
This is not dap-specific, also with the CLI I see:
...
$ gdb -q -batch prog -ex "break prog.adb:22" -ex run -ex "info locals"
...
<W03a0> = 3
...
vs.:
...
<W03a0> = 3
<W03a6> = 7
...
Matthieu Longo [Thu, 23 Oct 2025 16:20:50 +0000 (17:20 +0100)]
gdb: add noexcept to relevant methods of class ref_ptr
This patch aims at improving code readability and maintainability
by adding the 'noexcept' attribute to some constructors and
methods of class 'ref_ptr' to make clear that no exception is
supposed to be raised from them.
As an additional benefit, the compiler doesn't need to generate
the stack unwinding code for those constructors and methods.
Matthieu Longo [Thu, 22 Jan 2026 18:53:34 +0000 (18:53 +0000)]
bfd/ELF: fix BFD library build --enable-shared
The patch series that added support for Object Attributes v2 introduced
regressions when building the BFD library as a shared object.
Incorrect usages of ATTRIBUTE_HIDDEN caused the following link-time errors:
/usr/bin/ld: config/obj-elf-attr.o: in function `obj_attr_v2_record':
obj-elf-attr.c: undefined reference to `bfd_elf_obj_attr_v2_init'
obj-elf-attr.c: undefined reference to `_bfd_obj_attr_v2_find_by_tag'
obj-elf-attr.c: undefined reference to `obj_attr_v2_t_append'
/usr/bin/ld: config/obj-elf-attr.o: in function `obj_attr_v2_subsection_record':
obj-elf-attr.c: undefined reference to `obj_attr_subsection_v2_t_append'
obj-elf-attr.c: undefined reference to `obj_attr_subsection_v2_t_remove'
obj-elf-attr.c: undefined reference to `obj_attr_subsection_v2_t_append'
This patch fixes the symbols visibility so that the BFD library links
correctly when built with --enable-shared.
The ATTRIBUTE_HIDDEN annotations were removed from bfd_elf_obj_attr_v2_init
and _bfd_obj_attr_v2_find_by_tag, and _bfd_obj_attr_v2_find_by_tag was renamed
to reflect the belonging to the public BFD API using the 'bfd_' prefix. The
doubly linked list helpers remain hidden and are instead exposed through wrapper
functions.
Than McIntosh [Sun, 25 Jan 2026 14:19:10 +0000 (14:19 +0000)]
PR 33835 readelf incorrect handling of DWARF5 CU DIE addr_base attribute
Users of "readelf" report problems running the tool's DWARF dump flag
on binaries built with the most recent version of the Go compiler (1.25),
Go bug report here https://github.com/golang/go/issues/77246
Indu Bhagat [Thu, 22 Jan 2026 08:00:36 +0000 (10:00 +0200)]
ld: sframe: do not generate .sframe for PLT if no .sframe is in input BFDs
GNU ld creates SFrame stack trace info for the PLT. For x86 the linker-
created .sframe section is created in setup_gnu_properties. For s390 it
is created in create_dynamic_sections. For both, the section data is
itself emitted a bit later in late_size_sections. Note that for aarch64 the
linker does not create .sframe for PLT yet.
Recall that a previous patch 832ca9ef670 uncoupled
--no-ld-generated-unwind-info from the linker-generated .sframe
sections. This means that the linker now generates .sframe section (for
.plt*) for the first input BFD enthusiatically even when none of the
input BFDs have any .sframe section, unless --discard-sframe is also
added. The issue is that these (unexpected) linker-generated .sframe
sections (on x86_64, and s390) may now trip the linking process, e.g.,
when using --orphan-handling=error together with a linker script that
treats .sframe differently than the default linker script.
https://sourceware.org/pipermail/binutils/2026-January/147826.html
Further, with SFrame sections to be soon marked KEEP for fixing
GC/SFrame (PR ld/32769), the presence of these linker generated SFrame
sections will also cause emission of an empty .sframe (for x86_64 and
s390x), even when all input bfd's have no .sframe section.
This patch avoids creation of .sframe for .plt* if none of the input
BFDs had any .sframe section. This then avoids creation of empty
.sframe in linked objects on x86_64 and s390x, when none of the inputs
have SFrame sections. This also fixes PR ld/33830.
For the code changes: Reviewed-by: Jens Remus <jremus@linux.ibm.com>
New testcases have (since the above Reviewed-by) been added. Since
--no-ld-generated-unwind-info is not supported on aarch64, add
target-specific ld tests. Additionally add a generic test (for all
targets that support SFrame) to ensure no output .sframe is generated if
users says no --gsframe or similar.
bfd/
PR ld/33830
* elf-bfd.h (_bfd_elf_sframe_present_input_bfds): New
declaration.
* elf-sframe.c (_bfd_elf_sframe_present_input_bfds): New
definition.
* elf64-s390.c (elf_s390_create_dynamic_sections): Do not
generate .sframe for .plt unconditionally.
* elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties):
Likewise.
ld/testsuite/
PR ld/33830
* ld-s390/no-sframe.ld: Linker script with no specification for
SFrame sections.
* ld-s390/s390.exp: Add new test.
* ld-s390/sframe-command-line-2.d: New testcase that uses
--no-ld-generated-unwind-info and a linker script that has no
specific rules for .sframe.
* ld-x86-64/no-sframe.ld: Likewise for x86_64.
* ld-x86-64/sframe-command-line-2.d: Likewise for x86_64.
* ld-x86-64/x86-64.exp: Add new test.
* ld-sframe/no-ld-generated-sframe.d: Ensure no .sframe in
output if no .sframe in input.
* ld-sframe/no-sframe.ld: Linker script with no specification
for SFrame sections.
* ld-sframe/test.s: Add new test.
aarch64: TLBI Domains changes for PLBI instruction
For the PLBI instruction with optional register argument
<Rt> == 0b1111, with FEAT_TLBID enabled they are permitted to
have an Rt value which is not 0b11111 and this is allowed for
all the TLBI instructions with a <type> of ALLE1*, ALLE2* and
VMALL* and a <shareability> of IS or OS.
aarch64: Enable TLBIP instructions with tlbid option
TLBI Domains feature changes TLBI and TLBIP system instructions.
For all TLBIP *E1IS*, TLBIP *E1OS*, TLBIP *E2IS* and TLBIP *E2OS*
instructions that are currently dependent on FEAT_D128 (+d128),
will also be available with FEAT_TLBID (+tlbid).
TLBI Domains feature changes TLBI and TLBIP system instructions.
For the TLBI instruction with optional register argument
<Rt> == 0b1111, with FEAT_TLBID enabled they are permitted to
have an Rt value which is not 0b11111 and this is allowed for
all the TLBI instructions with a <type> of ALLE1*, ALLE2*,
VMALL*, VMALLS12* or VMALLWS2* and a <shareability> of IS or OS.
This patch add support for FEAT_TLBID feature, which is enabled
by new +tlbid option.
While ld-i386/libgot-1.rd already allows for differences in the
addresses, the addend is assumed to be fixed. However, this is not the
case with -melf_i386_sol2. The difference is that .hash, .dynsym, and
.symtab have additional entries as required by the Solaris ABI:
* In .dynsym and .symtab, _DYNAMIC, _GLOBAL_OFFSET_TABLE_, and
_PROCEDURE_LINKAGE_TABLE_ are added.
* .symtab also gains _END_ and _START_.
This explains the differences in addresses and addends, but they are
completely benign.
This patch thus allows for arbitrary addends.
Tested on {i386,amd64}-pc-solaris2.11 with both -melf_i386_sol2 and
-melf_i386, and {i686,x86_64}-pc-linux-gnu.
Rainer Orth [Sat, 24 Jan 2026 07:02:14 +0000 (08:02 +0100)]
ld: testsuite: Skip pr33577 tests with GNU extensions on Solaris [PR33577]
Several of the ld-elfvers pr33577 tests FAIL on Solaris, for either or
both of two reasons:
* Tests using ld --hash-style=gnu cannot work on Solaris:
.gnu.hash/SHT_GNU_HASH sections are a GNU extension not supported by
Solaris ld.so.1.
* Similarly, binding different implementations of the same symbol to
different symbol versions is a GNU extension that wasn't in the
original Solaris specification of symbol versioning. ld.so.1 doesn't
support it and never will.
This can be seen in the elfdump output for the .dynsym section:
Symbol Table Section: .dynsym
index value size type bind oth ver shndx name
[8] 0x630 0xd FUNC GLOB D 1H .text foo
[10] 0x620 0x6 FUNC GLOB D 2 .text foo
foo is bound to both version 1 (the Base version) and version 2 (VERS_1
from pr33577.map).
Same for .symtab:
Symbol Table Section: .symtab
index value size type bind oth ver shndx name
[28] 0x620 0x6 FUNC GLOB D 0 .text foo
[35] 0x630 0xd FUNC GLOB D 0 .text foo@
As I said, ld.so.1 doesn't support <symbol>@<version> (in this case the
Base version) at all.
Therefore the tests that employ those extensions are guarded with
supports_gnu_osabi.
Tested on sparc{,v9}-sun-solaris2.11, sparc{,64}-unknown-linux-gnu,
{i386,amd64}-pc-solaris2.11, and {x86_64,i686}-pc-linux-gnu.
ld:
PR ld/33577
* testsuite/ld-elfvers/vers.exp (base_symbol_test): Only run
pr33577a with libpr33577-versioned.so test on ELFOSABI_GNU
systems.
Likewise for run base_symbol_tests with --hash-style=gnu.
ld: Make separate clauses where a label was before a declaration
The default behavior of gcc changed from gcc-11. With gcc-10 and
earlier versions, you got:
In file included from ../bfd/bfd.h:45,
from /src/ld/ldmisc.c:23:
/src/ld/ldmisc.c: In function 'vfinfo':
/src/ld/ldmisc.c:186:8: error: a label can only be part of a statement and a declaration is not a statement
186 | bool ll_type = false;
| ^~~~
/src/ld/ldmisc.c:581:8: error: a label can only be part of a statement and a declaration is not a statement
581 | bool ll_type = false;
| ^~~~
make[4]: *** [Makefile:1606: ldmisc.o] Error 1
Since gcc-10 matches the binutils/README requirement ("a C99 compliant
compiler and library") and as binutils policy is to adjust code to
handle earlier gcc versions, an obvious fix is to make a compound
statement for the code after the case-label.
ld:
* ldmisc.c (vfinfo) <case 'l' - two cases>: Make separate
compound statements where case-labels were part of a declaration.
H.J. Lu [Thu, 15 Jan 2026 01:11:50 +0000 (09:11 +0800)]
elf: Set has_local_dynsyms for forced local symbol
bfd_elf_link_record_dynamic_symbol may be called by mips backend after
a global symbol has been forced to local. Set has_local_dynsyms to true
in this case.
bfd/
PR ld/33793
* elflink.c (bfd_elf_link_record_dynamic_symbol): Set
has_local_dynsyms to true for forced local symbol.
ld/
PR ld/33793
* testsuite/ld-mips-elf/mips-elf.exp: Run pr33793.
* testsuite/ld-mips-elf/pr33793.d: New file.
* testsuite/ld-mips-elf/pr33793.s: Likewise.
Michal Sobon [Fri, 23 Jan 2026 13:38:28 +0000 (14:38 +0100)]
opcodes: Fix branch displacement mask in M*Core disassembler
The BT, BF, BR, and BSR instructions use the Scaled 11-Bit Displacement
addressing mode. According to the Motorola M*Core Reference Manual,
the instruction format has:
- bits 15-11: opcode
- bits 10-0: 11-bit signed displacement field
The displacement calculation is: PC <- PC + 2 + (sign-extended disp11 << 1)
The disassembler was incorrectly masking with 0x3FF (10 bits) instead of
0x7FF (11 bits). This masked off bit 10, which is the sign bit for the
11-bit signed displacement. As a result, negative (backward) branches
were incorrectly disassembled as forward branches.
opcodes/
* mcore-dis.c (print_insn_mcore): Fix displacement mask from
0x3FF to 0x7FF in BR case to correctly extract all 11 bits
including the sign bit.
Indu Bhagat [Fri, 23 Jan 2026 22:21:56 +0000 (14:21 -0800)]
libsframe: rename sframe_fre_* internal APIs to use data word instead of offset
Rename three internal functions:
- sframe_fre_get_offset_count to sframe_fre_get_dataword_count
- sframe_fre_get_offset_size to sframe_fre_get_dataword_size
- sframe_fre_offset_bytes_size to sframe_fre_datawords_bytes_size.
libsframe/
* sframe.c: Rename functions and variables.
Indu Bhagat [Fri, 23 Jan 2026 22:21:15 +0000 (14:21 -0800)]
libsframe: rename offset in user-facing sframe_frame_row_entry struct
This patch is the first patch to align libsframe with the terminology
change of moving from 'offset' to 'data word'. With the introduction of
flexible FDE type SFRAME_FDE_TYPE_FLEX, the variable-length data
following an SFrame FRE header can now represent signed offsets or
unsigned control data. Consequently, 'data word' is adopted as the more
generic term.
This change updates the names used in the user-facing
sframe_frame_row_entry structure. While some API function names remain
unchanged to preserve existing contracts, the underlying data buffers
and size macros now reflect the data word' terminology.
libsframe is a tricky spot for such a terminology change: some of APIs
are still used to read (may be followed by endian swap) for dumping
SFrame V2 sections in textual format. Some classic examples are
sframe_decode_fre, and flip_fre (both are static functions). But moving
forward, using the term 'data word' for such APIs and their internal too
may be better. Subsequent commits will achieve just that.
include/
* sframe-api.h (MAX_NUM_DATAWORDS): Rename from
MAX_NUM_STACK_OFFSETS.
(MAX_DATAWORD_BYTES): Rename from MAX_OFFSET_BYTES.
(struct sframe_frame_row_entry): Rename fre_offsets to
fre_datawords.
libsframe/
* sframe.c (sframe_fre_sanity_check_p): Use MAX_NUM_DATAWORDS.
(sframe_get_fre_offset): Update internal pointers to use
'offsets' and access fre_datawords.
(sframe_get_fre_udata): Rename local variables to
dataword_cnt/dataword_size and update to use
SFRAME_FRE_DATAWORD_* constants.
(sframe_decode_fre): Use fre_datawords and MAX_DATAWORD_BYTES.
(sframe_encoder_add_fre): Use fre_datawords.
(sframe_encoder_write_fre): Use fre_datawords.
Indu Bhagat [Fri, 23 Jan 2026 22:20:54 +0000 (14:20 -0800)]
include: gas: sframe: fix terminology from offset to data word
In SFrame V3, with the addition of flexible FDE type, the
variable-length array of bytes trailing the SFrame FRE header are no
longer exclusively interpreted as signed offsets. This data can now
include unsigned control data, unsigned padding word data or signed
offset data. Consequently, using the term "offsets" to describe this
trailing data is inaccurate and can be confusing.
This patch switches the terminology to 'Data Word' across the assembler
and the SFrame header file. Note that, the term 'Word' is used
colloquially here, the actual size (1, 2, or 4 bytes) remains determined
by the applicable bits in the FRE info byte.
gas/
* gen-sframe.c: Rename SFrame FRE 'offset' to 'data word'.
include/
* sframe.h (SFRAME_FRE_DATAWORD_1B, SFRAME_FRE_DATAWORD_2B,
SFRAME_FRE_DATAWORD_4B): New constants.
(struct sframe_fre_info): Update bitfield documentation.
(SFRAME_V3_FRE_DATAWORD_COUNT): New macro.
(SFRAME_V3_FRE_DATAWORD_SIZE): New macro.
Tom Tromey [Sun, 23 Apr 2023 15:58:14 +0000 (09:58 -0600)]
Simplify cp_print_class_member
I noticed that cp_print_class_member's calling convention can be
simplified. In particular it seems cleaner for it to simply take a
value and a stream; and the "prefix" argument is only ever set to one
value.
This version also renames the function, to indicate a bit more clearly
what it actually does.
Hannes Domani [Fri, 23 Jan 2026 19:07:04 +0000 (20:07 +0100)]
Add aarch64-windows support
This makes most debugging work, except unwinding doesn't always work
from inside dlls where no debug info is available, because SEH unwinding
is not implemented.
The number of available hardware breakpoints is taken from
ID_AA64DFR0_EL1 (registry key "CP 4028").
As for hardware watchpoints, even though ARM64_MAX_WATCHPOINTS is 2,
testing showed that only 1 ever works, so it's fixed to that value.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Hannes Domani [Fri, 23 Jan 2026 19:07:04 +0000 (20:07 +0100)]
Create x86-windows-nat.c
Also creates the x86_windows_per_inferior and x86_windows_nat_target
derived classes in there which will then hold the arch-specific data and
function overrides.
Hannes Domani [Fri, 23 Jan 2026 19:07:04 +0000 (20:07 +0100)]
Move struct declarations into windows-nat.h
This is done as preparation for aarch64-windows-nat, since both x86 and
aarch64 will use them as base (after the x86 parts are split off into
x86-windows-nat).
Hannes Domani [Fri, 23 Jan 2026 19:07:04 +0000 (20:07 +0100)]
Remove duplicate code from windows_nat_target::resume
Updating the debug registers and calling SetThreadContext is already
done in windows_continue, called directly afterwards, so this removes it
from windows_nat_target::resume.
Tom Tromey [Sat, 22 Nov 2025 18:03:57 +0000 (11:03 -0700)]
Some cleanups to "pretend language" handling
I noticed that the "pretend language" handling in the DWARF reader
doesn't work as intended; the problem code in dwarf2_per_cu::set_lang
is:
if (unit_type () == DW_UT_partial)
return;
The issue here is that this subverts the very purpose of having a
"pretend" language.
Some background: when Jakub wrote dwz, we also added support for this
style of DWARF compression to gdb. Now, dwz only shares DIEs in a
"top level" way -- i.e., at the time (and as far as I know, continuing
to today), it would not emit a DW_TAG_imported_unit inside a
namespace. So, when implementing this we also implemented an
optimization, namely that gdb would not re-read every imported unit a
la '#include', but instead would make symtabs for each included unit
(partial units didn't yet exist).
However, an imported/partial unit might not have a language -- but a
language is necessary for interpreting the DIEs. This is where the
"pretend" language comes from. When reading a CU, any included
partial units that do not have a language of their own will inherit
that CU's language.
This patch started by removing the DW_UT_partial check. This of
course caused assertion failures in some modes, as set_lang also
asserts that the language cannot change. But, it's possible for a CU
to be prepared multiple times, and for different invocations to
provide different languages.
This is not a scenario we allowed for in the early days. Nowadays,
though, it seems to me that it's basically fine in practice, with the
reason being that sharing DIEs that differ semantically but not
syntactically across different languages is hard to achieve.
We do see this some cross-language sharing in a limited way -- "dwz
-5" will emit inclusions from both C and C++ CUs for the
gdb.fortran/mixed-lang-stack.exp test -- but note that this sharing is
limited to things that are common between C and C++, like "float".
Therefore this patch replaces the assertions in set_lang with some
compare-exchanges.
Finally I changed cutu_reader to use a std::optional for the pretend
language. I think this makes it more clear what is happening. And,
while doing this I found a spot in the cooked indexer where
language_minimal was passed in, but where the importing CU's language
should have been used.
I regression tested this on x86-64 Fedora 40 using the default board,
plus the cc-with-gdb-index, cc-with-debug-names, and cc-with-dwz-5
boards.
Andrew Burgess [Thu, 22 Jan 2026 14:09:37 +0000 (14:09 +0000)]
gdb/tui: return std::string from tui_get_function_from_frame
Update tui_get_function_from_frame to return a std::string rather than
a pointer into a static buffer.
The value returned from tui_get_function_from_frame is passed to
tui_location_tracker::set_location, which already stores the data in a
std::string; this just moves the string creation earlier.
I don't think there was anything particularly wrong with the old code,
but I'm not a huge fan of returning data in static buffers unless
there's a really good reason, and it doesn't feel like there's a
really good reason in this case.
The current approach in tui_get_function_from_frame is to call
print_address_symbolic, and then to pull the function name from the
result. There is an argument that this approach could be improved,
but I've not done that in this commit, nor do I plan to do that any
time soon. As such the new code should do exactly what the old code
did.
There should be no user visible changes after this commit.
Matthieu Longo [Thu, 22 Jan 2026 17:34:39 +0000 (17:34 +0000)]
ld: bring vfinfo() in parity with printf() for format specifiers ll[d|i|x]
vfinfo() does not currently support the double-'l' ('ll') length
modifier for 'd', 'u', and 'x' conversion specifiers. This caused
incorrect behavior when using PRI[d|u|x][32|64] on some platforms,
and is error-prone for developers who reasonably expect
printf-compatible semantics.
This patch adds support for ll[d|u|x] to align vfinfo() with printf()
and improve portability and robustness.
projects / thirdparty / binutils-gdb.git / log
