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.
cp-demangle.c does not build when CP_DEMANGLE_DEBUG is defined since
r13-2887-gb04208895fed34. This trivial patch fixes the issue.
libiberty/ChangeLog:
* cp-demangle.c (d_dump): Fix compilation when CP_DEMANGLE_DEBUG
is defined.
cat abc.C
#define A(n) struct T##n {} t##n;
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7) A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7) B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7) C(n##8) C(n##9)
#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7) D(n##8) D(n##9)
E(1) E(2) E(3)
int main () { return 0; }
./xg++ -B ./ -o abc{.o,.C} -flto -flto-partition=1to1 -O2 -g -fdebug-types-section -c
./xgcc -B ./ -o abc{,.o} -flto -flto-partition=1to1 -O2
(not included in testsuite as it takes a while to compile) FAILs with
lto-wrapper: fatal error: Too many copied sections: Operation not supported
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
The following patch fixes that. Most of the 64K+ section support for
reading and writing was already there years ago (and especially reading used
quite often already) and a further bug fixed in it in the PR104617 fix.
Yet, the fix isn't solely about removing the
if (new_i - 1 >= SHN_LORESERVE)
{
*err = ENOTSUP;
return "Too many copied sections";
}
5 lines, the missing part was that the function only handled reading of
the .symtab_shndx section but not copying/updating of it.
If the result has less than 64K-epsilon sections, that actually wasn't
needed, but e.g. with -fdebug-types-section one can exceed that pretty
easily (reported to us on WebKitGtk build on ppc64le).
Updating the section is slightly more complicated, because it basically
needs to be done in lock step with updating the .symtab section, if one
doesn't need to use SHN_XINDEX in there, the section should (or should be
updated to) contain SHN_UNDEF entry, otherwise needs to have whatever would
be overwise stored but couldn't fit. But repeating due to that all the
symtab decisions what to discard and how to rewrite it would be ugly.
So, the patch instead emits the .symtab_shndx section (or sections) last
and prepares the content during the .symtab processing and in a second
pass when going just through .symtab_shndx sections just uses the saved
content.
2024-09-07 Jakub Jelinek <jakub@redhat.com>
PR lto/116614
* simple-object-elf.c (SHN_COMMON): Align comment with neighbouring
comments.
(SHN_HIRESERVE): Use uppercase hex digits instead of lowercase for
consistency.
(simple_object_elf_find_sections): Formatting fixes.
(simple_object_elf_fetch_attributes): Likewise.
(simple_object_elf_attributes_merge): Likewise.
(simple_object_elf_start_write): Likewise.
(simple_object_elf_write_ehdr): Likewise.
(simple_object_elf_write_shdr): Likewise.
(simple_object_elf_write_to_file): Likewise.
(simple_object_elf_copy_lto_debug_section): Likewise. Don't fail for
new_i - 1 >= SHN_LORESERVE, instead arrange in that case to copy
over .symtab_shndx sections, though emit those last and compute their
section content when processing associated .symtab sections. Handle
simple_object_internal_read failure even in the .symtab_shndx reading
case.
After the commit:
commit 5e1d530da8 (gcc-buildargv)
Date: Sat Feb 10 11:22:13 2024 +0000
libiberty/buildargv: handle input consisting of only white space
The function only_whitespace (in argv.c) was no longer being called.
Lets delete it.
There should be no user visible changes after this commit.
2024-07-29 Andrew Burgess <aburgess@redhat.com>
libiberty/
* argv.c (only_whitespace): Delete.
GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.
I have recently been working to improve this area of GDB, and noticed
some unexpected behaviour to the libiberty function buildargv, when
the input is a string consisting only of white space.
What I observe is that if the input to buildargv is a string
containing only white space, then buildargv will return an argv list
containing a single empty argument, e.g.:
char **argv = buildargv (" ");
assert (*argv[0] == '\0');
assert (argv[1] == NULL);
We get the same output from buildargv if the input is a single space,
or multiple spaces. Other white space characters give the same
results.
This doesn't seem right to me, and in fact, there appears to be a work
around for this issue in expandargv where we have this code:
/* If the file is empty or contains only whitespace, buildargv would
return a single empty argument. In this context we want no arguments,
instead. */
if (only_whitespace (buffer))
{
file_argv = (char **) xmalloc (sizeof (char *));
file_argv[0] = NULL;
}
else
/* Parse the string. */
file_argv = buildargv (buffer);
I think that the correct behaviour in this situation is to return an
empty argv array, e.g.:
char **argv = buildargv (" ");
assert (argv[0] == NULL);
And it turns out that this is a trivial change to buildargv. The diff
does look big, but this is because I've re-indented a block. Check
with 'git diff -b' to see the minimal changes. I've also removed the
work around from expandargv.
When testing this sort of thing I normally write the tests first, and
then fix the code. In this case test-expandargv.c has sort-of been
used as a mechanism for testing the buildargv function (expandargv
does call buildargv most of the time), however, for this particular
issue the work around in expandargv (mentioned above) masked the
buildargv bug.
I did consider adding a new test-buildargv.c file, however, this would
have basically been a copy & paste of test-expandargv.c (with some
minor changes to call buildargv). This would be fine now, but feels
like we would eventually end up with one file not being updated as
much as the other, and so test coverage would suffer.
Instead, I have added some explicit buildargv testing to the
test-expandargv.c file, this reuses the test input that is already
defined for expandargv.
Of course, once I removed the work around from expandargv then we now
do always call buildargv from expandargv, and so the bug I'm fixing
would impact both expandargv and buildargv, so maybe the new testing
is redundant? I tend to think more testing is always better, so I've
left it in for now.
2024-07-16 Andrew Burgess <aburgess@redhat.com>
libiberty/
* argv.c (buildargv): Treat input of only whitespace as an empty
argument list.
(expandargv): Remove work around for intput that is only
whitespace.
* testsuite/test-expandargv.c: Add new tests 10, 11, and 12.
Extend testing to call buildargv in more cases.
GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.
I have recently been working to improve this area of GDB, and have
tracked done some of the unexpected behaviour to the libiberty
function buildargv, and how it handles backslash escapes.
For reference, I've been mostly reading:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
The issues that I would like to fix are:
1. Backslashes within single quotes should not be treated as an
escape, thus: '\a' should split to \a, retaining the backslash.
2. Backslashes within double quotes should only act as an escape if
they are immediately before one of the characters $ (dollar),
` (backtick), " (double quote), ` (backslash), or \n (newline). In
all other cases a backslash should not be treated as an escape
character. Thus: "\a" should split to \a, but "\$" should split to
$.
3. A backslash-newline sequence should be treated as a line
continuation, both the backslash and the newline should be removed.
I've updated libiberty and also added some tests. All the existing
libiberty tests continue to pass, but I'm not sure if there is more
testing that should be done, buildargv is used within lto-wraper.cc,
so maybe there's some testing folk can suggest that I run?
2024-07-16 Andrew Burgess <aburgess@redhat.com>
libiberty/
* argv.c (buildargv): Backslashes within single quotes are
literal, backslashes only escape POSIX defined special characters
within double quotes, and backslashed newlines should act as line
continuations.
* testsuite/test-expandargv.c: Add new tests 7, 8, and 9.
Investigating GDB PR d/31580 showed that the libiberty demangler
doesn't automatically demangle D mangled names. However, I think it
should -- like C++ and Rust (new-style), D mangled names are readily
distinguished by the leading "_D", and so the likelihood of confusion
is low. The other non-"auto" cases in this code are Ada (where the
encoded form could more easily be confused by ordinary programs) and
Java (which is long gone, but which also shared the C++ mangling and
thus was just an output style preference).
This patch also fixed another GDB bug, though of course that part
won't apply to the GCC repository.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276
libiberty
* cplus-dem.c (cplus_demangle): Try the D demangler with
"auto" format.
* testsuite/d-demangle-expected: Add --format=auto test.
