mold used to emit a spurious "recompile with -fPIC" error when creating
a position-dependent executable. This is because we alwyas create
dynamic relocations for importe symbols. If the relocated place is
read-only, we can't apply a dynamic relocation, and we printed out the
error message.
This patch fixes the issue by creating copy relocations and PLTs for
such symbols.
Fixes https://github.com/rui314/mold/issues/116
475a250ad4 changed mold's behavior on
weak undefined symbols, so that if they are not resolved within the
current ELF module, they are resolved to address zero. Previously,
they would be promoted to dynamic symbols to give then another chance
to be resolved at runtime.
That change caused a regression in Firefox. Firefox uses weak undef
symbols as a mean to export symbols from libxul.so. Quote from
Firefox's mfbt/Types.h:
> On linux mozglue is linked in the program and we link libxul.so with
> -z,defs. Normally that causes the linker to reject undefined references in
> libxul.so, but as a loophole it allows undefined references to weak
> symbols. We add the weak attribute to the import version of the MFBT API
> macros to exploit this.
So, they use this as a "loophole".
This change partially revert 475a250ad4.
Now, remaining weak undefs are resolved to address zero only when we
are creating an executable.
Fixes https://github.com/rui314/mold/issues/114
We sometimes put local symbols into .dynsym, but if they are
global symbols hidden by a version script, they were exported
from .dynsym. This patch correctly makes them local symbols.
Previously, we try to promote unresolved weak undefined symbols to
dynamic symbols so that they will get another chance to be resolved at
runtime. This is not always doable. Consider the following two cases:
- There's a relocation that directly refers a weak undefined symbol
- There's a relocation that is in a read-only section
In the former case, we need to create a copy relocation, but we can't
do that against a weak undef becasue a weak undef doesn't have the notion
of the symbol size.
In the latter case, we need to create a dynamic relocation, but such
dynamic relocation would fail at load-time when the runtime linker tries
to mutate the contents of a read-only section.
So, we had a logic to detect the above cases and promote weak undefs
only when they can be promoted. But the logic is not as robust as I
hoped. So, in this patch, I removed the logic and stop promoting weak
undefs.
We shouldn't create TLSDESC dynamic relocations for statically-
linked executables because such executables don't contain the
tranpoline function needed for TLSDESC. Instead, we should
always relax these relocations.
We used to write only global symbols to .dynsym because, in most
use cases, .dynsym are used for resolving inter-module dependencies.
However, we need to put local symbols to .dynsym if they are thread-
local symbols.
Previously, we created dynamic relocations against read-only sections
if the sections contain relocations against weak undefined symbols.
Since such dynamic relocations cannot be applied at load-time, the
generated executables failed with SEGV.
Now, such relocations are resolved to address 0.
Reported at https://github.com/rui314/mold/pull/110
Previously, only /usr/bin/ld, /usr/bin/ld.lld and /usr/bin/ld.gold
were intercepted. Now, mold ignores the directory part when comparing
a command name with `ld`, `ld.lld` or `ld.gold`.
This change is made because ld is often installed other than /usr/bin.
Fixes https://github.com/rui314/mold/issues/101
You can now build mold with the following commands:
$ mkdir -p out/debug
$ cd out/debug
$ cmake -GNinja -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Debug ../..
$ ninja
To run tests, use the following commands:
$ cd out/debug
$ ctest -j$(nproc)
Previously, a GOT relocation (e.g. R_X86_64_REX_GOTPCRELX) and a
R_X86_64_64 relocation referring the same imported symbols were
resolved to different addresses. Here is why:
- When we saw a R_X86_64_64 relocation against an imported symbol,
we created a PLT and resolve the relocation there.
- GOT relocation is resolved to a GOT entry, which has a true
address of an imported function at runtime, which is different
from PLT entries that redirect calls to the real function.
With this patch, we no longer create a PLT entry for R_X86_64_64.
Instead, we emit a dynamic relocation so that it is always resolved
to a real function address.
Fixes GNU MP's `make check` failure, which was reported at
https://github.com/rui314/mold/issues/81
The grammar of the command is this
VERSION { <version-script> }
where <version-script> is a version script you can specify with
the --version-script option.
The default size and offsets of the .dynamic section are not necessarily
same with different builds of clang. For example, some builds can make
clang pass --hash-style=gnu to the linker and some --hash-style=both.
This change updates the test to compute the difference in size of the
.dynamic section before and after using the flag -spare-dynamic-tags,
making it independent of the compiler build.
Signed-off-by: Nehal J Wani <nehaljw.kkd1@gmail.com>
mold: /__w/mold/mold/test/tmp/pie/a.o:(.text): R_X86_64_32 relocation
against symbol `.rodata' can not be used; recompile with -fPIE
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Signed-off-by: Nehal J Wani <nehaljw.kkd1@gmail.com>
Previously, if a weak undefined symbol cannot be resolved within
an output of the linker, mold turned it into an absolute symbol
with value 0. However, other linkers export such symbols as a
weak dynamic symbol, so that the symbol gets another chance to be
resolved at runtime.
This patch implements the behavior.
This is needed by Gentoo's dev-libs/nsync-1.20.1 package.
This is needed by Gentoo's dev-lang/spidermonkey-78.10.1 package,
as its configure script assumes that the linker exit normally
even if extra options are given after `--version`.
We should not set STT_GNU_IFUNC to symbols in .dynsym because
from the other ELF module's point of view, it doens't matter
whether a symbol is IFUNC or not.
This is needed by Gentoo's sci-mathematics/nauty-2.6.7 package.
mmap(2) fails if you pass 0 as an argument for `length` parameter,
so this case has to be handled as a special case.
This is needed by Gentoo's media-plugins/calf-0.90.3-r1 package.
In other words, a linker shouldn't pull out an object file from an
archive to resolve an existing undefined or a common symbol with a
common symbol.
This is needed by Gentoo's app-arch/dump-0.4.47 package.
Previously, we turned unresolved undefined symbols into dynamic
symbols. This patch changed the behavior so that such symbols
are turned into non-dynamic absolute symbols with value zero.
This change is needed by Gentoo's dev-libs/wayland-protocols-1.21
package.
If an object file in an static archive contains a common symbol
that can be used to resolve an undefined symbol, mold now pulls
out that object file from the archive. Previously, we ignore such
common symbols.
Object files generated by a Fortran compiler often contain a lot of
common symbols, and this change makes a difference.
Fixes Gentoo's sci-astronomy/wcslib-7.3 package, which contains a
program written in Fortran.
This change is needed to build Gentoo's dev-lang/gprolog-1.4.5,
which is the GNU Forth package. GNU Forth creates ELF objects
itself, and it still uses .ctors and .dtors as opposed to .init_array
and .fini_array.
Previously, mold couldn't handle an object file which contains
versioned symbol `foo@@SOME_VERSION` that also has an undefined
symbol `foo`. Now, `foo` is resolved to `foo@@SOME_VERSION`.
This change is required to build Gentoo's media-libs/alsa-lib-1.2.3.2-r1
package.
The configure script in Gentoo's dev-libs/jansson-2.13.1-r1 package
treats mold 0.1.1 as GNU ld 0.1.1, which is from 1980s if existed.
Adding "GNU gold" to the help message solves the nasty issue, as the
configure script considers any version of GNU gold supports modern
features.
