Add newly released mold version 2.33.0 from upstream
https://github.com/rui314/mold
New features
- mold gained a new linker flag --separate-debug-file to bundle debug
info sections into a separate file instead of putting them into a main
output file. You can optionally specify a filename in the form of
--separate-debug-file=<filename>. By default, a debug info file is
created in the same directory as the main output file with the .dbg
extension. mold embeds the debug file's filename into the main output
file so that gdb can automatically follow the link to find debug info
when debugging the main output file.
- The main objective of this flag is to speed up the mold linker even
more. By default, mold creates a separate debug file in the background
after creating a main output file, so that you can start running the
executable as soon as possible while mold is still working on linking
its debug info sections. For example, linking clang with debug info
normally takes ~1.70s on a Threadripper 7980X machine, while it takes
only ~0.52s with --separate-debug-info. Shaving off a full second in
quick edit-rebuild-run cycles should improve programmers'
productivity. If you do not want mold to work in the background, pass
the --no-detach option. (596ffa9)
- mold now supports the --no-allow-shlib-undefined flag. If the option
is given, mold checks if all undefined symbols are resolved not only
for input object files but also for shared libraries passed to the
linker. To use the feature, you need to pass all shared libraries,
including transitively dependent ones, to the linker so that the
linker can resolve all symbols that are available at runtime.
(3001f02)
- mold gained the --dynamic-list-data flag for the sake of compatibility
with GNU ld. If the flag is given, all data symbols are exported as
dynamic symbols. (dd8d971)
- [x86-64] -z x86-64-v2, -z x86-64-v3, -z x86-64-v4 flags are supported.
(5606087)
Bug fixes and compatibility improvements
- [x86-64] Recent x86-64 processors support Intel CET to protect control
flow integrity. When the feature is enabled, the instruction that is
executed immediately after an indirect branch must be endbr64 or a CPU
fault will raise. In other words, it restricts the locations where the
control can transfer to with indirect branches. Doing that makes ROP
attacks harder to conduct.
- A problem with that is the compiler needs to conservatively emit an
endbr64 at the beginning of each global function because the compiler
doesn't know whether or not the function's address is taken in other
translation units. As a result, the resulting binary contains more
endbr64s than necessary, weakening the protection.
- mold supports the -z rewrite-endbr option to conduct a whole program
analysis and rewrite endbr64 with nop if a function's address is not
actually taken within the program. Previously, mold didn't take
section symbols into account when conducting the analysis, which
resulted in culling some endbr64s that must not be removed. Now, the
bug has been fixed. We confirmed that mold can build itself with -z
rewrite-endbr, and the resulting mold executable works fine with Intel
CET. (ed7eec5)
- mold now creates a .eh_frame section even if it's empty. (14a4b05)
- [LoongArch] The following relocations are now supported:
R_LARCH_TLS_LE_HI20_R, R_LARCH_TLS_LE_ADD_R, R_LARCH_TLS_LE_LO12_R,
R_LARCH_CALL36, R_LARCH_RELAX (36e5b4b, 98a7cff, 2c6f379)
- [LoongArch] Some relaxations that reduce the section size are now
supported. (74b359f, 121f917)
- [LoongArch] Range extension thunk support has been removed in favor of
R_LARCH_CALL36 relocations. (47c092a)
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Since commit 16c6cc99 ("Save the toolchain configuration to its own
file, as an auto-extracting shell script:") we've been saving the
configuration as a self extracting script. This is a little non-obvious
as it looks like it should be a regular file but the bzipped payload
means it can be easily inspected. It may also cause alarm for users who
should rightly be suspicious of unexpected binaries that get shipped
along with packaged toolchains. It also assumes that bzip2 (or at least
bzcat) is available on the machine running the toolchain.
Instead of the self extracting shell script save the config as a regular
compressed file with an obvious file extension.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
gold uses g++ to link which doesn't recognise -all-static. It appears as
if -static should work for both libtool and g++ but for some reason it
doesn't. Remove the restriction that gold can't be included in a static
toolchain. When a static toolchain is requested pass
--with-gold-ldflags=--static to configure. Finally build gold separately
so it does not get the extra_make_flags which may contain -all-static.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Based on the configure.ac for binutils it appears that arm, loongarch,
mips, powerpc, s390, sparch and x86 are supported. Expand the list of
architectures that gold is allowed to be used on.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
https://sourceware.org/pipermail/gdb-announce/2024/000140.html
The release notes state that "Building GDB and GDBserver now requires a
C++17 compiler (for instance, GCC 9 or later)". Looks like we already
satisfy this requirement with GDB_DEP_NO_STD_FUTURE.
gdbserver now has a dependency on iconv.h, for uclibc configurations we
need to make sure this is satisfied.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Support for Oracle Linux toolchains have some repetition within their
package directories.
This patch improves the status of package directories and patch reusability.
Signed-off-by: Cupertino Miranda <cupertino.miranda@oracle.com>
Add newly released mold version 2.32.0 from upstream
https://github.com/rui314/mold
New features
- mold supports a feature called Identical Code Folding, or ICF. As the
name suggests, ICF finds identical functions and merges them to reduce
the size of an output file. This is especially effective for
template-heavy C++ programs since templates tend to be instantiated to
the same machine code for different types. For example,
std::vector<int> is likely to be instantiated to the same code as
std::vector<unsigned>. We've made an improvement to our ICF algorithm
so that the --icf feature is ~50% faster than the previous version.
(fa8e95a)
- The -z rodynamic option is now supported for compatibility with LLVM
lld. With the option, mold places the .dynamic section into a
read-only segment. (9a233df)
Bug fixes and compatibility improvements
- Previously, mold behaved differently compared to other linkers if both
-z defs and --undefined=ignore-in-object-files were given (#1270).
Now, they override each other so that the mold's behavior is
compatible with others. (8cd85aa)
- Previously, --dependency-file mistakenly recorded response files as
dependencies (#1258). This bug has been fixed. (4281f45)
- There was a bug that mold corrupted debug info section contents when
the --relocatable option was given (#1265). This issue has been fixed.
(08b0a16)
- [PPC64] The R_PPC64_TPREL16_LO_DS relocation type is supported.
(a8cd2e8)
- [ARM64, PPC64, LoongArch] mold 2.31.0 or earlier may have failed with
an assertion failure when creating a large output file (#1224). This
issue has been resolved. (c7c8583)
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Allows building the #mold linker, which can then be used in the
cross-toolchain by passing the -fuse-ld=mold to the gcc flags. It is
much faster than ld or gold.
This requires a C++20 compiler and cmake.
Initially implemented by Arnaud, and HC added configure check for cmake.
Outstanding task to validate compiler is C++20 compatible.
Signed-off-by: Arnaud Vrac <avrac@freebox.fr>
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Both D and GNAT have their own runtimes (resp. libphotos and libada).
It is still possible to build the compiler proper without any runtime,
and have an external runtime installed later. This is most commonly
found in embedded systems.
An example for D is: https://github.com/KitsunebiGames/tinyd-rt
An example for Ada: https://github.com/Fabien-Chouteau/bare_runtime
Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
Musl was marked experimental in commit 08d91d41 ("musl: config is broken
for !EXPERIMENTAL"). Most of the reasoning for that change no longer
applies and as it's been about 8 years it's time to let musl loose on
the world. Drop the `depends on EXPERIMENTAL` and update the sample
configs for aarch64 and x86_64.
For powerpc64 the ABI needs to be elfv2. Enforce this via the powerpc
config. Add a sample configuration for powerpc-unknown-linux-musl.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
GCC14 will treat implicit-function-declaration as an error by default.
See https://gcc.gnu.org/gcc-14/porting_to.html for details.
Some libc function like __trap34 are defined in assembly and break this GCC diagnostic.
Signed-off-by: Nik Konyuchenko <spaun2002mobile@gmail.com>
GCC14 has started to complain about sloppily written configure tests.
Update them so the code snippet is valid according to GCC14.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Current glibc versions don't compile without warnings with GCC14.
Disable -Werror for glibc when using GCC14.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
+ gcc 14 package version
+ tar.gz and tar.xz checksums
+ patches from gcc13 that can still be applied to gcc14
Signed-off-by: Nik Konyuchenko <spaun2002mobile@gmail.com>
Resolve the following build error for arc-multilib-linux-uclibc.
libc/sysdeps/linux/common/fstat64.c: In function 'fstat64':
libc/sysdeps/linux/common/fstat64.c:33:38: error: passing argument 2 of '__syscall_fstat64' from incompatible pointer type [-Wincompatible-pointer-types]
33 | return __syscall_fstat64(fd, buf);
| ^~~
| |
| struct stat64 *
While we're at it bring in one more bug fix patch from upstream.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The libpthread-drop-protected-attribute patch was added in error because
I had it applied locally when grabbing the upstream changes. Remove it
now.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Add the 1.0.48 and some additional patches from master which include
some fixes for GCC 14 support.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
macos-latest has recently (as of April 2024) started transitioning to
macos-14 (previously it was macos-12). This seems to be missing things
we rely on (e.g. makeinfo) and even when those are added throws other
errors. For now lets pin things to macos-12 until someone can spend
some time looking at why we can't use macos-14.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Wildcard is an opt-in (disabled by the default) feature that is used by many GNU tools like Binutils.
Signed-off-by: Mateusz Mikuła <mati865@gmail.com>
Code added to deal with --enable-local used the non-existent CT_Error
instead of CT_Abort. Use the correct function so the build aborts with a
useful error message.
Fixes#2141
Signed-off-by: Chris Packham <judge.packham@gmail.com>
* Run `apt-get update` before installing packages, as the local VM may
not have these packages already installed like the github.com runners
do.
* Add bison, flex, and texinfo, as they may not already be on the local
VM as they may be on the github.com runners.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
The native gdb needs the version of libexpat built for the target. On
some systems gdb's configure will find the one from the build machine.
Use --with-expat= to point at the correct one for the target.
Fixes: 2092
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Add the new release and rebase the local patches. Add a new patch which
resolves a build issue on macOS.
https://sourceware.org/pipermail/binutils/2024-January/132213.html
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
In canadian builds, the target toolchain running on the build
machine is not compiling and installing target Newlib. Thus it
cannot by itself link target executables. This results in
errors for gnuprumcu package when its configure script attempts
to test the compiler:
.../ld: cannot find crt0.o: No such file or directory
configure:3738: error: C compiler cannot create executables
Fix by passing the host toolchains's sysroot in target CFLAGS.
While at it, also add a missing passing of target LDFLAGS.
Successfully tested the following canadian builds:
x86_64-unknown-linux-gnu,pru
x86_64-w64-mingw32,pru
arm-unknown-linux-gnueabihf,pru
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
The canadian cross builds are hitting the disk space limit on the free
tier github runners. For now disable them.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This patch adds two gcc commits to fix musl libdir path for loongarch64:
* 13c5de14 ("LoongArch: Fix MUSL_DYNAMIC_LINKER")
* a5f1bdfc ("LoongArch: Modify MUSL_DYNAMIC_LINKER.")
* 2f7d4728 ("LoongArch: Use /lib instead of /lib64 as the library search path for MUSL.")
Signed-off-by: WANG Rui <wangrui@loongson.cn>
