glibc 2.22 or prior have a bug that the dynamic linker (ld-linux.so.2)
crashes on `dlopen` if .rela.dyn and .rela.plt are not contiguous in
the `dlopen`-ed file and RTLD_NOW is specified. That bug was fixed in
fa19d5c48a.
glibc 2.23 which includes the fix for the bug was released on 2016-02-18.
So, unless you are using glibc that is more than 5 years old, mold-
generated shared object files work fine with `dlopen`. But it is easy
to make the sections contiguous in file, so I'll commit this change as a
workaround for the bug.
Fixes https://github.com/rui314/mold/issues/120
Previously, mold created two or more ".rodata" sections if input files
contain regular .rodata sections as well as .rodata.str* or .rodata.cst*
sections. This is because .rodata.str* and .rodata.cst* contains mergeable
section contents (i.e. string constants and constant pools, respectively),
and they are handled in a special way.
In ELF, section names are not significant, so nothing is wrong with
creating multiple .rodata. However, valgrind unfortunately doesn't like
such executable.
With this change, mold keeps ".rodata.str" and ".rodata.cst" prefixes
to avoid creating multiple ".rodata" sections.
Fixes https://github.com/rui314/mold/issues/118
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
