Commit graph

9 commits

Author SHA1 Message Date
Dan Klishch
5963b785e7 LibELF: Unbreak dynamic loader on riscv64
It turns out riscv64 indeed requires -fno-stack-protector for
perform_relative_relocations, oopsie :^)
2024-05-07 16:39:17 -06:00
Sönke Holz
f8628f94b8 LibELF: Refactor how arch-specific dynamic relocation types are handled
We currently expect that the relocation type numbers are unique across
all architectures. But RISC-V and x86_64 use the same numbers for
different relocation types (R_X86_64_COPY = R_RISCV_JUMP_SLOT = 5).

So create a generic reloc type enum which maps to the arch-specific
reloc types instead of checking for all arch reloc types individually
everywhere.
2024-02-24 16:05:50 -07:00
Daniel Bertalan
45d81dceed Everywhere: Replace ElfW(type) macro usage with Elf_type
This works around a `clang-format-17` bug which caused certain usages to
be misformatted and fail to compile.

Fixes #8315
2023-12-01 10:02:39 +02:00
implicitfield
79adeb626b LibC+LibELF: Move ELF definitions from LibC to LibELF
This is needed to avoid including LibC headers in Lagom builds.
Unfortunately, we cannot rely on the build machine to provide a
fully POSIX-compatible ELF header for Lagom builds, so we have to
use our own.
2023-06-27 12:40:38 +02:00
Timon Kruiper
4b0f8e9a20 LibELF+LibC: Add support for relative relocations in aarch64 binaries
This commit adds R_AARCH64_RELATIVE to elf.h and uses it in
ELF::perform_relative_relocations to correctly verify the relocation
type. This is the only change needed to support relative relocations for
aarch64.
2023-02-15 22:53:19 +01:00
Liav A
a4c87fac56 LibELF+LibSymbolication: Remove i686 support 2022-12-28 11:53:41 +01:00
Daniel Bertalan
3974cac148 LibELF: Implement support for DT_RELR relative relocations
The DT_RELR relocation is a relatively new relocation encoding designed
to achieve space-efficient relative relocations in PIE programs.

The description of the format is available here:
https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/Pi9aSwwABgAJ

It works by using a bitmap to store the offsets which need to be
relocated. Even entries are *address* entries: they contain an address
(relative to the base of the executable) which needs to be relocated.
Subsequent even entries are *bitmap* entries: "1" bits encode offsets
(in word size increments) relative to the last address entry which need
to be relocated.

This is in contrast to the REL/RELA format, where each entry takes up
2/3 machine words. Certain kinds of relocations store useful data in
that space (like the name of the referenced symbol), so not everything
can be encoded in this format. But as position-independent executables
and shared libraries tend to have a lot of relative relocations, a
specialized encoding for them absolutely makes sense.

The authors of the format suggest an overall 5-20% reduction in the file
size of various programs. Due to our extensive use of dynamic linking
and us not stripping debug info, relative relocations don't make up such
a large portion of the binary's size, so the measurements will tend to
skew to the lower side of the spectrum.

The following measurements were made with the x86-64 Clang toolchain:

- The kernel contains 290989 relocations. Enabling RELR decreased its
  size from 30 MiB to 23 MiB.
- LibUnicodeData contains 190262 relocations, almost all of them
  relative. Its file size changed from 17 MiB to 13 MiB.
- /bin/WebContent contains 1300 relocations, 66% of which are relative
  relocations. With RELR, its size changed from 832 KiB to 812 KiB.

This change was inspired by the following blog post:
https://maskray.me/blog/2021-10-31-relative-relocations-and-relr
2022-02-11 18:07:53 +01:00
Gunnar Beutner
ff292fbe5a LibELF: Fix unaligned writes in the relocation code 2021-07-27 13:15:16 +02:00
Gunnar Beutner
daeb371180 DynamicLoader+LibELF: Move self-relocation code into a separate file 2021-07-27 13:15:16 +02:00