Alan Modra [Thu, 22 Jan 2026 02:37:51 +0000 (13:07 +1030)]
libgot-1 testcases
There is no need for multiple tests of readelf --got-contents,
nor should the matching be so strict that changes in section layout
force editing of the testsuite.
It also looks to me that the i386 --got-contents output is wrong,
at least it is confusing to have .rel.plt show 0020020c00000307 R_386_JUMP_SLOT 00000000 bar
while the corresponding got-contents dump shows "bar + 156".
3: 0020020c R_386_JUMP_SLOT bar + 156
Andrew Burgess [Mon, 12 Jan 2026 10:44:35 +0000 (10:44 +0000)]
gdb: fix 'info frame' for tail calls with no debug information
If the inferior stack contains a tail call function. And if the CU
containing the tail call function doesn't have any debug information.
And if the user uses 'info frame' to examine the tail call frame, then
GDB will report the wrong function name, for example:
Breakpoint 1, 0x000000000040110a in callee ()
(gdb) bt
#0 0x000000000040110a in callee ()
#1 0x0000000000401116 in caller ()
#2 0x0000000000401140 in main ()
(gdb) up
#1 0x0000000000401116 in caller ()
(gdb) frame
#1 0x0000000000401116 in caller ()
(gdb) info frame
Stack level 1, frame at 0x7fffffffa440:
rip = 0x401116 in dummy_func; saved rip = 0x401140
called by frame at 0x7fffffffa450, caller of frame at 0x7fffffffa430
Arglist at 0x7fffffffa430, args:
Locals at 0x7fffffffa430, Previous frame's sp is 0x7fffffffa440
Saved registers:
rbp at 0x7fffffffa430, rip at 0x7fffffffa438
(gdb)
Notice that 'info frame' claims that the current frame is 'dummy_func'
rather than 'caller', as the 'backtrace', 'up', and 'frame' commands
claim.
This is because 'backtrace', 'up', and 'frame' all uses print_frame to
print the frame details, which in turn uses find_frame_funname to get
the frame's function name.
In contrast, 'info_frame_command_core' contains an inlined copy of
'find_frame_funname' with one key difference. The code in
info_frame_command_core uses get_frame_pc_if_available while
find_frame_funname uses get_frame_address_in_block_if_available. The
latter function returns '$pc - 1' if the frame in question could be a
tail call function, while get_frame_pc_if_available always returns
$pc. This difference means that, for a tail call function, GDB will
lookup the wrong msymbol.
Fix this by updating info_frame_command_core to use
find_frame_funname. We end up still keeping the call to
get_frame_pc_if_available as 'info frame' still needs to print this
address. There should be no other noticeable changes after this
commit.
There's also a test in which I have tried to create a tail call
function in a (relatively) target agnostic way. I compile a test
program, pull some addresses from it, then recompile the test to
assembly, and augment the assembler output, changing one symbol size,
and adding an entirely new function symbol. The modified assembly
file is then compiled, without debug information, to create the actual
test executable. This gives GDB the impression that the test contains
a tail call function.
Matthieu Longo [Thu, 10 Apr 2025 15:11:02 +0000 (16:11 +0100)]
gnu directives: bfd: generic tests for merge of gnu attributes v2
These tests are a copy-paste of the generic tests for AArch64.
Test cases:
- only one input object is copied to the output object
- merge two inputs with optional subsections of both types
ULEB128 and NTBS, which contains same, additional, and
missing attributes.
- mismatch subsection properties.
- combine matching required subsections.
- combine non-matching required subsections.
- prune unknown attributes in known subsections.
- prune unknown subsections.
Matthieu Longo [Thu, 10 Apr 2025 14:16:31 +0000 (15:16 +0100)]
gnu directives: gas/readelf tests for gnu attributes v2
These tests are a copy-paste of the generic parsing tests for AArch64.
The added tests cover the parsing of the new assembly directives
(gnu_subsection and gnu_attribute), the serialization of the
Object Attributes v2 (OAv2) data into an object file, and the
dumping of those data via readelf.
The parsing tests focus on the following points:
- the syntax of the new directives.
- the recognition of generic tokens like: NTBS, ULEB128, required,
optional.
The dumping tests focus on:
- the OAv2 population into the correct section assigned by the backend.
- the merge of the subsections and attributes when they are declared
several times inside respectively the same compilation unit, and
subsection.
- the sorting of OAv2 before the serialization.
Matthieu Longo [Thu, 17 Apr 2025 17:02:38 +0000 (18:02 +0100)]
gnu directives: add support for .gnu_attribute and .gnu_subsection in OAv2 context
This patch adds support for the GNU directives .gnu_attribute and
.gnu_subsection, used respectively for OAv1 and OAv2, and for OAv2
only. These directives behave like their AEABI counterparts, as
they are aliases intended for use by any backends supporting OAv1
and/or OAv2. Their availability is controlled by the TC_OBJ_ATTR_v1
and TC_OBJ_ATTR_v2 macros.
Previously, the "gnu_" subsection namespace was used only for
"gnu_testing_" and defaulted to a private scope. This patch updates
the scope recognition to correctly distinguish between private usage
(e.g., testing) and public usage (e.g., actual GNU subsections
storing public information).
Matthieu Longo [Tue, 25 Feb 2025 17:28:03 +0000 (17:28 +0000)]
ld tests for AArch64-specific merge coverage for AEABI Build Attributes
Test cases:
- coverage of required subsection 'aeabi_pauthabi'.
- coverage for BTI, PAC, GCS used along GNU properties.
- warn on unknown attributes, and prune them from output.
Matthieu Longo [Thu, 17 Apr 2025 09:23:08 +0000 (10:23 +0100)]
aarch64: merge of Object Attributes v2 during linkage
This patch adds support to AArch64 backend to process AEABI Build
Attributes and raise any compatibility issue.
AArch64 backend declares 2 vendor subsections, and their associated tags:
- aeabi_feature_and_bits: contains tags that describe the same optional
bits as the GNU_PROPERTY_AARCH64_FEATURE_1_AND. For now, the following
attributes are recognized:
- Tag_Feature_BTI: means that all the executable sections are
compatible with Branch Target Identification (BTI) mechanism.
- Tag_Feature_PAC: means that all the executable sections have been
protected with Return Address Signing.
- Tag_Feature_GCS: means that all the executable sections are
compatible with the Guarded Control Stack (GCS) extension.
- aeabi_pauthabi: contains information about the Pointer Authentication
Signing schema when the object uses an extension to ELF, PAUTHABI64,
which is currently not supported by GCC toolchain. The pointers that
are signed as well as the modifiers and key used for each type of
pointer are known as the signing schema. The support of this
subsection is there for completeness with the AEABI Build Attributes
document, and allows readelf to dump the data nicely, and the linker
to detect a use of a signing schema, and error.
- Tag_PAuth_Paltform: the platform vendor id.
- Tag_PAuth_Schema: the version numner of the schema.
For backward-compatibilty purpose, AArch64 backend translates
GNU_PROPERTY_AARCH64_FEATURE_1_AND in input files to its OAv2 equivalents.
The frozen set of OAv2 is populated with values derived from command-line
options for BTI (-z force-bti) and GCS (-z gcs=*).
It also reports incompatibilities for BTI and GCS, and set BTI PLT type
depending on the OAv2 merge result.
Regarding incompatibilities, only the ones detected in objects constituting
the output link unit will be reported. Supports for detecting incompatibilities
in shared objects might be a future work to bring it in pair with the GNU
properties merge. However, since OAv2 are translated to GNU properties,
detection will still happen so this feature seems redundant and of little
value given the backward compatibility support for GNU properties is
required (see next paragraph).
Finally, it translates OAv2s in subsection "aeabi_feature_and_bits" to
GNU_PROPERTY_AARCH64_FEATURE_1_AND as GNU properties are required for
the dynamic linker (it does not understand OAv2s yet).
Matthieu Longo [Tue, 25 Feb 2025 17:26:57 +0000 (17:26 +0000)]
ld tests for generic merge coverage of Object Attributes v2
Test cases:
- only one input object is copied to the output object
- merge two inputs with optional subsections of both types
ULEB128 and NTBS, which contains same, additional, and
missing attributes.
- mismatch subsection properties.
- combine matching required subsections.
- combine non-matching required subsections.
- prune unknown attributes in known subsections.
- prune unknown subsections.
Matthieu Longo [Wed, 12 Nov 2025 16:05:07 +0000 (16:05 +0000)]
OAv2 merge: translate GNU properties to Object Attributes v2 (and vice versa)
Some input objects may contain inconsistencies, i.e. they might include
GNU properties but lack the corresponding object attributes, or inversely.
The later case is never produced by Gas, but the former can occur with
older Gas versions that do not support object attributes.
To keep consistency during the merge process, each input object's GNU
properties are translated into their object attributes equivalents (if
they exists). Also, after object attributes have been merged at the file
scope, they are translated back to GNU properties to keep the GNU
properties merge process consistent. This final translation occurs before
merging the input with the global merge accumulator (a.k.a. REF) and the
global configuration (a.k.a FROZEN).
Note: the first parameter of translate_obj_attrs_to_gnu_props(), bfd *,
should be 'const', but this implies that _bfd_elf_get_property() should
also be constified, and this is out of scope.
Matthieu Longo [Fri, 14 Nov 2025 10:31:29 +0000 (10:31 +0000)]
OAv2 merge: prune unsupported or invalid subsections and attributes
During the merge, each subsection and attribute is assigned a status.
If the status is OK, the item is retained and serialized into the
output object. Otherwise, unsupported or invalid subsections and
attributes are pruned before serialization.
When a subsection or attribute is pruned, ld emits information-level
messages to inform the user, preventing confusion about the absence
of elements that were present in the input objects.
Matthieu Longo [Fri, 14 Nov 2025 12:04:32 +0000 (12:04 +0000)]
OAv2 merge: merging Object Attributes
The Object Ottributes merge process must handle both optional and
required subsections. It also treats the first merge of the frozen set
specially, as the OAv2 list in the input BFD serves as the accumulator
for subsequent merges.
** Optional subsections
Optional subsections are processed as if merging two ordered sets — by
iterating linearly through both, checking whether an element of a given
ordinality is present in the opposite set, and adding it to the
accumulator. The added diffuculty with subsections and attributes lies
in the fact that missing elements have default values, and these must be
merged with existing ones to produce the final value to be stored.
** Required subsections
Required subsections are processed slightly differently from the
optional subsections, as they cannot be pruned since they are mandatory,
hence an error will be raised by the linker if it is not recognized.
For now, the subsection for PAuth ABI is the only one use case, and
no merge is applied on the values. The values simply need to match.
This implementation choice might be challenged in the future if required
subsections can have the same diversity as optional subsections. If the
case arises, the refactoring to handle this new behavior should consist
in adding a new merge policy MERGE-EQUAL, or something similar. Some "if
required" should be added in the optional subsections merge logic to
error on any missing elements, or mismatch, and messages should also be
rephrased to point out that the error is for a required subsection.
** Important note regarding support for testing
In order to test this generic logic, AArch64's use cases are not
offering enough coverage, so a "GNU testing namespace" which corresponds
to the name of the subsection was introduced. It follows the following
pattern:
gnu_testing_<XXXXXX>_MERGE_<POLICY>
with:
- <XXXXXX>: an arbitrary name for your testing subsection.
- <POLICY>: the name of the merging policy to apply on the values in
the subsection. The currently supported merge policy are:
* _MERGE_AND: bitwise AND applied on numerical values.
* _MERGE_OR: bitwise OR applied on numerical values.
* _MERGE_ADD: concatenates strings together with a '+' in-between.
Note: "_MERGE_ADD" does not make really sense, and will very likely
never be used for a real merge. Its only purpose is to test the
correct handling of merges with strings.
Any subsection name matching neither names supported by the backend, nor
following the pattern corresponding GNU testing namespace will be considered
unknown and its status set to obj_attr_subsection_v2_unknown. This will
have for consequence the pruning of this subsection.
Additionally, the first two tags in gnu_testing namespace, GNUTestTag_0
and GNUTestTag_1, are known, and so have a name and can be initialized
to the default value ('0' or NULL) depending on the encoding specified
on the subsection. Any tags above 1 will be considered unknown, so will
be default-initialized in the same way but its status will be set to
obj_attr_v2_unknown. This behavior of the testing tags allows to test
the pruning of unknown attributes.
Matthieu Longo [Fri, 14 Nov 2025 19:34:25 +0000 (19:34 +0000)]
OAv2 merge: mark unknown subsections
In Object Attributes v2, the merge policy is not encoded within the
subsection definition. It is therefore up to the linker to determine
the appropriate policy based on the subsection's name and properties.
Unless a subsection is explicitly recognized by the linker, the
spefication of OAv2 provides no means to infer its merge policy.
Furthermore, in theory, this merge policy could vary between
attributes within the same subsection.
As a result, before beginning the merge process, ld inspects each
subsections, and attempts to identify them as either a GNU subsection,
or a backend-specific one. If this identification fails, the status
of the subsection is set to 'UNKNOWN'. Subsections marked as unknown
are then skipped during the merge process, and later pruned from the
output before the serialization.
Matthieu Longo [Fri, 14 Nov 2025 18:41:32 +0000 (18:41 +0000)]
OAv2 merge: merge subsections and tags at file scope
Before merging input object files together, each input's object
attributes must be sanitized to ensure that duplicate subsections and
attributes are merged and properly sorted. Indeed, uniqueness and
ordering of subsections and attributes are required prerequisites for
the merge process.
This operation also handles, on a best-effort basis, exotic objects
produced by non-GNU assemblers, where duplicate subsections may appear
across different sections, and similarly, duplicate attributes across
subsections.
It is importand to note that such cases are not covered by the Object
Attributes specification, and the resulting behavior is implementation
-defined. Other linkers may handle these inputs differently.
Matthieu Longo [Fri, 14 Nov 2025 18:44:46 +0000 (18:44 +0000)]
OAv2 merge: create a section for object attributes
bfd copies object attributes to the output BFD only if the input BFD —
used to store the merge result— contains an object attribute section.
bfd_linear_find_first_with_obj_attrs() returns an input BFD that may or
may not already include such a section. If no object attributes section
is found, the merge process must create one.
This patch implements create_object_attributes_section(), which constructs
the missing section with the appropriate flags, type, and alignment. The
implementation is adapted from _bfd_elf_link_create_gnu_property_sec() in
bfd/elf-properties.c. The code preserves the different alignment
requirements for 32-bit and 64-bit ELF formats, although the rationale for
this distinction remains unclear in the original source and patch history.
Matthieu Longo [Fri, 14 Nov 2025 15:36:44 +0000 (15:36 +0000)]
OAv2 merge: find first input containing an object attributes section
During the merge process, the linker first scans the list of input files
to identify ELF object files that contain object attributes. If no such
object file is found, the merge process terminates. Otherwise, the first
matching file is used as the placeholder for the global merge result.
This patch implements a linear search to locate the first input BFD
containing an Object Attributes section, while recording a good candidate
otherwise.
It is worth noting that the position of the object file in the list, as
well as whether it contains object attributes or not, or whether it
contains an object attributes section or not, are not significant. Any
input ELF object files could serve this placeholder purpose if the merge
process was performed in parallel.
Matthieu Longo [Sun, 13 Apr 2025 00:51:55 +0000 (01:51 +0100)]
OAv2 merge: plumbing of generic merge logic during linkage
This patch adds the plumbing for the OAv2 generic merge logic in the
linker. The linker is an "advanced" consumer of OAv2. After parsing,
it deduplicates the attributes, merges them, detects any compatibility
issues, and finally translates them to GNU properties.
This patch only prepares the infrastructure required to support that
processing. All operations described below rely on helpers or stubs,
and their implementation details will be added in the subsequent
patches.
** Intended pipeline
Disclaimer: the description below documents the intended processing
pipeline. This commit only establishes the phases boundaries, and
call sites. The actual logic of each step is implemented in subsequent
patches.
The OAv2 processing pipeline follows a map-reduce pattern. Obviously,
the actual processing in GNU ld is not multi-threaded, and the
operations are not necessarily executed directly one after another.
* Phase 1, map: successive per-file operations applied on the list of
compatible input objects.
1. Parsing of the OAv2 section's data (also used by objcopy).
2. Translation of relevant GNU properties to OAv2. This is required
for the backward-compatibility with input objects only marked
using GNU properties.
3. Sorting of the subsections and object attributes. Further
operations rely on the ordering to perform some optimization in
the processing of the data.
4. Deduplication of subsections and object attributes, and detection
of any conflict between duplicated subsections or tags.
5. Translation of relevant OAv2 to GNU properties for a forward
-compatibility with the GNU properties merge.
6. Marking of unknown subsections to skip them during the merge
(in phase 2), and to prune them before the output object's
serialization (in phase 3).
* Phase 2, reduce: OAv2 in input objects are merged together.
1. Gathering of "frozen" values (=coming from the command-line
arguments) into a virtual read-only list of subsections and
attributes.
2. Merging of OAv2 from an input file and the frozen input.
3. Merging of the results of step 2 together. Since the OAv2 merge
is commutative and associative, it can be implemented as a reduce.
However, GNU ld implements it as an accumulate because it does
not support multithreading.
Notes: the two merge phases also perform a marking of unsupported/
invalid subsections and attributes. This marking can be used for
debugging, and also more practically, to drop unsupported optional
subsections from the output.
* Phase 3, finalization of the output.
1. Pruning of the unknown / unsupported / invalid subsections and
attributes.
2. Serialization of OAv2 data (also used by objcopy).
Notes:
- There is no translation of the merged OAv2 to GNU properties
at this stage, as the GNU properties merge process has already
all the needed information (translated in step 5 of stage 1) to
produce the GNU properties equivalents.
- The GNU properties are currently required as the runtime linker
does not understand OAv2 yet.
- Phase 3 should also include a compatibility check between the
final merge result of the current link unit and input shared
objects. I opted for postponing this compatibility check, and
GNU properties merge will take care of it as it already does.
Matthieu Longo [Mon, 20 Jan 2025 11:57:30 +0000 (11:57 +0000)]
bfd: add support for copying Object Attributes v2
The OAv2 section's content of the source file is copied to the
destination object file without any alteration of the attributes
or subsections (no deduplication nor sorting of subsections or
object attributes is performed).
For now, only ELF format is supported.
Matthieu Longo [Thu, 1 May 2025 16:42:33 +0000 (17:42 +0100)]
bfd: parse Object Attributes v2's section in input object files
This patch adds to BFD the capability of parsing the Object Attributes v2
(OAv2) stored into the section defined by the backend (i.e. .ARM.attributes
for AArch64).
An OAv2 section is organized with the following syntactic structure:
<format-version: uint8>
[ <subsection-length: uint32>
<subsection-name: NTBS>
<optionality: uint8>
<encoding: uint8>
<attribute>*
]*
Once parsing is completed, OAv2 are stored in a list of subsections in
elf_obj_tdata.
Regarding ULEB128 parsing, the implementation of _bfd_safe_read_leb128
has known shortcomings. In particular, it may accept malformed ULEB128
values if the 8th bit is set while meeting the end condition "data < end".
The error handling could be improved, but this function is old and used
in more than 50 places. The same issue applies to _bfd_read_unsigned_leb128
and _bfd_read_signed_leb128, which likewise do not report errors in
this case. Since this is long-standing behavior and fixing it would
require broader changes outside the scope of this patch series, the
issue is acknowledged but not addressed here, and is considered
acceptable as this patch does not worsen the situation.
Richard Ball [Tue, 14 Jan 2025 16:44:40 +0000 (16:44 +0000)]
Serialization and dumping tests of Object Attributes v2
The added tests cover the parsing of the new assembly directives
(aeabi_subsection and aeabi_attribute), the serialization of the
Object Attributes v2 (OAv2) data into an object file, and the
dumping of those data via readelf.
The parsing tests focus on the following points:
- the syntax of the new directives.
- the recognition of generic tokens like: NTBS, ULEB128, required,
optional.
- the recognition of backend-specific tokens like Tag_Feature_(BTI,
PAC,GCS).
The dumping tests focus on:
- the OAv2 population into the correct section assigned by the backend
(i.e. .ARM.attributes for AArch64).
- the merge of the subsections and attributes when they are declared
several times inside respectively the same compilation unit, and
subsection.
- the sorting of OAv2 before the serialization.
Co-Authored-By: Matthieu Longo <matthieu.longo@arm.com>
Richard Ball [Sat, 12 Apr 2025 17:24:40 +0000 (18:24 +0100)]
readelf: dump Object Attributes v2
This patch adds support to readelf for displaying Object Attributes v2
on AArch64. The list of known tags and subsections match the ones in
the document "Build Attributes for the Arm 64-bit Architecture (AArch64)"
available at [1].
[1]: https://github.com/ARM-software/abi-aa
Co-Authored-By: Matthieu Longo <matthieu.longo@arm.com>
Richard Ball [Thu, 1 May 2025 16:34:33 +0000 (17:34 +0100)]
bfd: write Object Attributes v2
This patch adds the serialization logic to write Object Attributes v2 (OAv2)
into the ELF section specified by the backend (.ARM.attributes for AARch64).
OAv2, once processed by the parser, are stored in the order they were
declared in the assembly, so not necessarily sorted. Sorting them
simplifies the comparison of the data between several files. Since
sorting OAv2 is clearly not the responsibility of readelf, they need
to be sorted by the producers (i.e. gas or ld).
The linker sorts the subsections and attributes as a pre-requisite of
the merge. Since the merge preserves the ordering, no final sort is
required before the serialization, contrarilly to the assembler.
Moving the final sort for gas into set_obj_attr_contents would mean
that a sort would be performed on an already-sorted collections. To
avoid this redundant operation at link time, we check whether the
output BFD is a linker output (is_linker_output = 1). If it is not
(i.e., it is gas), we perform a finalization step that sorts the
subsections and attributes before writing.
As previously mentioned, the logic of OAv1 and OAv2 is kept separated.
Co-Authored-By: Matthieu Longo <matthieu.longo@arm.com>
Matthieu Longo [Thu, 17 Apr 2025 14:02:18 +0000 (15:02 +0100)]
gas: use common code for object attribute v1 & v2 parsing
Since the previous patch added all the code to be able to parse both
OAv1 and OAv2 directives, this patch switches OAv1 to use this common
code.
Additionally to the common code in obj-elf.c, the following backends
using a custom object attribute directive were impacted.
- ARC
- Arm
- m68k
- PowerPC
- RISC-V
- TI C6X
A parsing test for Arm had to be adapted to the error messages of the
new parser.
The gas and ld test suites were successfully run for the following
backends: S390, ARC, Arm, CSky, m68k, msp430, PowerPC, TI C6X, RISC-V,
AArch64, MIPS, SPARC.
Richard Ball [Tue, 28 Jan 2025 17:06:58 +0000 (17:06 +0000)]
gas: implement parsing of object attributes v2
This patch adds the parsing logic for Object Attributes v2 (OAv2), enabling
Gas to interpret and process these attributes correctly. It also updates the
AArch64 backend to utilize the new parsing capabilities, and handle the new
AArch64-specific directives.
This patch relies on the abstractions introduced in the previous patch to
store the data. Its scope is limited to parsing the new assembly directives,
checking the inputs, and storing the data into the relevant OAv2 abstractions.
Note that, for now, the new parsing capabilities are only available for AArch64.
Even if the implementation was splitted into a generic part available in
gas/config/obj-elf.c, and an AArch64-specific one in gas/config/tc-aarch64.c,
the lack of GNU generic directives to handle OAv2 prevented the capability
from being exposed to others backends.
** GNU assembler interface for aeabi subsections
OAv2 introduced two new directives for AArch64:
- .aeabi_subsection name, comprehension, encoding
Create or switch the current subsection to 'name'.
Comprehension values can be 'required' or 'optional'.
Encoding values are limited for now to 'ULEB128', and 'NTBS'
The comprehension and encoding are mandatory arguments on the first
declaration of the subsection, but become optional for subsequent
ones.
- .aeabi_attribute tag, value
Set 'tag' to 'value' in the current subsection.
Tag can either be an integer, or one of the defined symbols in the backend.
The usage of those directives will error if the following requirements
are breached:
- If the subsection X has been previously declared, the comprehension and
encoding parameters of the current .aeabi_subsection that redeclares X
have to match with the previous declaration. If those parameters are
omited, no check is performed.
- The type of the value set via .aeabi_attribute has to align with
the current subsection.
- If the tag N has already been declared for the current subsection, a
later assignment to tag N is tolerated only if the newly set value is
equal to the former one. This check is stricter than needed. Ideally,
the tag N's values should be merged together, and an error should be
raised only if an incompatibility is detected. Because the attributes
are set in one chunk by GCC, there is no real use case for such a merge.
The new parsing code is enabled/disabled via the TC_OBJ_ATTR_v1 and
TC_OBJ_ATTR_v2 defines, and supports the following configurations:
- enable both OAv1 and OAv2 parsing. This is currently used by no
target, but is useful for migration from OAv1 to OAv2.
- enable OAv1 parsing only. This is used by all targets supporting OAs
except for AArch64.
- enable OAv2 parsing only. This is only used by AArch64.
** Regarding the implementation
The logic of OAv1 does not always keep separated the different data processing
steps: parsing, convertion to internal abstractions, error checking and further
processing (if any) on those abstractions, and their serialization into the
object files.
This patch takes into account the specifities of syntax for OAv1 and OAv2, but
mutualize as much as possible the common behavior so that the same methods can
be used for parsing the OAv1 and OAv2 directives.
However, the mutualization of the code is limited by a different internal model
for OAv1 and OAv2. Even if it is technically feaseable to have only one middle
-end for OAv1, OAv2 and even GNU properties, sharing the same data model to
perform the merge logic with the same code, it is a significant amount of work.
This extra work was not considered as a part of this new feature, so this patch
series will stick with the minimum of mutualization as possible.
Co-Authored-By: Matthieu Longo <matthieu.longo@arm.com>
Richard Ball [Mon, 20 Jan 2025 13:01:12 +0000 (13:01 +0000)]
Object Attributes v2: new abstractions for subsections and attributes
This patch lays the groundwork for the support of Object Attributes v2 (OAv2).
OAv2 is an enhancement of OAv1. They retain successful aspects of OAv1, define
the relationship between object attributes and existing GNU properties, separate
architectural requirements from software ABI requirements, and simplify the
format to make it easier for OAv2 consumers to parse, and skip subsections and
attributes. Interestingly, OAv2 have only one scope: the whole relocatable file
where they were specified. For the reason behind this choice, see [1], "Build
attributes at file scope only". This document also provides more insights into
the design rationale for OAv2.
Even if OAv2 was designed primarily for AArch64, this implementation splits the
generic core logic from the backend-specific one, and aims at facilitating OAv2
adoption by others backend. This logic will apply for any subsequent OAv2 patch.
New abstractions for attributes and subsections are introduced in bfd/elf-attrs.h
Those align with the format of OAv2 proposed in [2].
An object attribute obj_attr_v2 is a tag-value pair:
- tag: a key, i.e. a unique identifier for the attribute in the
subsection.
- value: a variant for which the interpretation depends on the encoding
set in the subsection it was stored in. 2 types of values are possible:
ULEB128 (Unsigned Little Endian Base 128) or a string encoded as NTBS
(Null-Terminated Byte String).
A subsection obj_attr_subsection_v2 has the following members:
- name: the name of this subsection.
- scope: the prefix in the subsection name determines whether the
subsection is public or private.
- optionality: is this subsection optional or required ? Depending on
whether the subsection is public or private, it can be ignored by the
consumer.
- encoding: see previous note regarding the value of an attribute. This
encoding applies to all the attributes in this subsection.
- list of object attributes.
Even if OAv1 and OAv2 data structures are similar, their processing is
different. Thus refactoring the code of OAv1 and OAv2 to share it does not
seem the right approach for clarity and maintainability, and minimalization
of the risk of introducing regressions.
Consequently, utility functions to initialize, copy, swap, free, compare,
mutate, and sort those structures won't be shared between OAv1 and OAv2.
Finally, the version ID used to identify the storage format of the object
attributes is object and backend dependent. This approach allows mixing
OAv1 and OAv2 in input objects. Then the deserializer translates the input
data to the internal model (currently OAv2, but it could be a more generic
one in the future) to perform the merge. In the end, the output format is
set by the backend: OAv2 for AArch64, OAv1 for others. The only exception
for this is objcopy, which won't change the format of the object attributes,
and will preserve the format of the data during the copy.
Hopefully, this mechanism will make easy the migration from OAv1 to OAv2 if
anyone is interested.
[1]: [Design Rationale for Build Attributes for the Arm 64-bit Architecture (AARCH64)]
(https://github.com/ARM-software/abi-aa/blob/eec881270d5e3b23e58a6250640d06ff545ec1fc
/design-documents/buildattr64-rationale.rst)
[2]: [Build Attributes for the Arm® 64-bit Architecture (AArch64)](https://github.com
/ARM-software/abi-aa/blob/eec881270d5e3b23e58a6250640d06ff545ec1fc/buildattr64
/buildattr64.rst)
Co-Authored-By: Matthieu Longo <matthieu.longo@arm.com>
Tom de Vries [Thu, 22 Jan 2026 09:48:45 +0000 (10:48 +0100)]
[gdb/symtab] Fix segfault in cutu_reader::read_toplevel_die
PR 33818 reports a problem when running test-case
gdb.ada/uninitialized-variable-record.exp:
...
(gdb) print y2
dwarf2/read.c:14073:20: runtime error: member access within null pointer of \
type 'struct dwarf2_cu'
ERROR: GDB process no longer exists
...
bisecting to commit 2f23cf07253 ("[gdb] Add regression test for PR
symtab/33777").
I managed to reproduce it using target board readnow.
The problem is here in cutu_reader::read_toplevel_die:
...
m_new_cu.get ()->per_objfile->per_bfd->nr_toplevel_dies_read++;
...
Class cutu_reader has two fields pointing to a dwarf2_cu:
...
/* The CU of the DIE we are parsing. */
struct dwarf2_cu *m_cu;
...
and:
...
dwarf2_cu_up m_new_cu;
...
and m_new_cu is not always set.
Fix this by using m_cu instead.
Reported-By: Jan Vrany <jan.vrany@labware.com Suggested-By: Simon Marchi <simon.marchi@efficios.com>
Tested on x86_64-linux.
reset_resolved_wilds didn't clear out matching_sections in output
sections with constraint -1. Fix that and tidy call sites of
obstack_init and obstack_free for matching_obstack so that the obstack
is allocated later and freed completely. Also tidy ptroot.
PR 33821
* ldlang.c (the_root): Delete, replacing with..
(ptroot): ..this, no longer a pointer. Update all uses.
(lang_for_each_statement_worker): Add "constrained" param.
Ignore os.constraint if false.
(reset_resolved_wilds): Use lang_for_each_statement_worker.
Move obstack_init..
(lang_init): ..and this obstack_init of matching_obstack..
(resolve_wilds): ..to here.
* ldlang.h (lang_for_each_statement_worker): Update declaration.
(lang_for_each_statement): Update.
* emultempl/xtensaelf.em: Update lang_for_each_statement_worker
calls throughout.
Alan Modra [Mon, 19 Jan 2026 23:57:45 +0000 (10:27 +1030)]
sframe fre sanity checks
I noticed the fre esz check in flip_sframe_fdes_with_fres_* was wrong,
testing against the full buffer size rather than the remaining size.
It is also ineffective at stopping buffer overflows to check after the
buffer accesses have occurred.
Likely many more buffer overflow checks in the sframe code are needed
before anyone can claim it is secure. Even in the fre code, I see
things like sframe_decoder_get_fres_buf merrily iterating over fres
without a concern for buffer overflow.
* sframe.c (flip_fre): Add fp_size param. Use it to avoid
buffer overflow on fuzzed input.
(flip_sframe_fdes_with_fres_v2): Pass remaining buffer size to
flip_fre. Remove now redundant and wrong esz check.
(flip_sframe_fdes_with_fres_v3): Likewise.
Tom Tromey [Sun, 18 Jan 2026 17:09:19 +0000 (10:09 -0700)]
Remove lookup_transparent_type lang hook
C++ was the only user of the lookup_transparent_type lang hook, so it
can be removed entirely. basic_lookup_transparent_type and its helper
function are renamed as appropriate.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Sun, 18 Jan 2026 17:05:23 +0000 (10:05 -0700)]
Remove cp_lookup_transparent_type
cp_lookup_transparent_type seems to be a workaround for bugs in very
old compilers. A comment mentions that the bugs are fixed in GCC 3.4
-- released in 2004.
I think this is long past due for removal, which this patch does.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Wed, 21 Jan 2026 04:57:34 +0000 (15:27 +1030)]
hppa64 root.u.def assertions
The aim here is to add assertions when root.u.def is accessed that
the field is valid, ie. we have a bfd_link_hash_defined or
bfd_link_hash_defweak symbol. On doing so I found the assertion
triggering on one of the ld undefweak tests, fixed with the
elf64_hppa_finish_dynamic_symbol change.
The patch also refactors code using text_hash_entry and
data_hash_entry.
* elf64-hppa.c (elf64_hppa_finish_dynamic_symbol): Use zero
value for both undefined and undefweak symbols, and when
non-pic too. Assert when accessing root.u.def that the symbol
is the correct type.
(elf64_hppa_finalize_opd, elf64_hppa_finalize_dlt),
(elf64_hppa_finalize_dynreloc): Similarly assert here.
(elf64_hppa_finalize_dlt): Move duplicate code involving
text_hash_entry and data_hash_entry out of conditionals.
(elf64_hppa_finalize_dynreloc, elf_hppa_dlt_dynrel_reloc),
(elf_hppa_final_link_relocate): Likewise.
A previous commit added new backend hook sframe_support_flex_fde_p by
defining a new function for each backend that supports SFrame stack
trace format:
As pointed out in a review comment, simply providing the definition to
use true/false (as applicable) is sufficient for the purpose, and helps
generate better code. So do that.
https://inbox.sourceware.org/binutils/80404871-53b4-4f5c-9d86-7a3a4d0a920e@suse.com/
GNU doesn't generally use the "<...>" convention, but instead uses
upper case for "metasyntactic variables". See the GNU coding
standards for this topic.
In this particular spot, though, I think the old form using quotes is
preferable. This patch reverts this change.
Commit a1c2fa92ac93bf50227941bd82094e6997c5fd56 broke the ld
testcase for .note.GNU-stack wanting to be SHT_NOTE. Fix this
by falling back to .text if .dynamic isn't available to define
the text segment base.
2026-01-21 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (elf64_hppa_late_size_sections): Fallback
to .text if .dynamic section isn't found.
Tom de Vries [Wed, 21 Jan 2026 15:43:07 +0000 (16:43 +0100)]
[gdb] Ignore .sframe section in dtrace_static_probe_ops::get_probes
On aarch64-linux (Debian testing), with test-case gdb.base/fission-macro.exp I
run into:
...
(gdb) set complaints 5^M
(gdb) file fission-macro-v4-b32-s0^M
Reading symbols from fission-macro-v4-b32-s0...^M
During symbol reading: \
skipping section '.sframe' which does not contain valid DOF data.^M
(gdb) FAIL: $exp: lang=c: dwarf_version=4: dwarf_bits=32: strict_dwarf=0: \
No complaints
...
The problem is that there's an overlap between:
...
./include/elf/common.h:#define SHT_SUNW_dof 0x6ffffff4
...
and:
...
./include/elf/common.h:#define SHT_GNU_SFRAME 0x6ffffff4
...
So when dtrace_static_probe_ops::get_probes tries reading an SHT_SUNW_dof
section, it fails to read the corresponding magic number and bails with this
complaint:
...
During symbol reading: \
skipping section '.sframe' which does not contain valid DOF data.^M
...
But the section actually being read is not an SHT_SUNW_dof section, but an
SHT_GNU_SFRAME section:
...
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[17] .sframe GNU_SFRAME 00000000000008f0 0008f0 000035 00 A 0 0 8
...
Fix this by checking for the section name .sframe in
dtrace_static_probe_ops::get_probes.
Tested on aarch64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33813
Michal Sobon [Wed, 21 Jan 2026 13:45:05 +0000 (14:45 +0100)]
opcodes: Fix BMASKI disassembly for immediate 32 on M*Core
The BMASKI instruction has three encoding variants (OMa, OMb, OMc).
The OMa encoding (0x2C00, mask 0xFFF0) specifically represents
BMASKI with immediate 32, encoded as IMM5=0.
Per Motorola M*Core specification: "An IMM5 value of 0 is interpreted
as a value of 32."
Previously, all three variants extracted the immediate the same way,
causing OMa to incorrectly display 0 instead of 32.
opcodes/
* mcore-dis.c (print_insn_mcore): Handle OMa encoding to display
immediate 32 instead of 0 for BMASKI.
gas/testsuite/
* gas/mcore/allinsn.s: Add test for bmaski with immediate 32.
Replace two clrc padding instructions with one for 4-byte alignment.
Fix missing newline at end of file.
* gas/mcore/allinsn.d: Update expected output.
Evgeny Karpov [Wed, 21 Jan 2026 13:44:44 +0000 (14:44 +0100)]
aarch64: Add bigobj support to AArch64 COFF
During Boost library testing on aarch64-w64-mingw32, it appeared that 2^16
sections are not enough. It can be handled by using the bigobj format to extend
the total amount of sections to 2^32. This patch adds bigobj support to
AArch64 COFF in a similar way to how it is done for x86_64.
Co-authored-by: Martin Vejbora <mvejbora@microsoft.com> Signed-off-by: Evgeny Karpov <evgeny@kmaps.co>
Jan Beulich [Wed, 21 Jan 2026 13:43:54 +0000 (14:43 +0100)]
ld: testcase for .note.GNU-stack wanting to be SHT_NOTE
If --noexecstack is removed and instead of empty.s a source file is used
which explicitly creates a @progbits .note.GNU-stack, the test fails (for
the absence of a NOTE segment).
Jan Beulich [Wed, 21 Jan 2026 13:42:39 +0000 (14:42 +0100)]
readelf: don't (silently) fail on empty SHT_NOTE sections
Them containing no entries is not an error. Such sections simply have
nothing to dump. (Exiting with non-zero status but no error message isn't
quite appropriate anyway.)
Matthieu Longo [Thu, 4 Dec 2025 15:50:30 +0000 (15:50 +0000)]
aarch64: silence GCS warnings on shared libraries for -z gcs=implicit
Dynamic library incompatibilities should not be reported when no GCS
option is provided (defaults to '-z gcs=implicit') and no explicit
diagnostic is provided via '-z gcs-report-dynamic'.
Binary Linux distributions do not rebuild all packages from scratch
when rolling out a new feature or creating a new release; only
modified packages get rebuilt. In the context of GCS deployment, this
meant that some packages were rebuilt with GCS enabled while their
dependencies were not yet GCS-compatible, resulting in warnings. These
warnings caused build failures for packages that treat linker warnings
as errors. Those errors slowed down the GCS deployment, and Linux
distribution maintainers requested that no GCS option provided should
be equivalent to '-z gcs=implicit -z gcs-report-dynamic=none'.
In contrast, '-z gcs=always' should continue to report such issues by
default. Warnings can still be disabled or promoted to errors by
explicitly setting '-z gcs-report-dynamic' to respectively 'none' or
'error'.
This patch preserves the existing behaviour for '-z gcs=never', changes
the default behaviour of '-z gcs=implicit' or no GCS option, and removed
the inheritance mechanism between '-z gcs-report' and '-z gcs-report-dynamics'.
The expected behaviour with the different possible combinations is as
follows:
* -z gcs=never:
No diagnostic messages are emitted.
* -z gcs=implicit:
No diagnostic messages are emitted for input static objects.
However, if all the input static objects are marked for GCS, the
output object will also be marked for GCS.
In this case the output is marked with GCS, '-z gcs-report-dynamic'
defaults to 'none' and no diagnostics are emitted. Diagnostics can
be enabled by explicitly providing the option.
* -z gcs=always:
Warning diagnostics for both static and dynamic input objects are
enabled by default. The two options are independent of one another,
and the diagnostic level can be adjusted for each by explicitly
providing the desired level to '-z gcs-report-dynamic' and '-z
gcs-report'.
The patch also updates the existing tests, removes redundant test cases,
and adds new tests covering cases with no report option provided, or
report options explicitly set.
The SFrame test for PR ld/33401 is a two-step link test where the
second link depends on the output of the first. In the first step, the
linker process generates R_*_NONE relocs for .sframe section, while
the second link process should pass without any issue.
This patch reworks the PR ld/33401 test by removing the call to
run_cc_link_tests, and use individual command invocation for
compilation, assembling and linking. It introduces the UNRESOLVED
status if the first step contains a linking or assembling error. The
UNTESTED status is emitted if the first stage doesn't produce R_*_NONE
relocs in .sframe section to test the original issue.
ld/
PR ld/33784
* testsuite/ld-sframe/sframe.exp (check_pr33401): Rework the
procedure for UNRESOLVED and UNTESTED cases.
(check_dump): New procedure.
* testsuite/ld-sframe/pr33401.rd: Add extra line at the end of the
file.
As a result of the mail exchange in
https://sourceware.org/pipermail/binutils/2026-January/147439.html,
the run_cc_link_test procedure may want to link standard libs
too. However, this is not required for running PR 32789 tests. Add
-nostdlib option.
ld/
* testsuite/ld-sframe/sframe.exp: Add nostdlib when testing PR
32789.
Alan Modra [Mon, 19 Jan 2026 22:13:25 +0000 (08:43 +1030)]
libsframe misaligned uint32_t
I saw asan complaints about misaligned loads and stores when taking a
quick look at pr33810 before Jens' patch was applied. They have
disappeared now, but it looks to me like a FRE can start on any
address boundary and there is no padding or suchlike to align the
FRE fields.
* sframe.c (flip_fre_stack_offsets): Let the compiler know
that integers may be misaligned.
Simon Marchi [Sat, 17 Jan 2026 06:02:35 +0000 (01:02 -0500)]
gdb/dwarf: add unit_lists structure to index writer
I think it makes the code more readable than the pair of vector. Also,
I'm considering adding a third list (foreigh type units), which will be
easier with the structure.
Change-Id: I38ec4ddf8f786a2ba10c5b371cfe04c2baaa7da9 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 17 Jan 2026 06:02:32 +0000 (01:02 -0500)]
gdb/dwarf: move DWP htab nullptr check to lookup_dwo_unit_in_dwp
cutu_reader::lookup_dwo_cutu gets hold of the right htab for the kind of
unit to look up (CU or TU), but then just uses the pointer to know if it
should call lookup_dwo_unit_in_dwp or not. lookup_dwo_unit_in_dwp then
uses the same condition to obtain the correct htab. I think it would
make more sense to return early from lookup_dwo_unit_in_dwp instead, if
the required htab does not exist.
Change-Id: I6f8f96aba2452f8261b3c60667e72fb21b97c89d Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Tue, 20 Jan 2026 15:08:38 +0000 (15:08 +0000)]
gdb: fail for 'maint print frame-id LEVEL' of an invalid frame
I noticed that 'maint print frame-id LEVEL' will always print a
frame-id, just not always for LEVEL, for example:
(gdb) bt
#0 woof () at stack.c:4
#1 0x000000000040111f in bar () at stack.c:10
#2 0x000000000040112f in foo () at stack.c:16
#3 0x000000000040113f in main () at stack.c:22
(gdb) maintenance print frame-id 4
frame-id for frame #3: {stack=0x7fffffffa640,code=0x0000000000401131,!special}
(gdb)
Notice that the request was for the frame-id of #4, which doesn't
exist, but what I got was the frame-id for #3.
Fix this by adding a check to maintenance_print_frame_id (frame.c), so
the new behaviour is:
(gdb) maintenance print frame-id 4
No frame at level 4.
(gdb)
This matches the behaviour of the 'frame' command:
(gdb) frame 4
No frame at level 4.
(gdb)
I've added a new test to cover this case.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
hppa64: Improve relocation handling for local symbols and add gc_section support
With this patch, gcc-16 can be built and there are significant
improvements in test results. I spent a lot of time trying to
fix the EH exception support. While there are still issues with
handling relocations in linkonce sessions, exception handling
mostly works if pc-relative and text relative encoding is used
in .eh_frame. The main problems are the HP-UX dynamic linker
relocates the text and data segements indpendently, and it does
not support unaligned dynamic relocations.
Due to a configure bug in libstdc++-v3, the lack of gc_section
support caused many test failures, so I added the gc_section
support form elf32-hppa.c.
I also move the HP_LOAD_MAP scratchpad to the end of the .bss
section and fixed a number of issues with the linker scripts.
2026-01-20 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (elf64_hppa_check_relocs): Drop NEED_PLT
from R_PARISC_LTOFF_FPTR relocations. Revise R_PARISC_FPTR64
relocation to use maybe_dynamic. Add support for
R_PARISC_GNU_VTINHERIT and R_PARISC_GNU_VTENTRY relocations.
Add code to handle dynamic relocations of local symbols.
(elf64_hppa_gc_mark_hook): New.
(ensure_undef_dynamic): New.
(allocate_dynrel_entries): Revise checks to determine when
to discard relocs.
(elf64_hppa_late_size_sections): Revise allocation of local
PLT, DLT and OPD entries.
(elf64_hppa_finalize_opd): Remove assert.
(elf64_hppa_finalize_dlt): Change type of dynindx to long.
(elf64_hppa_finalize_dynreloc): Likewise. Add check for
discarded sections. Correct handling of R_PARISC_FPTR64
relocation. Remove assert. Add new assert to check that
we don't allocate more relocs in .rela.data than it can
hold.
(elf64_hppa_finish_dynamic_sections): Move allocation for
DT_HP_LOAD_MAP to end of .bss section. Only allocate on
HP-UX.
(elf_hppa_dlt_dynrel_reloc): Add dynrel_type argument.
Change type of dynindx. Drop use of value. Remove assert.
(elf_hppa_opd_dynrel_relocs): Rename to elf_hppa_opd_eplt_reloc.
Drop code to to emit R_PARISC_FPTR64 relocation.
(elf_hppa_opd_fptr_reloc): New.
(elf_hppa_final_link_relocate): Add SYM arguement. Move
check for SEC_DEBUGGING. Rework DLT, LTOFF, FPTR and DIR64
relocation handling.
(elf64_hppa_relocate_section): Add asserts to ensure symbol
isn't undefined and input_section hasn't been discarded.
(elf_backend_gc_mark_hook): Define.
(elf_backend_can_gc_sections): Define.
ld/ChangeLog:
* emulparams/elf64hppa.sh (DATA_ADDR): Revise value to match
HP-UX 11 value.
(SHLIB_DATA_ADDR): Likewise.
(NOP): Define.
(OTHER_READONLY_SECTIONS): Add .data.rel, .HP.init, .preinit,
.init and .fini sections to list.
(__SYSTEM_ID_D, __TLS_SIZE_D, __FPU_REVISION, __FPU_MODEL,
__CPU_REVISION, __CPU_KEYBITS_1, __LOAD_INFO, __ARGC, __ARGV,
__ENVP, __libdl_jmp_tbl, __systab): Provide.
(DATA_START_SYMBOLS, OTHER_SYMBOLS, INIT_START): Delete.
(PREINIT_START, PREINIT_END, INIT_START): Define.
emulparams/hppa64linux.sh (NOP): Define.
(DATA_START_SYMBOLS): Delete.
scripttempl/elf64hppa.sc: Delete .init and .fini sections
from script. Allocate 16 bytes at end of .bss for HP_LOAD_MAP.
Tom Tromey [Thu, 8 Jan 2026 15:03:33 +0000 (08:03 -0700)]
Move puts_tabular to obj-lang.c
Only objc-lang.c uses puts_tabular. This patch moves the function
there and makes it 'static'. It is also updated not to depend on the
global (but private to utils.c) chars_printed, and not to call
begin_line.
Tom Tromey [Fri, 16 Jan 2026 18:27:46 +0000 (11:27 -0700)]
Remove all globals from coffread.c
This patch changes coffread.c to add a reader object type. All
globals are moved into this type, and the majority of functions in
coffread.c are changed to be methods.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Fri, 16 Jan 2026 18:18:20 +0000 (11:18 -0700)]
Use coffread_objfile throughout coffread.c
coffread.c:coff_symtab_read sets a global objfile while working. It
seemed nicer to me to hoist this so that it is set by the main entry
point, and then used throughout the file.
Normally I wouldn't encourage the use of globals, but shortly we'll be
replacing these with an object.
Note that while coff_symtab_read cleared coffread_objfile when it was
finished, I haven't preserved this in the new patch. First, this
should have been done with a scoped_restore. Second, this is the only
global to get this treatment. Third, it's not necessary at all. And,
finally, this will be moot anyway when the globals are removed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Fri, 16 Jan 2026 18:08:58 +0000 (11:08 -0700)]
Remove redundant nlist_bfd_global
coffread.c has two BFD globals: nlist_bfd_global and symfile_bfd.
There's no need for both, and since symfile_bfd is set early (in
coff_symfile_read, the entry point), this removes nlist_bfd_global and
replaces all the uses.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
BFD: Remove extraneous BFD struct member setup from `bfd_make_readable'
Complementing commit 3097045a18a8 ("ld plugin bfd_make_readable leak")
remove assignments to BFD struct members from `bfd_make_readable' that
now duplicate ones unconditionally made by `_bfd_free_cached_info'
called earlier on.
BFD: Remove null pointer checks for `bfd_hash_table_free' calls
Given that as from commit 90e5645309be ("libiberty: Make `objalloc_free'
`free'-like WRT null pointer") `bfd_hash_table_free' now returns with no
action taken when called for a hash table with no allocation present,
remove null pointer checks guarding invocations.
Jens Remus [Tue, 20 Jan 2026 09:33:56 +0000 (10:33 +0100)]
s390: gas: Remove support for register names "ap" and "cc" in CFI directives
The assembler erroneously converted the special register names "ap" and
"cc" to the DWARF register numbers 32 and 33 respectively, which are
actually assigned to the control registers c0 and c1 according to both
the s390 32-bit (s390) ELF ABI [1] and s390 64-bit (s390x) ELF ABI [2].
Register numbers 32 and 33 are used internally by GCC as "argument
pointer" (ap) and "condition code" (cc). Very early GCC versions leaked
this out into DWARF. However, those GCC-internal special register names
should never be actually used in CFI, especially given their resulting
DWARF register numbers have a different meaning in DWARF (CFI).
Jens Remus [Tue, 20 Jan 2026 09:33:56 +0000 (10:33 +0100)]
s390: gas: Support access register names in CFI directives
Convert access register (AR) names a0-a15 to DWARF register numbers when
used in CFI directives. Convert an access register number (0..15) to
its corresponding DWARF register number (48..63) as specified in the
s390 64-bit (s390x) ELF ABI [1] by adding 48.
gas/testsuite/
* gas/s390/cfi-regnames.d: Add test for AR names in in CFI
directives.
* gas/s390/cfi-regnames.s: Likewise.
* gas/s390/cfi-regnames-err.l: Likewise.
* gas/s390/cfi-regnames-err.s: Likewise.
Jens Remus [Tue, 20 Jan 2026 09:33:56 +0000 (10:33 +0100)]
s390: gas: Support vector register names in CFI directives
Convert vector register names v0-v31 to DWARF register numbers when used
in CFI directives. Convert a vector register number (0..31) to its
respective DWARF register number (16..31, 68..83) as specified in the
s390 64-bit (s390x) ELF ABI [1] as follows:
Right rotate the least significant three bits and add 16 for register
numbers 0..15 or 68 for register numbers 16..31.
Add a test case for the use of vector register (VR) names in CFI
directives.
Jens Remus [Tue, 20 Jan 2026 09:33:55 +0000 (10:33 +0100)]
s390: gas: Fix conversion of FP register names to DWARF register numbers
The assembler supports register names in CFI directives. For floating-
point (FP) registers f0..f15 the register numbers 0..15 are erroneously
converted to DWARF register numbers 16..31 by adding 16. This is wrong
as the s390 64-bit (s390x) ELF ABI [1] specifies the DWARF register
numbers for the FP registers as follows:
Convert a FP register number (0..15) to its respective DWARF register
number (16..31) as follows:
Right rotate the least significant three bits and add 16.
Add a test case for the use of general register (GR; r0..r15) and
floating-point register (FPR; f0..f15) names in CFI directives.
gas/
* config/tc-s390.c (tc_s390_regname_to_dw2regnum): Fix
conversion of FP register names to DWARF register numbers.
gas/testsuite/
* gas/s390/s390.exp (cfi-regnames, cfi-regnames-err): Run new
tests.
* gas/s390/cfi-regnames.d: New test for GR and FPR names in CFI
directives.
* gas/s390/cfi-regnames.s: Likewise.
* gas/s390/cfi-regnames-err.l: Likewise.
* gas/s390/cfi-regnames-err.s: Likewise.
Jens Remus [Tue, 20 Jan 2026 09:22:52 +0000 (10:22 +0100)]
libsframe: use proper FRE type when flipping SFrame V3 FREs
flip_sframe_fdes_with_fres_v3 was erroneously using a fixed FRE type
of 0 (= SFRAME_FRE_TYPE_ADDR1) when endianness byte-flipping the FREs,
regardless of the actual FRE type (i.e. ADDR1, ADDR2, or ADDR4). This
only affected cross builds, where the .sframe section data may needed
to be endianness byte-flipped (e.g. binutils cross-built for s390
64-bit (s390x) on x86-64).
As a consequence objdump/readelf with option --sframe could fail to dump
e.g. s390 64-bit (s390x) .sframe section data on x86-64 with the
following error message:
Error: SFrame decode failure: Buffer does not contain SFrame data.
The linker ld-sframe test "PR ld/33401 (Step 1: Create relocatable
object and check R_*_NONE)" cross-build for s390 64-bit (s390x) on
x86-64 could fail with ld error message:
error in tmpdir/StatePlaying.o(.sframe); no .sframe will be created
The linker ld-sframe test "PR ld/33401 (Step 1: Create relocatable
object and check R_*_NONE)" cros-build for s390 64-bit (s390x) on
x86-64 could fail with BDF assertion:
Add a common cfi-sframe assembler test, that forces a FDE type of
SFRAME_FRE_TYPE_ADDR2. When the test is run cross-build it may
exercise the SFrame FDE and FDE endianness byte flipping.
libsframe/
PR ld/33810
* sframe.c (sframe_decode_fde_attr_v3): Decode and return FRE
type from FDE attributes.
(flip_sframe_fdes_with_fres_v3): Use proper FRE type from
FDE attributes when flipping FREs.
gas/testsuite/
PR ld/33810
* gas/cfi-sframe/cfi-sframe.exp (cfi-sframe-common-pr33810): Run
new test.
* gas/cfi-sframe/cfi-sframe-common-pr33810.d: New test.
* gas/cfi-sframe/cfi-sframe-common-pr33810.s: Likewise.
Bug: https://sourceware.org/pr33810 Fixes: 8ab6e4c72ab6 ("[SFrame-V3] include: gas: libsframe: split FDE into idx and attr") Reported-by: Alan Modra <amodra@gmail.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Tom de Vries [Tue, 20 Jan 2026 08:06:20 +0000 (09:06 +0100)]
[gdb] Add regression test for PR symtab/33777
PR symtab/33777 reports a problem where toplevel DIEs of partial units are
read many times.
The problem manifest as a timeout when building gdb with -O0 and Asan, and
running test-case gdb.base/tls-dlobj.exp with glibc debuginfo installed.
Reproduce the problem in a simpler and quicker way, without relying on glibc
debuginfo:
- build an executable with 100 partial units
- run info line "$file:$line" a 100 times
- add a line to "maint print statistics" that tells us how many time a
toplevel DIE is read.
Without the fix we have:
...
Number of read units: 1
Number of unread units: 108
Number of read top-level DIEs: 10118
...
and with the fix we have:
...
Number of read units: 1
Number of unread units: 108
Number of read top-level DIEs: 218
...
Detect the problem by asserting:
...
gdb_assert { $top_level_die <= 3 * ( $read_cu + $unread_cu ) }
...
The factor 3 is used because for some target boards $top_level_die is slightly
more than 2 * ( $read_cu + $unread_cu ).
Tom Tromey [Sun, 18 Jan 2026 17:42:34 +0000 (10:42 -0700)]
Remove "alias" hack from add_symbol_to_list
add_symbol_to_list has this code:
/* If this is an alias for another symbol, don't add it. */
if (symbol->linkage_name () && symbol->linkage_name ()[0] == '#')
return;
This appears to be an old stabs hack. In the stabs removal patch
(commit eaea19f98d8) we see:
- /* '#' is a GNU C extension to allow one symbol to refer to another
- related symbol.
-
- Generally this is used so that an alias can refer to its main
- symbol. */
This is a classic example of an old style problem that gdb had:
sometimes hacks were added to the gdb core to work around problems in
symbol readers -- IMO this kind of thing should have always been
handled by the stabs reader itself, not add_symbol_to_list.
Anyway, this is obsolete now and this patch removes it.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Mon, 19 Jan 2026 18:14:11 +0000 (19:14 +0100)]
[gdb/symtab] Handle zero opcode_base in line number program header
I build gdb with TSAN, and with test-case gdb.dwarf2/malformed-line-header.exp
ran into a heap-use-after-free:
...
(gdb) info line 1
==================
WARNING: ThreadSanitizer: heap-use-after-free (pid=897504)
Write of size 1 at 0x72040000d000 by main thread:
#0 dwarf_decode_line_header() gdb/dwarf2/line-header.c:356 (gdb+0xa0618c)
...
Location is heap block of size 0 at 0x72040000d000 allocated by main thread:
#0 operator new[](unsigned long) <null> (libtsan.so.2+0xa6b01)
#1 dwarf_decode_line_header() gdb/dwarf2/line-header.c:354 (gdb+0xa06159)
...
This is caused by allocating a zero-sized array (lh->opcode_base == 0), and
writing to it:
...
lh->standard_opcode_lengths.reset (new unsigned char[lh->opcode_base]);
lh->standard_opcode_lengths[0] = 1; /* This should never be used anyway. */
...
Fix this by skipping this code if lh->opcode_base == 0.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Jan Beulich [Mon, 19 Jan 2026 09:42:25 +0000 (10:42 +0100)]
PPC: permit %dm0 as insn operand
When the DM registers were added, sorting of the table was broken. With
the present arrangement, this leads to (only) %dm0 not being found by the
binary search that both use sites of the table entertain.
Jan Vrany [Mon, 19 Jan 2026 08:58:41 +0000 (08:58 +0000)]
gdb/testsuite: fix FAILs in fileio.exp
I'm experiencing intermittent FAILs in fileio.exp when running on (my)
CI:
FAIL: gdb.base/fileio.exp: Open a file
FAIL: gdb.base/fileio.exp: Creating already existing file returns EEXIST
FAIL: gdb.base/fileio.exp: Open for write but no write permission returns EACCES
FAIL: gdb.base/fileio.exp: Writing to a file
...
The problem turned out to be the way the OUTDIR gets defined in fileio.c.
The path is passed down "naked" and turned into string by STRINGIFY macro.
However, if the path happens to contain name of unrelated pre-existing
C macro, this macro gets expanded during the "stringification", resulting
in (likely) different path than used in fileio.exp and therefore causing
failures.
For example, if the GDB is compiled and tested in directory
This commit fixes this by defining the OUTDIR as string literal in first
place (similarly to how it was done prior commit cc91060) and updating
quote_for_host to handle strings that themselves contains quote (").
Tested on x86_64-linux by running all tests using quote_for_host with
both target board unix and host/target board local-remote-host-native.
projects / thirdparty / binutils-gdb.git / log
