[PATCH] D107533: Handle encoding personalities of same names but different kinds.

[Jez Ng via Phabricator via llvm-commits]

int3 added a comment.

Interesting example... after playing around with it for a bit, I'm not convinced that ld64 is actually behaving sensibly here 😕

First, when linking against combined.o, the dylib symbol "wins":

  (base) ~/unwind: ld -arch "x86_64" -platform_version macos 10.15 11.0   -syslibroot "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk" -lSystem -lc++ user_2.o combined.o -o out-ld64
  ld: warning: object file (user_2.o) was built for newer macOS version (11.0) than being linked (10.15)
  ld: warning: object file (combined.o) was built for newer macOS version (11.0) than being linked (10.15)
  (base) ~/unwind: llvm-objdump --macho --bind out-ld64
  out-ld64:
  
  Bind table:
  segment  section            address    type       addend dylib            symbol
  __DATA_CONST __got              0x100004000 pointer         0 libc++           ___gxx_personality_v0

In contrast, the code in this diff lets the local symbol win. But... I put "wins" above in quotes because ld64 doesn't actually seem to consider the local symbol a valid candidate at all! If we remove `-lc++`:

  (base) ~/unwind: ld -arch "x86_64" -platform_version macos 10.15 11.0   -syslibroot "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk" -lSystem user_2.o combined.o -o out-ld64
  ld: warning: object file (user_2.o) was built for newer macOS version (11.0) than being linked (10.15)
  ld: warning: object file (combined.o) was built for newer macOS version (11.0) than being linked (10.15)
  Undefined symbols for architecture x86_64:
    "___gxx_personality_v0", referenced from:
        _main in user_2.o
        Dwarf Exception Unwind Info (__eh_frame) in user_2.o
        _foo in combined.o
        Dwarf Exception Unwind Info (__eh_frame) in combined.o
  ld: symbol(s) not found for architecture x86_64

However, linking `user_1.o` and `defined.o` in place of `combined.o` does cause the personalities to be resolved to the local symbol:

  (base) ~/unwind: ld -arch "x86_64" -platform_version macos 10.15 11.0   -syslibroot "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk" -lSystem user_2.o user_1.o defined.o -o out-ld64
  ld: warning: object file (user_2.o) was built for newer macOS version (11.0) than being linked (10.15)
  ld: warning: object file (user_1.o) was built for newer macOS version (11.0) than being linked (10.15)
  ld: warning: object file (defined.o) was built for newer macOS version (11.0) than being linked (10.15)
  ld: warning: could not create compact unwind for ___gxx_personality_v0: FDE found for zero size function
  (base) ~/unwind: llvm-objdump --macho --bind out-ld64
  out-ld64:
  
  Bind table:
  segment  section            address    type       addend dylib            symbol

I'm not convinced that we should attempt to emulate this bizarre behavior. Would it be possible to change your build system to work around this instead?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107533