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.