[all-commits] [llvm/llvm-project] a4900f: [BOLT] Abort on out-of-section symbols in GOT (#10...

[Vladislav Khmelevsky via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a4900f0d936f0e86bbd04bd9de4291e1795f1768
      https://github.com/llvm/llvm-project/commit/a4900f0d936f0e86bbd04bd9de4291e1795f1768
  Author: Vladislav Khmelevsky <och95 at yandex.ru>
  Date:   2024-08-07 (Wed, 07 Aug 2024)

  Changed paths:
    M bolt/include/bolt/Core/BinaryContext.h
    M bolt/lib/Core/BinaryContext.cpp
    M bolt/lib/Rewrite/RewriteInstance.cpp
    A bolt/test/AArch64/Inputs/got_end_of_section_symbol.lld_script
    A bolt/test/AArch64/got_end_of_section_symbol.s
    M bolt/test/X86/section-end-sym.s

  Log Message:
  -----------
  [BOLT] Abort on out-of-section symbols in GOT (#100801)

This patch aborts BOLT execution if it finds out-of-section (section
end) symbol in GOT table. In order to handle such situations properly in
future, we would need to have an arch-dependent way to analyze
relocations or its sequences, e.g., for ARM it would probably be ADRP +
LDR analysis in order to get GOT entry address. Currently, it is also
challenging because GOT-related relocation symbols are replaced to
__BOLT_got_zero. Anyway, it seems to be quite a rare case, which seems
to be only? related to static binaries. For the most part, it seems that
it should be handled on the linker stage, since static binary should not
have GOT table at all. LLD linker with relaxations enabled would replace
instruction addresses from GOT directly to target symbols, which
eliminates the problem.

Anyway, in order to achieve detection of such cases, this patch fixes a
few things in BOLT:
1. For the end symbols, we're now using the section provided by ELF
binary. Previously it would be tied with a wrong section found by symbol
address.
2. The end symbols would have limited registration we would only
add them in name->data GlobalSymbols map, since using address->data
BinaryDataMap map would likely be impossible due to address duality of
such symbols.
3. The outdated BD->getSection (currently returning refence, not
pointer) check in postProcessSymbolTable is replaced by getSize check in
order to allow zero-sized top-level symbols if they are located in
zero-sized sections. For the most part, such things could only be found
in tests, but I don't see a reason not to handle such cases.
4. Updated section-end-sym test and removed x86_64 requirement since
there is no reason for this (tested on aarch64 linux)

The test was provided by peterwaller-arm (thank you) in #100096 and
slightly modified by me.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications