If you try to link ICC-generated objects file with GCC-generated objects,
you'll get an error message that `__gxx_personality_v0` is duplicated.
This is because ICC puts a section with this symbol into a GNU linkonce
section, while GCC puts it into a COMDAT section.
ICC should stop putting that symbol into GNU linkonce because it's
superceded by COMDAT long ago.
That being said, we need to do something to make it possible to mix
ICC and GCC object files. In this patch, we simply discard the ICC-
generated section. Since `__gxx_personality_v0` is always provided by
libc (that function handles C++ exceptions), we can simply ignore ICC's
output.
Fixes https://github.com/rui314/mold/issues/271
libtbb.so contains undefined symbols on Gentoo with musl libc.
Because we are not using such symbols at runtime, and symbols are
resolved lazily, mold would work fine as long as we can build it.
By passing `-allow-shlib-undefined`, we can build mold.
Fixes https://github.com/rui314/mold/issues/281
ARM64 branch instructions have only a 25-bit displacement. Non-thumb
instructions are always aligned to 4 byte boundaries, but with that
implicit trailing two zeros considered, they can represent only a 27-bit
displacement. That means branch instructions can jump to a location only
if it is within a ±128 MiB range.
If a branch destination is farther than that, a linker has to emit machine
code sequence that constructs a full 32-bit address in a register to jump
to the final destination, and redirect the branch to that code sequence.
Such code sequence is called a "range extension thunk" or just "thunk".
Previously, mold didn't support range extension thunks, so it couldn't link
large programs. That would fail with an "relocation out of range" error.
Now, mold gained a feature to create thunks and can link large programs.
Thunk creation is an interesting algorithmic problem. We need to insert
a thunk for at least in every 128 MiB chunk, because otherwise branch
instructions wouldn't be able to jump to a thunk. Adding an entry to a thunk
could slightly enlarge the distance between a branch instruction location
and its destination if the thunk is in between them. That could make the
branch that was previously reachable unreachable.
Usually, this problem is solved by an iterative algorithm. With the
iterative algorithm, a linker check for reachability of all relocations,
create new thunks if necessary, and repeat it until no new thunks are
created.
I implemented a different algorithm than that in this patch. The algorithm
implemented in this patch is guaranteed to work in O(n) where n is the
number of relocations. This algorithm might be novel.
And the algorithm implemented in this patch is quite fast. It can create
thunks in 80 milliseconds on a 16-core Amazon Graviton 2 machine for
clang-14 that has an ~100MB .text section.
Previously, we didn't handle version scripts like this correctly:
ver {
global: *;
local: foo*;
}
We didn't handle `local:` part correctly except for `*`.
Fixes https://github.com/rui314/mold/issues/277
It should be perfectly legal to have an empty CIE along with an end-of-records
marker of FDE. /usr/lib/crtend.o from NetBSD/amd64 has the following .eh_frame
but mold emits an error for the zero-length FDE:
.section .eh_frame, "a", @progbits
.align 8
.quad 0
Signed-off-by: Masatake Daimon <pho@NetBSD.org>
GCC 7.5.0 passes these flags to ld(1). Maybe mold should handle them properly,
but since common symbols are considered to be obsolete it's probably not worth
it. At least it's better to ignore them rather than to abort.
Signed-off-by: Masatake Daimon <pho@NetBSD.org>
Some operating systems, like NetBSD, don't have a separate library for
dlopen(3). They have dl* functions in their libc.
Signed-off-by: Masatake Daimon <pho@NetBSD.org>
We try to overwrite to an existing output file if exists because
writing to a file that is already in buffer cache is much faster than
creating a new fresh file and write to it.
Previously, mold failed with the "fchmod failed" error if an existing
file is writable (so open for read-write succeeds) but owned by
someone else (so fchown fails). Now, mold ignore such existing file
and create a fresh output file.
Fixes https://github.com/rui314/mold/issues/275
A function passed to tbb::parallel_scan must be associative, but I don't
think our function satisfied that constraint. So I rewrote code without
tbb::parallel_scan.
.relr.dyn is a new section that has been implemented in other linkers
recently. That section contains only the RELATIVE-type dynamic
relocations (i.e. base relocations). Compared to the regular
.rela.dyn, a .relr.dyn's size is typically less than 1/10 because the
section is compressed.
Since PIEs (position-independent executables) tend to contain lots of
RELATIVE-type relocations and PIEs are now the default on many Linux
distributions for security reasons, .relr.dyn is more effective than
it was. It can reduce binary size by a few percent or more.
Note that the runtime support is catching up, so binaries built with
`-pack-dyn-relocs=relr` may not work on your system unless you are
running a very recent version of Linux.
I believe this pseudo member is relatively new to support archive
files larger than 4 GiB. I'm not sure if mold can handle such large
archives, but first of all, mold crashes when an archive with this
pseudo member is given.
This commit fixes the crash bug.
I don't know how to create an archive with this pseudo member, so
this commit does not have a testcase.
Reported by sina-ht at https://github.com/rui314/mold/pull/269.
