It was accidentally mapped to --color-diagnostics=always, but it
was a bug. For the sake of compatibility with other tools such as
clang or lld, it should be defined as an alias for `auto`.
My last commit d391fd9a59 changes how we
resolve versioned symbols, but that affected too many programs.
In particular it broke GCC build, so reverted in
f378fdc495.
This commit is an attempt to fix the same issue with a minimal change.
Fixes https://github.com/rui314/mold/issues/475
Otherwise the test may fail simply because .gdbinit setup does
something strange (I happen to have 'set auto-solib-add off', which
disables loading debug info by default).
An object file can contain both unversioned and versioned symbols for
the same symbol. For example, the following piece of code will be
compiled to an object file that will contain `foo` and `foo@VERSION`.
void foo() {}
asm(".symver foo, foo@VERSION");
If this object file is given to GNU BFD linker, it exports only
`foo@VERSION` and suppresses `foo`. I believe the rationale for doing
that is, if a symbol is versioned, all of its versions must be
versioned. In other words, `foo@VER1`, `foo@VER2` and `foo@@VER3` can
co-exist, but `foo@VER1` and `foo` can't. In the latter case, if you
want to provide `foo` as the default version, it should be exported
not as `foo` but as `foo@@SOME_VERSION` (with double at-signs).
Fixes https://github.com/rui314/mold/issues/426
GCC creates a .debug_macro section if -g3 is given. That section
is in a comdat group, but the section is directly referred by another
section, which is a violation of the ELF spec.
If a section is deduplicated, we handle any references to that section
as if they had value 0. But that causes a mysterious gdb slowdown.
So we can't set 0 for a dead .debug_macro section.
In this commit, we simply stop deduplicating .debug_macro sections.
This will bloat up debug info, but that's better than producing an
effectively non-debuggable binary.
Fixes https://github.com/rui314/mold/issues/357
Fixes https://github.com/rui314/mold/issues/438
This test fails on some Linux systems, and it is essentially testing
not the mold's capabilities but the running platform's capabilities.
I don't think there's a portable, guaranteed way to create an
executable shared object on Linux, so even if it happens to work,
I don't think we can guarantee that.
Previously, --gdb-index tries to read bogus compressed data from
input sections if input debug sections are compressed.
Fixes https://github.com/rui314/mold/issues/431
This affects Fedora >= 35, where debuginfod is enabled by default. On
such systems, gdb shows the following interactive prompt and then waits
forever:
```
This GDB supports auto-downloading debuginfo from the following URLs:
https://debuginfod.fedoraproject.org/
Enable debuginfod for this session? (y or [n])
```
Unsetting the `DEBUGINFOD_URLS` environment variable disables the prompt
as documented here: https://fedoraproject.org/wiki/Debuginfod#Disabling
Signed-off-by: Christoph Erhardt <github@sicherha.de>
Previously, if a section has a very large alignment requirement,
that section and the following sections may get wrong file offsets.
Fixes https://github.com/rui314/mold/issues/405
This is a tough one because .gdb_index, .debug_gnu_pubnames,
.debug_gnu_pubtypes and DWARF are underdocumented, and DWARF is
complicated even if you have a right documentation. But, I believe I
managed to create a correct .gdb_index section.
Just like ld.lld, mold's --gdb-index needs all input object files to
have been compiled with -ggnu-pubnames. We read symbol names and type
names from the sections generated by -ggnu-pubnames.
Unlike ld.gold and ld.lld, we do not use an external library to read
DWARF debug info records.
As always, this feature is implemented with speed in mind. For Clang
15 which is built with -ggnu-pubnames, mold takes ~150 ms to create a
~300 MiB .gdb_index section on a simulated 16-core machine.
Fixes https://github.com/rui314/mold/issues/396
It is very rare, but technically you can create a shared object that
can also be executed directly. You can do that by giving a dynamic
linker path to the linker.
https://github.com/rui314/mold/issues/422
With this change, you can link a simple bootloader using mold.
To do so, compile bootloader source files to object files with
the `-fno-PIC` flag and then invoke mold on the object files with
`-Ttext=<bootloader-start-address>` and `--oformat=binary`.
The .text segment is usually at the beginning of the output file if
the file is created that way. By passing the startup code as the first
file argument to the linker, you can place that startup code at the
beginning of the file.
Fixes https://github.com/rui314/mold/issues/418
Previously, we make all PLT entries canonical if we are creating
a position dependent executable, because I was thinking that promoting
usual PLT entries to canonical ones is harmless; symbol equality still
holds.
However, it looks like Qt depends on the usual linker's behavior not
to make PLT canonical if not necessary. I believe they are maintaining
some hidden symbol as aliases for exported symbols and compare their
addresses at runtime.
Of course this doesn't work if your program is not compiled with -fPIC,
but qt5/QtCore/qglobal.h has a macro to abort compilation if PIC is
disabled. (They check for __PIC__ and __PIE__ macros.) So, all object
files are guaranteed to be compiled with -fPIC if they are using QT
functions, and they assume that the linker doesn't create a canonical
PLT for Qt functions.
This commit makes mold to create canonical PLTs only when needed.
That is, if an address of a function is directly taken (i.e. not via
GOT), then mold makes its PLT canonical.
Fixes https://github.com/rui314/mold/issues/352
With this change, you can now cross compile test cases and run
them on qemu-user. Here is an example to run our test suits in
an emulated ARM32 environment.
$ CC=arm-linux-gnueabihf-gcc \
CXX=arm-linux-gnueabihf-g++ \
GCC=arm-linux-gnueabihf-gcc \
GXX=arm-linux-gnueabihf-g++ \
OBJDUMP=arm-linux-gnueabihf-objdump \
MACHINE=arm \
QEMU='qemu-arm -L /usr/arm-linux-gnueabihf' \
make -j16 test
Currently, we do not support relaxations of TLS GD/LD relocations
for ARM64. This is in practice not a problem because TLSDESC is used
on ARM64 by default.
However, there's one situation in which not supporting TLS GD/LD
relaxation becomes an issue; static linking. If an executable is
statically-linked, relaxation is mandatory because we can't generate
dynamic relocations for GD/LD relocations.
In this patch, we simply report an error if an object file compiled
with TLS GD/LD is used for creating a statically-linked executable.
This commit fixes all tests on ARM64.
Some `ldd` impls don't support the --version option. We do not
want to show the error message but instead just skip the test
entirely.
https://github.com/rui314/mold/pull/385
After a certain point, it is not expected that there's a remaining
undefined symbol. -noinhibit-exec did not respect that invariant,
which caused a crash bug on ARM64.
This change forces all symbols to be resolved if --noinhibit-exec
is given.
Fixes https://github.com/rui314/mold/issues/383
We unset `LANG`, but it looks like `LC_ALL` takes precedence over `LANG`,
so we should set `LC_ALL` to `C`.
Reported at https://github.com/rui314/mold/pull/385
mold 1.1.1 generates `-static-pie` code that works with glibc 2.35 but
segfaults with glibc 2.34 or older.
Signed-off-by: Christoph Erhardt <github@sicherha.de>
Previously, mold did not work with the -static-pie compiler flag.
In order to support static PIE, we need the following:
1. Create a .dynamic section even if it is not a dynamic executable, and
2. do not define __rel_iplt_start/end symbols.
The second part is required to workaround a glibc issue.
Even with these changes, mold-generated executable doesn't work with
old glibc versions. But I think it's OK because -static-pie is relatively
new option and you need a newer toolchain anyway.
It looks like the glibc loader does not use this field in the dynamic
section. GNU ld, gold and LLVM lld don't create this. So I think we
can just follow suit.
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
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>
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
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
`-icf=all` couldn't handle very small programs that has no sections
to process in the main loop. This commit fixes that crash bug.
Fixes https://github.com/rui314/mold/issues/332
GCC creates symbols in comdat groups as STB_GNU_UNIQUE instead of STB_WEAK
if it was configured to do so at build time or the -fgnu-unique option was
given. If mold is given two object files with and without STB_GNU_UNIQUE,
it could end up selecting a sybmol that is in a de-duplicated comdat group.
This is arguably just an ABI incompatibility. Two comdat groups must
contain the same contents if their identifiers are the same. But we
can't handle it as an error because it is not uncommon to link object
files compiled using Clang (or GCC without -fgnu-unique) to static
libraries built with GCC that produces STB_GNU_UNIQUE symbols.
This patch gives the same priority to STB_GNU_UNIQUE as STB_WEAK so that
mold won't select symbols in discarded comdat groups.
Frankly, the situation around STB_GNU_UNIQUE is a mess. That GNU extension
shouldn't have been added to the GNU toolchain in the first place.
It looks like GCC shipped with Linux distros are nowadays do not produce
STB_GNU_UNIQUE symbols by default, but we still need to handle them.
Fixes https://github.com/rui314/mold/issues/324
Previously, if a protected/hidden undef symbol is resolved to a DSO
symbol, mold didn't report a symbol undefined error.
Fixes https://github.com/rui314/mold/issues/329
This commit adds the `--emit-relocs` option to mold. If the flag is
given, mold copies relocation sections from input files to an output
file. This option is used by some binary post-processing tools such
as Facebook's Bolt.
It looks like the relocations emitted by `--emit-relocs` are correct,
but I didn't do extensive testing. If you find any problem, please
let me know.
Fixes https://github.com/rui314/mold/issues/177
`--repro` is a hidden command flag for debugging.
Previously, if the flag was given, mold would create a `.repro`
section in an output file with all input files as its contents.
The flaw of the design is that when mold fails to create an output
file, no .repro section would be created.
So I changed the behavior in this commit. Now, the tar file is
created as an independent file.
PT_GNU_RELRO works on page granularity. We always align the begining
of a RELRO segment to a page boundary, but the end was not. Since the
runtime conservatively align _down_ it to a page boundary, the last
page weren't be marked as read-only.
This patch makes the size of a RELRO always a multiple of the page size.
To process version scriots, we have to match glob patterns against
symbol strings. Sometimes, we have hundreds or thousands of glob
patterns and have to match them against millions of mangled long
C++ symbol names. This step can be very slow.
In this patch, I implemented the Aho-Corasick algorithm to match glob
patterns to symbol strings as quickly as possible. For the details
of the algorithm, see https://en.wikipedia.org/wiki/Glob_(programming).
This patch improves mold's performance for programs that uses large
version scripts. For example, linking libQt6Gui.so.6.3.0 reduced from
1.10s to 0.05s with this patch.
This patch also changes how symbol versions are applied if two or more
version patterns match to a single symbol string. Previously, the last
one in a script file took precedence. Now, the first one takes
precedence. I believe the new behavior is compatible with GNU ld.
Fixes https://github.com/rui314/mold/issues/156
Fixed https://github.com/rui314/mold/issues/287
Previously, we didn't handle version scripts like this correctly:
ver {
global: *;
local: foo*;
}
We didn't handle `local:` part correctly except for `*`.
Fixes https://github.com/rui314/mold/issues/277
.relr.dyn is a new section that has been implemented in other linkers
recently. That section contains only the RELATIVE-type dynamic
relocations (i.e. base relocations). Compared to the regular
.rela.dyn, a .relr.dyn's size is typically less than 1/10 because the
section is compressed.
Since PIEs (position-independent executables) tend to contain lots of
RELATIVE-type relocations and PIEs are now the default on many Linux
distributions for security reasons, .relr.dyn is more effective than
it was. It can reduce binary size by a few percent or more.
Note that the runtime support is catching up, so binaries built with
`-pack-dyn-relocs=relr` may not work on your system unless you are
running a very recent version of Linux.
gdb uses this field only if it is an executable. Having an extra
dynamic entry is usually harmless, but unfortunately, RPM's `rpmdeps`
tool uses the presence of this entry to distinguish executables from
shared object files. So, it is better not to create a DT_DEBUG entry
for shared object files.
Fixes https://github.com/rui314/mold/issues/254
That substring was introduced in de7ba9014f
to appease Gentoo's dev-libs/jansson-2.13.1-r1 package. But I think I
shouldn't done that from the beginning to avoid the sitaution of the
"User-Agent" string of the web browser, which everybody claims they
are Mozilla, AppleWebKit, Chrome and Safari simultaneously.
Previously, the `bnd jmp` instruction in a IBTPLT entry jumps to the
middle of an instruction due to an incorrect GOTPLT value. That happened
to work because a value that was there after the jump can be interpreted
as an `add` instruction and the control falled through the next `pushq`.
Previously, mold ignored common symbols in an archive when resolving
symbols. As a result, even if an undefined symbol could be resolved
using a common symbol in an archive, mold would end up with an undefined
symbol error.
This commit changes the behavior. Now, an undefined symbol is resolved
to a common symbol in an archive if exists.
Fixes https://github.com/rui314/mold/issues/256
The .ctors section contains a list of pointers that have to be run
before `main`. It usually contains pointers to global constructors.
The .dtors are for global destructors.
The .init_array and .fini_array serve the same purpose as .ctors and
.dtors. The former sections are newer than the latter sections, and
most programs have already migrated to .{init,fini}_array.
.ctors/.dtors are very similar to .{init,fini}_array, but the order
in which pointers are executed is different. .ctors/.dtors are executed
from the end to the beginning, while .{init,fini}_array are executed
from the beginning to the end.
Previously, we converted .ctors/.dtors sections into .{init,fini}_array
sections. In order to do that, we not only merge .ctors/.dtors to
.{init,fini}_array but also reverse their section contents, so that
the initialization order remains the same.
However, there was a bug in that logic. We forgot to reverse the
locations of dynamic relocations for the converted sections.
So, .ctors/.dtors sections converted to .{init,fini}_array were executed
in a wrong order.
We have two choices to "fix" the issue: (1) reverse not only section
contents but also dynamic relocations, or (2) stop converting .ctors/.dtors.
In this patch, I chose (2).
Since LLVM lld doesn't convert .ctors/.dtors, it shouldn't cause an
issue for most programs.
Previously, mold crashes due to an invalid regex pattern exception
when `[...]` is given as a version script pattern.
Fixes https://github.com/rui314/mold/issues/258
Previously, mold put all global symbols into .gnu.hash. Although I
believe it was not an error, it bloated the size of .gnu.hash because
.gnu.hash needs only exported symbols.
https://github.com/rui314/mold/issues/255
This is very hacky but highly practical, so I couldn't resist to not
implement this. We should support LTO natively in the future. In the
meantime, this feature should work as a poor-man's replacement.
Fixes https://github.com/rui314/mold/issues/242
This makes it possible to build and test mold in a path that contains
whitespace characters - with the notable exception of the tests where
`LD_PRELOAD` is used. That's because `LD_PRELOAD` unconditionally treats
any whitespace as separator, regardless of quoting.
The following ShellCheck warnings are eliminated by this commit:
* SC2046: Quote this to prevent word splitting.
* SC2086: Double quote to prevent globbing and word splitting.
Signed-off-by: Christoph Erhardt <github@sicherha.de>
For globbing, '?' matches a single character, so must be replaced
with '.'. As a result, don't skip the later regex matching for
version scripts, if the pattern contains either '*' or '?'.
Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
Previously, if there are more than one TLS BSS section (e.g. .tbss and
.tcommon), mold layout them in such a way that they overlap in memory.
That caused a mysterious program crash to the programs compiled with DMD,
a D compiler.
Fixes https://github.com/rui314/mold/issues/126
When we are creating a DSO, unresolved undefined symbols are promoted to
dynamic symbols by default so that they will get another chance to be
resolved at runtime.
You can suppress this behavior by passing `-z defs`. If that option is
given, remaining undefs are reported as errors instead of being silently
promoted.
It looks like `-warn-undefined-symbols` negates the effect of `-z defs`.
So, if both options are given, remaining undefs are promoted to dynamic
symbols. mold previously silently make such symbols absolute symbols with
value 0.
Fixed https://github.com/rui314/mold/issues/152
These test files are not only invoked by make by also directly by hand.
Unsetting `LANG` on each file so that they don't fail in a non-English
environment.
This change is mechanically created by the following command:
sed -i '1 a export LANG=' test/*/*.sh
Previously, if the following conditions are met:
- we are creating a shared object file,
- there's an undefined symbol in an input object file that are
to be promoted to a dynamic symbol, and
- a version script defining a default version is given,
then the symbol gets the default version. But that's a wrong behavior
because version scripts should not affect symbols that are not defined
in an output file.
This change fixes the issue by not setting version to such symbol.
Fixes https://github.com/rui314/mold/issues/151
Previously, an executable linked by mold could fall into an infinite
loop between .plt.got and .got entries. This commit fixes the issue
by creating .plt entries instead of .plt.got.
Fixes https://github.com/rui314/mold/issues/129
