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
glibc's -static-pie implementation expect that _GLOBAL_OFFSET_TABLE_
is at the beginning of .got.plt, as it uses the address of _DYNAMIC
which is stored at _GLOBAL_OFFSET_TABLE_[0].
In this patch, we always create .got.plt for x86-64 and i386.
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
While running tests on UBSan instrumented mold binary 2 separated problems are reported:
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior elf/main.cc:592:15 in
elf/output-chunks.cc:1866:24: runtime error: member call on null pointer of type 'mold:🧝:VerdefSection<mold:🧝:X86_64> *'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior elf/output-chunks.cc:1866:24 in
elf/input-files.cc:1000:8: runtime error: load of value 190, which is not a valid value for type 'bool'
This change fixes both of them.
Signed-off-by: Dawid Jurczak <dawid_jurek@vp.pl>
