The `extern "C"` directive in a version script should match a non-C++
mangled name for the sake of compatibility with other linkers. It
caused a regression for libprotobuf.
If a section name is valid as a C identifier (i.e. it doesn't start
with '.' and doesn't contain any punctuators), the linker automatically
creates new symbols by prepending `__start_` and `__stop_` to the
section name.
Previously, we conservatively keep such C identifier sections during
garbage collection. However, since `__start_` and `__stop_` symbols
are hidden symbols, if we do not have `__start_foo` or `__stop_foo`,
we can safely discard section `foo`.
Notably, we previously wrote symbols that have been demoted into STB_LOCAL
as STB_GLOBAL. Fix this by using a logic shared with dynsym to determine
the output attributes.
Also reorder the symbols since the LOCAL ones need to come first.
Found in Mesa test suite.
Signed-off-by: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
`cxa_finalize` takes `__dso_handle` to uniquify identify an ELF module
in memory. Its actual location doesn't matter but needs to be different
for each ELF module.
Fixes https://github.com/rui314/mold/issues/507
This change removes the compact PLT and non-IBT PLT and replaces
them with IBT PLT. The compact PLT wasn't compatible with `-z ibtplt`.
Fixes https://github.com/rui314/mold/issues/581
The command "mold -run foo.ld" can fail when foo.ld is an empty file.
The musl execvp() call fails with "Exec format error" when the script
to be executed is empty. The fix is to create foo.ld with a valid
Unix shebang.
Signed-off-by: Peter Wang <novalazy@gmail.com>
This also fixes the `note-property` test which was hanging on my
machine. Turns out `$CC` was stuck waiting to read from `stdin`,
and as such I decided to write something into it.
Signed-off-by: Robert Bartlensky <bartlensky.robert@gmail.com>
We used to compute a file UUID using only the hashes in the code
signature section. So we computes the same UUID even if two files
are differnet only in some field of the code signature section.
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
