[all-commits] [llvm/llvm-project] 484c96: [lld-macho] Postprocess LC Linker Option

[kyulee-com via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 484c961ccdfaf1d72429560a08b2d44da9a292cd
      https://github.com/llvm/llvm-project/commit/484c961ccdfaf1d72429560a08b2d44da9a292cd
  Author: Kyungwoo Lee <kyulee at fb.com>
  Date:   2023-08-13 (Sun, 13 Aug 2023)

  Changed paths:
    M lld/MachO/Driver.cpp
    M lld/MachO/Driver.h
    M lld/MachO/InputFiles.cpp
    M lld/MachO/InputFiles.h
    A lld/test/MachO/lc-linker-option-lto.ll
    A lld/test/MachO/lc-linker-option-order.ll
    M lld/test/MachO/lc-linker-option.ll

  Log Message:
  -----------
  [lld-macho] Postprocess LC Linker Option

LLD resolves symbols regardless of LTO modes early when reading and parsing input files in order. The object files built from LTO passes are appended later.
Because LLD eagerly resolves the LC linker options while parsing a new object file (and its chain of dependent libraries), the prior decision on pending prevailing symbols (belonging to some bitcode files) can change to ones in those native libraries that are just loaded.

This patch delays processing LC linker options until all the native object files are added after LTO is done, similar to LD64. This way we preserve the decision on prevailing symbols LLD made, regardless of LTO modes.
 - When parsing a new object file in `parseLinkerOptions()`, it just parses LC linker options in the header, and saves those contents to `unprocessedLCLinkerOptions`.
 - After LTO is finished, `resolveLCLinkerOptions()` is called to recursively load dependent libraries, starting with initial linker options collected in `unprocessedLCLinkerOptions` (which also updates during recursions)

Reviewed By: #lld-macho, int3

Differential Revision: https://reviews.llvm.org/D157716