It looks like setting __TBB_DYNAMIC_LOAD_ENABLED to 0 is not enough
to make TBB not to call dlopen(). We need to unset __TBB_WEAK_SYMBOLS_PRESENT
as well.
Fixes https://github.com/rui314/mold/issues/348
When building with SYSTEM_MIMALLOC=1, linking with (assuming
shared) '-lmimalloc' is not enough to override C++ new/delete
with mimalloc versions, and 'mimalloc-new-delete.h' should be
included from one (and the only) translation unit as well.
Signed-off-by: Dmitry Antipov <dantipov@cloudlinux.com>
ELF object files returned by do_lto() may contain unforeseen undefined
symbols, so we can't call that function after the symbol resolution pass
because it can cause undefined symbol errors.
In the previous commit (c325cc039a),
I argued that PC-relative relocations are not representable if they
refer absolute symbols, and I made a change so that such relocations
are handled as errors.
Even though what I did is technically correct, that results in a failure
of an important use case of the weak undefined symbol. Here is why.
If you have an weak undefined symbol `foo`, you would use it as follows:
if (foo)
foo();
If `foo` is defined (i.e. has an address other than 0), `foo` is called.
If `foo` is undefined (i.e. has the address 0), the subsequent CALL
instruction will have an offset from the CALL instruction to address 0.
That displacement is computed at link-time. If the output is position-
independent, the call instruction may not have a correct displacement
from address 0 to the instruction at runtime due to base relocation.
However, that's not a problem in practice, because the function call
is guarded by `if (foo)`, and that will always evaluated to false
if `foo` is undefined. Therefore, the faulty `CALL` instruction will
never be executed.
So, that means we need to relocate PC-relative relocations against
absolute symbols even if doing so results in an incorrect result.
This patch implement that.
PC-relative relocations against absolute symbols are not representable
in position-independent code. In order to support such relocations,
someone has to compute `S + A - P` or subtract `B` as a base relocation,
but such dynamic relocations don't exist.
This is contrary to non-PC-relative relocations against non-absolute
symbols. In this case, we can simply use the base relocation (e.g.
R_X86_64_RELATIVE).
https://github.com/rui314/mold/issues/348
It looks like the option is supported only by gold, and it doesn't
make much sense to me to have this option along with more generic
--warn-textrel. So I want to remove this before the next release.
This patch removes the --shuffle-sections option that takes an
argument as I'm still thinking about a better name for the option.
You can still use `--shuffle-sections` that doesn't take an argument.
If a relocation's r_sym value is 0 (i.e. it refers the undefined symbol
at the beginning of the symbol table), it has to handled as if S were 0.
We used to handle as if S were -1.
In addition to that, even if a relocation needs a dynamic base relocation,
it doesn't mean its expression is always S+A. For example, calling an
absolute address needs a dynamic relocation but its expression is S+A-P.
Fixes https://github.com/rui314/mold/issues/348
This reverts commit ddcb7b4197. `is_dso`
is used by hot functions such as `Symbol::get_addr()`, so we want to
eliminate the cost of virtual function dispatch.
read_lto_object is called on each archive member, so if an archive file
contains lots of members, it can exhaust the pool of file descriptors.
This patch fixes the issue by opening an archive only once.
Since compiled IR objects may contain mergeable string sections, we
don't know the estimated number of items in output mergeable sections.
Previously, we created the concurrent hash tables for output mergeable
sections before compiling IR objects, so there was a chance to see
the "concurrent hash table full" error.
This commit moves the code to add section pieces to output mergeable
sections after `do_lto`.
If the --shuffle-sections is given, mold now randomize the output by
shuffling input sections randomly. This feature is compatible with lld's
--shuffle-sections=SEED option introduced in
https://reviews.llvm.org/D74791.
This feature is useful when you want to equalize the conditions of
benchmarks. That is, some particular memory layout can produce a very
good benchmark number due to hardware-level cache hit rate or something
like that. Therefore, even if you get a good benchmark number after
changing code, there's a chance that that's caused by the layout change
and not by the new code itself. With --shuffle-sections, you can isolate
that.
The other use case I can think of is to enhance security. If you build
your program as a position-independent executable, the kernel
automatically enables ASLR (Address Space Layout Randomization), but ASLR
only shift the entire program image in memory by some random offset;
Relative offsets between sections remain the same. If you compile programs
from source, by using --shuffle-sections, you can make the offsets
unpredictable to attackers.
The LTO plugin API support is still in progress, but with this change,
mold can link itself with `-flto` with both GCC and Clang.
Since mold now supports LTO natively, I removed the fallback mechanism
to ld.bfd or ld.lld that I implemented in
a5029d19a8.
Fixes https://github.com/rui314/mold/issues/181
