Usually, init_array is readable and writable, but it looks like rustc
with `-C lto=fat` create a read-only .init_array. mold used to create
two output .init_array sections for read/write and read-only
init_array input sections. That caused one of them are not executed
on startup.
Now, mold create read/write .init_array output section even if an
input .init_array section is read-only.
Fixes https://github.com/rui314/mold/issues/363
We used to emit the following sequence for each PLT entry.
0xf3, 0x0f, 0x1e, 0xfa, // endbr64
0xff, 0x25, 0, 0, 0, 0, // jmp *foo@GOTPLT
0xe8, 0, 0, 0, 0, // call PLT[0]
In the above instruction sequence, `jmp` was expected to jump to the
following `call` instruction if the PLT entry is executed for the
first time. However, it wouldn't work because we needed another
`endbr64` before `call`.
This problem should be fixed in this commit. Now, the PLT header is
32 bytes long and each entry is 16 bytes.
IBT-enabled PLT section is sparse as 2/3 of the section contents are
NOP instructions. In this patch, I implemented alternative instruction
sequences for IBTPLT, so that each IBTPLT entry occupies only 16 bytes
instead of 32 bytes.
In return, our new IBTPLT section needs a 64 bytes header instead of a
16 bytes one, but it's overall a good deal because we usually have many
PLT entries.
When we relax R_X86_64_TLSGD or R_X86_64_TLSGD, we rewrite two
instructions (the one referred by TLSGD/TLSLD and the following one
referred by the following relocation). The second instruction is
usually 5 bytes, but if it can be longer than that, and if that's the
case, we need to emit a nop to fill the gap at the end of the longer
instruction.
We didn't do that. As a result, the remaining garbage of the second
instruction is executed and caused an unpredictable result (illegal
instruction or segv).
This patch fixes the issue.
Fixes https://github.com/rui314/mold/issues/360
This option reverse input sections before assigning offsets to them.
This is useful to detect an unintended dependency between static
initializers in different translation units. C++ only guarantees that
static initializers are invoked from top to bottom in a single
translation unit, and it doesn't guaratee anything about the order of
initialization between translation units.
By (partially) reversing the contents of .init_array using
--reverse-sections, you can run your program with a completely
reversed initialization order.
The test expects an error when an object compiled with `-fno-PIC` is
linked with `-pie`, but that doesn't happen on aarch64.
Signed-off-by: Christoph Erhardt <github@sicherha.de>
This commit removes build-static.sh because statically-linked mold
executable can't generally dlopen a shared library and therefore can't
load the linker LTO plugin.
Now, build-dynamic.sh is renamed dist.sh and recommended for general
use.
I think we don't need to create a tar file for binary distribution
for each Linux distro. Instead, we can create mold executable that
works on most Linux machines.
The new script, build-dynamic.sh, creates a mold executable with
libmimalloc, libtbb, libstdc++ and libcrypto begin linked statically.
I don't have a concern as to the availability of other libraries
(libc, libm, libz and librt) because they essentially exists on any
system.
This commit ensure that all symbol resolution results are cleared
after LTO, so that the following second symbol resolution will not
be affected by the previous results.
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
