If gcc is configured on aarch64-linux against new binutils, such as
2.46, it doesn't emit into assembly markings like
.section .note.gnu.property,"a"
.align 3
.word 4
.word 16
.word 5
.string "GNU"
.word 0xc0000000
.word 4
.word 0x7
.align 3
but instead emits
.aeabi_subsection aeabi_feature_and_bits, optional, ULEB128
.aeabi_attribute Tag_Feature_BTI, 1
.aeabi_attribute Tag_Feature_PAC, 1
.aeabi_attribute Tag_Feature_GCS, 1
The former goes into .note.gnu.propery section, the latter goes into
.ARM.attributes section.
Now, when linking without LTO or with LTO but without -g, all behaves
for the linked binaries the same, say for test.c
int main () {}
$ gcc -g -mbranch-protection=standard test.c -o test; readelf -j .note.gnu.property test
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI, PAC, GCS
$ gcc -flto -mbranch-protection=standard test.c -o test; readelf -j .note.gnu.property test
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI, PAC, GCS
$ gcc -flto -g -mbranch-protection=standard test.c -o test; readelf -j .note.gnu.property test
readelf: Warning: Section '.note.gnu.property' was not dumped because it does not exist
The problem is that the *.debug.temp.o object files created by lto-wrapper
don't have these markings. The function copies over .note.GNU-stack section
(so that it doesn't similarly on most arches break PT_GNU_STACK segment
flags), and .note.gnu.property (which used to hold this stuff e.g. on
aarch64 or x86, added in PR93966). But it doesn't copy the new
.ARM.attributes section.
The following patch fixes it by copying that section too. The function
unfortunately only works on names, doesn't know if it is copying ELF or some
other format (PE, Mach-O) or if it is copying ELF, whether it is EM_AARCH64
or some other arch. The following patch just copies the section always,
I think it is very unlikely people would use .ARM.attributes section for
some random unrelated stuff. If we'd want to limit it to just EM_AARCH64,
guess it would need to be done in
libiberty/simple-object-elf.c (simple_object_elf_copy_lto_debug_sections)
instead as an exception for the (*pfn) callback results (and there it could
e.g. verify SHT_AARCH64_ATTRIBUTES type but even there dunno if it has
access to the Ehdr stuff).
No testcase from me, dunno if e.g. the linker can flag the lack of those
during linking with some option rather than using readelf after link and
what kind of effective targets we'd need for such a test.
2026-03-05 Jakub Jelinek <jakub@redhat.com>
PR target/124365
* simple-object.c (handle_lto_debug_sections): Also copy over
.ARM.attributes section.
demangle_binder() parses the bound_lifetimes count as a base-62
integer with no upper bound. A crafted symbol can encode a huge
lifetime count in very few bytes, causing OOM or CPU hang.
Cap bound_lifetimes at 1024 and check rdm->errored in the loop
so it bails out early on errors during iteration.
libiberty/ChangeLog:
PR demangler/106641
* rust-demangle.c (demangle_binder): Reject bound_lifetimes
above 1024 to prevent resource exhaustion from crafted symbols.
Add rdm->errored check in the loop condition.
* testsuite/rust-demangle-expected: Add regression test.
Signed-off-by: Ruslan Valiyev <linuxoid@gmail.com>
In the case where a Mach-O object is embedded inside some container
(e.g. an archive) we must account the offset from the start of that
container when reading. In most cases, this has been done correctly.
However, we were missing the case for reading segment data. This
only showed up once we tried using archives (since regular Mach-O
objects start at the begining of the file).
Fixed thus.
libiberty/ChangeLog:
* simple-object-mach-o.c
(simple_object_mach_o_segment): Account for the offset of
this Mach-O object from the start of any container.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
The MSVCRT `strtoul()` function resets `errno` to zero upon success. On such
a system, `libiberty_vprintf_buffer_size()` could clobber `errno` like this:
MINGW64 ~
$ ld nonexistent.file
C:\MSYS64\mingw64\bin\ld.exe: cannot find nonexistent.file: No error
libiberty/ChangeLog:
* vprintf-support.c (do_strtoul): New function.
(libiberty_vprintf_buffer_size): Replace `strtoul` with `do_strtoul`.
Signed-off-by: LIU Hao <lh_mouse@126.com>
This patch introduces a new helper to swap the contents of two
doubly-linked list wrappers. The new *_swap_lists operation exchanges
the first, last, and size fields, allowing two lists to be swapped
efficiently without iterating over their elements.
This helper is intended for cases where the ownership of a list must be
exchanged but swapping wrapper pointers is not possible. For simple
references to lists, when wrappers are dynamically allocated, swapping
the wrapper pointers themselves is sufficient and remains the preferred
approach.
This change adds the necessary declaration and definition macros to
doubly-linked-list.h and integrates them into the set of mutative
list operations.
The testsuite is updated accordingly to cover the new functionality.
include/ChangeLog:
* doubly-linked-list.h
(LINKED_LIST_SWAP_LISTS): Add new helper.
(LINKED_LIST_DECL_SWAP_LISTS): Likewise.
(LINKED_LIST_DEFN_SWAP_LISTS): Likewise.
(LWRAPPERTYPE##_swap_lists): Likewise.
libiberty/ChangeLog:
* testsuite/test-doubly-linked-list.c: Update.
Inspired by a suggestion from Jan Beulich to make one of `objalloc_free'
callers `free'-like with respect to null pointer argument handling make
the function return with no action taken rather than crashing when such
a pointer is passed. This is to make the API consistent with ISO C and
to relieve all the callers from having to check for a null pointer.
libiberty/
* objalloc.c (objalloc_free): Don't use the pointer passed if
null.
This commit:
- Adapts specs in config/darwin.h for libga68.a.
- Amends section processing for non-LTO use in libibery on Darwin.
The initial implementation of the Mach-O simple object code was
mainly targeting LTO cases. The implementation was not suitable for
cases where we are just looking for a regular named section.
Signed-off-by: Iain Sandoe <iains.gcc@gmail.com>
gcc/ChangeLog
* config/darwin.h: Adapt specs for libga68.a.
libiberty/ChangeLog:
* simple-object-mach-o.c
(simple_object_mach_o_segment): Handle non-LTO sections.
This patch adds support for the BigObj COFF object file format to libiberty's
simple-object-coff.c. BigObj extends regular COFF to support a 32-bit section
count.
BigObj differs from COFF in a few ways:
* A different header structure
* 32-bit section counts instead of 16-bit
* 32-bit symbol section numbers instead of 16-bit
* 20-byte symbols instead of 18-byte symbols
(due to the extended section numbers)
For a more detailed summary, read my blog post on this subject:
https://peter0x44.github.io/posts/bigobj_format_explained/
libiberty/ChangeLog:
PR target/122472
* simple-object-coff.c (struct external_filehdr_bigobj): New
structure for BigObj file header.
(bigobj_magic): New constant for BigObj magic bytes.
(struct external_syment_bigobj): New structure for BigObj
20-byte symbol table entries.
(union external_auxent_bigobj): New union for BigObj 20-byte
auxiliary symbol entries.
(struct simple_object_coff_read): Add is_bigobj flag and make
nscns 32-bit to support both formats.
(struct simple_object_coff_attributes): Add is_bigobj flag.
(simple_object_coff_match): Add BigObj format detection.
(simple_object_coff_read_strtab): Use format-specific symbol
size when calculating string table offset.
(simple_object_coff_attributes_merge): Check is_bigobj flag.
(simple_object_coff_write_filehdr_bigobj): New function.
(simple_object_coff_write_to_file): Add logic for writing
BigObj vs regular COFF format with appropriate symbol
and auxiliary entry structures.
Signed-off-by: Peter Damianov <peter0x44@disroot.org>
Signed-off-by: Jonathan Yong <10walls@gmail.com>
commit aef88b83384976e96a8fb287a001588a2277ecd5
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Thu Oct 2 08:53:45 2025 +0800
binutils/GCC: Quote ${COMPILER_FOR_TARGET}
Replace
if test x${COMPILER_FOR_TARGET} = x"\$(CC)"; then
with
if test x"${COMPILER_FOR_TARGET}" = x"\$(CC)"; then
since COMPILER_FOR_TARGET may contain spaces when configuring GCC.
commit 76a693c087c30e8108852928c717399011c6166d
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Sep 30 11:23:58 2025 +0800
binutils: Use AC_TRY_COMPILE to check target clang/gcc
Use AC_TRY_COMPILE to check for the working target clang and gcc when
configuring for cross tools.
commit 77c74294bfc5005204a2de3cc64bbdb2f877be29
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Fri Sep 26 08:03:01 2025 +0800
binutils: Pass target plugin file to target ar/nm/ranlib
There are 2 kinds of binutils tests:
1. Tests of binutils object files and libraries using the build tools,
like CC, AR, NM and RANLIB.
2. Tests of binutils programs as the target tools, like CC_FOR_TARGET,
AR_FOR_TARGET, NM_FOR_TARGET and RANLIB_FOR_TARGET.
Set AR_PLUGIN_OPTION_FOR_TARGET, NM_PLUGIN_OPTION_FOR_TARGET and
RANLIB_PLUGIN_OPTION_FOR_TARGET to the target compiler plugin file for
target ar/nm/ranlib.
commit 10deea6e2fc1b9ec5818b5fa1bc510c63ff5b2e2
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Sep 23 04:24:00 2025 +0800
Binutils/GCC: Add clang LTO support to AR, NM and RANLIB
Add CLANG_PLUGIN_FILE to find the clang plugin file and pass it to
--plugin for ar, nm and ranlib so that binutils can be built with
clang LTO. Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION since
GCC_PLUGIN_OPTION may return the wrong PLUGIN_OPTION with clang.
commit 1fcb94ed750db2ac30d0f0ecc04fa0c7833dd10f
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Thu Sep 18 16:17:14 2025 +0200
Remove remnants of Solaris/PowerPC support
When removing Solaris/PowerPC support, I missed a couple of references.
This patch removes them.
Tested with crosses to ppc-unknown-linux-gnu and powerpc-ibm-aix7.
ChangeLog:
* Makefile.in: Regenerated.
* configure: Likewise.
* Makefile.tpl: Synced from binutils-gdb.
* configure.ac: Likewise.
* libtool.m4: Likewise.
config/ChangeLog:
* clang-plugin.m4: Synced from binutils-gdb.
* gcc-plugin.m4: Likewise.
libbacktrace/ChangeLog:
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
libiberty/ChangeLog:
* aclocal.m4: Regenerated.
* configure: Likewise.
* configure.ac: Synced from binutils-gdb.
zlib/ChangeLog:
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
We currently list P2115R0 as implemented, but only the modules changes
had been done. This patch implements the linkage changes so that
unnamed unscoped enums will use the name of the first enumerator for
linkage purposes.
This is (strictly speaking) a breaking change, as code that previously
relied on unnamed enumerations being internal linkage may have overloads
using those types become exposed and clash with other functions in a
different TU that have been similarly exposed. As such this feature is
only implemented for C++20.
No ABI flag warning is provided, partly because C++20 is still an
experimental standard, but also because any affected functions could not
have been part of an ABI until this change anyway.
A number of testcases that are testing for behaviour of no-linkage types
are adjusted to use an enumeration with no values, so that the pre-C++20
and post-C++20 behaviour is equivalently tested.
In terms of implementation, I had originally considered adjusting the
DECL_NAME of the enum, as with 'name_unnamed_type', but this ended up
being more complicated as it had unwanted interactions with the existing
modules streaming and with name lookup and diagnostic messages. This
patch instead uses a new function to derive this case.
The standard says that ([dcl.enum] p11) such an enum "...is denoted, for
linkage purposes, by its underlying type and its first enumerator", so
we need to add a new mangling production as well to handle this.
PR c++/120503
PR c++/120824
gcc/cp/ChangeLog:
* cp-tree.h (TYPE_UNNAMED_P): Adjust for enums with enumerators
for linkage purposes.
(enum_with_enumerator_for_linkage_p): Declare.
* decl.cc (name_unnamed_type): Adjust assertions to handle enums
with enumerators for linkage purposes.
(grokdeclarator): Use a typedef name for enums with enumerators
for linkage purposes.
(enum_with_enumerator_for_linkage_p): New function.
(finish_enum_value_list): Reset type linkage for enums with
enumerators for linkage purposes.
* mangle.cc (write_unnamed_enum_name): New function.
(write_unqualified_name): Handle enums with enumerators for
linkage purposes.
* tree.cc (decl_linkage): Fixup unnamed enums.
gcc/testsuite/ChangeLog:
* g++.dg/abi/mangle32.C: Remove enumerator list.
* g++.dg/cpp0x/linkage2.C: Likewise.
* g++.dg/ext/vector26.C: Likewise.
* g++.dg/other/anon3.C: Likewise.
* g++.dg/abi/mangle83.C: New test.
* g++.dg/modules/enum-15_a.C: New test.
* g++.dg/modules/enum-15_b.C: New test.
include/ChangeLog:
* demangle.h (enum demangle_component_type): Add enumeration
DEMANGLE_COMPONENT_UNNAMED_ENUM.
libiberty/ChangeLog:
* cp-demangle.c (d_unnamed_enum): New function.
(d_unqualified_name): Call it.
(cplus_demangle_type): Handle unscoped unnamed types
(Ue, Ul, etc.)
(d_count_templates_scopes): Handle unnamed enums.
(d_find_pack): Likewise.
(d_print_comp_inner): Print unnamed enums.
* testsuite/demangle-expected: Add tests.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
This patch fixes a comment typo, whaever -> whatever, prompted by the
recent hae -> has typo fix.
2025-08-13 Jakub Jelinek <jakub@redhat.com>
* cp-demangle.c (d_encoding): Fix a comment typo, whaever -> whatever.
When the doubly-linked list tests were introduced, the tests were
printing the content of the list forward and backward. However, this
printing is not needed outside of debugging, and confuses people because
the output is not only composed of PASS: lines.
This patch disables the printing of the list content by default. If
one wants to re-enable it for debugging, he can set the macro DUMP_LIST
to 1.
libiberty/ChangeLog:
* testsuite/test-doubly-linked-list.c: disable debug logging on
stdout.
Those methods's implementation is relying on duck-typing at compile
time.
The structure corresponding to the node of a doubly linked list needs
to define attributes 'prev' and 'next' which are pointers on the type
of a node.
The structure wrapping the nodes and others metadata (first, last, size)
needs to define pointers 'first', and 'last' of the node's type, and
an integer type for 'size'.
Mutative methods can be bundled together and be declarable once via a
same macro, or can be declared separately. The merge sort is bundled
separately.
There are 3 types of macros:
1. for the declaration of prototypes: to use in a header file for a
public declaration, or as a forward declaration in the source file
for private declaration.
2. for the declaration of the implementation: to use always in a
source file.
3. for the invocation of the functions.
The methods can be declared either public or private via the second
argument of the declaration macros.
List of currently implemented methods:
- LINKED_LIST_*:
- APPEND: insert a node at the end of the list.
- PREPEND: insert a node at the beginning of the list.
- INSERT_BEFORE: insert a node before the given node.
- POP_FRONT: remove the first node of the list.
- POP_BACK: remove the last node of the list.
- REMOVE: remove the given node from the list.
- SWAP: swap the two given nodes in the list.
- LINKED_LIST_MERGE_SORT: a merge sort implementation.
include/ChangeLog:
* doubly-linked-list.h: New file.
libiberty/ChangeLog:
* Makefile.in: Add new header.
* testsuite/Makefile.in: Add new test.
* testsuite/test-doubly-linked-list.c: New test.
Fixes this error during build of fixincludes:
In function ‘byte_regex_compile’,
inlined from ‘xregcomp’ at ../libiberty/../../libiberty/regex.c:7973:11:
../libiberty/../../libiberty/regex.c:3477:29: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
3477 | str[c1] = '\0';
| ^
../libiberty/../../libiberty/regex.c: In function ‘xregcomp’:
../libiberty/../../libiberty/regex.c:3454:35: note: at offset 128 into destination object ‘str’ of size 128
3454 | unsigned char str[128]; /* Should be large enough. */
| ^
* regex.c (regex_compile): Don't write beyond array bounds when
collecting range expression.
This adds an implementation of memrchr to libiberty and arranges
to configure gcc to use it, if the host does not have it.
PR cobol/119283
gcc/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for host memrchr.
include/ChangeLog:
* libiberty.h (memrchr): New.
libiberty/ChangeLog:
* Makefile.in: Add memrchr build rules.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for memrchr.
* functions.texi: Document memrchr.
* memrchr.c: New file.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
Darwin and Solaris, at least, provide basename() in libc, but only
declare it in <libgen.h>. That library is not one of the set in
AC_INCLUDES_DEFAULT and so we fail the config test and fall back
to the libiberty-provided version. In itself, this is not an
issue; however, if we include <libgen.h> and libiberty.h in the same
TU we do then get a decl conflict.
PR other/119218
libiberty/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Append <libgen.h> to AC_INCLUDES_DEFAULT
when checking for the 'basename' decl.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
This patch adds a function ldirname to libiberty. It is implemented
in terms of lbasename. Basically, given a given pathname, the dirname
part is what is not the basename minus the last directory separator
separating the dirname with the basename.
include/ChangeLog
* libiberty.h (ldirname): New function declaration.
(dos_ldirname): Likewise.
(unix_ldirname): Likewise.
libiberty/ChangeLog
* ldirname.c: New file.
* Makefile.in (CFILES): Add ldirname.c.
(REQUIRED_OFILES): Add ldirname.$(objext).
(./ldirname.$(objext)): New rule.
* makefile.vms (OBJS): Add ldirname.obj.
* configure.com (FILES): Add ldirname.
libiberty/getopt.c file is defining _NO_PROTO, which causes
conflicting declarations for the functions in AIX header files
like stdio.h & stdlib.h.
Looks like _NO_PROTO define were added long back and conflicting
declarations were always present until C23 standard uncovered it.
Remove the block defining _NO_PROTO as both Tru64 UNIX (ex-OSF/1)
and AIX 3.2 is no more supported.
libiberty/ChangeLog:
* getopt.c: Remove _NO_PROTO block
Some of the function definitions used K&R style definitions (but not all).
This just moves them all to be ANSI C
Bootstrapped and tested on x86_64-linux-gnu.
libiberty/ChangeLog:
* testsuite/test-demangle.c (get_line): Change K&R style
definition into ANSI C90 definitions.
(fail): Likewise.
(main): Likewise.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
These comment typos were found in the valgrind fork of libiberty
demangle code.
libiberty/ChangeLog:
* cplus-dem.c: Change preceeded to preceded.
include/ChangeLog:
* safe-ctype.h: Change accidently to accidentally.
