[PATCH] D97007: [lld-macho] Define __mh_*_header synthetic symbols.

Jez Ng via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 17 13:05:03 PDT 2021


int3 added a comment.

Hm, why is `__mh_execute_header` an undefined?

It seems like it's a defined symbol to me:

  (base) ~/tmp: cat test.cpp
  int main() { return 0; }
  (base) ~/tmp: clang -c test.cpp
  (base) ~/tmp: ld -lSystem test.o -o test
  (base) ~/tmp: llvm-objdump --syms test
  
  test:	file format mach-o 64-bit x86-64
  
  SYMBOL TABLE:
  0000000100000000 g     F __TEXT,__text __mh_execute_header
  0000000100003fa0 g     F __TEXT,__text _main
  0000000000000000         *UND* dyld_stub_binder

~~Weirdly enough, when I swap out LLD for ld64 in our unit tests, it seems like load-command.s generates `__mh_execute_header` as an absolute symbol.~~ Aha, turns out that it's an absolute symbol only if we aren't linking a PIE.

Also, ld64 doesn't appear to emit `__mh_bundle_header`:

  --- a/lld/test/MachO/lit.local.cfg
  +++ b/lld/test/MachO/lit.local.cfg
  @@ -8,7 +8,7 @@ import os
   #
   # Note however that this does not apply to `-syslibroot`: each instance of that
   # flag will append to the set of library roots.
  -lld = ('ld64.lld -arch x86_64 -platform_version macos 10.0 11.0 -syslibroot ' +
  +lld = ('ld -syslibroot ' +
       os.path.join(config.test_source_root, "MachO", "Inputs", "MacOSX.sdk"))
   config.substitutions.append(('%lld', lld + ' -fatal_warnings'))
   config.substitutions.append(('%no_fatal_warnings_lld', lld))



  (base) Output/load-commands.s.tmp: pwd
  /Users/jezng/src/llvm-project/build/release/tools/lld/test/MachO/Output/load-commands.s.tmp
  (base) Output/load-commands.s.tmp: llvm-objdump --syms executable
  
  executable:	file format mach-o 64-bit x86-64
  
  SYMBOL TABLE:
  0000000100000000 g       *ABS* __mh_execute_header
  0000000100003fb0 g     F __TEXT,__text _main
  0000000000000000         *UND* dyld_stub_binder
  (base) Output/load-commands.s.tmp: llvm-objdump --syms bundle
  
  bundle:	file format mach-o 64-bit x86-64
  
  SYMBOL TABLE:
  0000000000003fb0 g     F __TEXT,__text _main

I figured it might be interesting to test if our input object files can link against these symbols, and it appears to be the case:

  (base) ~/tmp: cat test.s
  .text
  .globl _main
  _main:
    mov __mh_execute_header at GOTPCREL(%rip), %rax
    ret
  (base) ~/tmp: llvm-mc test.s -triple=x86_64-apple-macos11.0 -filetype=obj -o test.o
  (base) ~/tmp: ld test.o -lSystem -o test
  (base) ~/tmp: ld test.o -lSystem -o test -dylib
  Undefined symbols for architecture x86_64:
    "__mh_execute_header", referenced from:
        _main in test.o
  ld: symbol(s) not found for architecture x86_64

We should add a test for that.



================
Comment at: lld/MachO/Symbols.h:86-88
+  // Whether this symbol should be forced to appear in the output binary's
+  // symbol table.
+  SymbolTablePresence presence : 2;
----------------
hm why the need to replace `linkerInternal` with this? (Do we still need it if the `__mh_*` symbols are Defineds?)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97007/new/

https://reviews.llvm.org/D97007



More information about the llvm-commits mailing list