13f439a187
Private extern symbols are used for things scoped to the linkage unit. They cause duplicate symbol errors (so they're in the symbol table, unlike TU-scoped truly local symbols), but they don't make it into the export trie. They are created e.g. by compiling with -fvisibility=hidden. If two weak symbols have differing privateness, the combined symbol is non-private external. (Example: inline functions and some TUs that include the header defining it were built with -fvisibility-inlines-hidden and some weren't). A weak private external symbol implicitly has its "weak" dropped and behaves like a regular strong private external symbol: Weak is an export trie concept, and private symbols are not in the export trie. If a weak and a strong symbol have different privateness, the strong symbol wins. If two common symbols have differing privateness, the larger symbol wins. If they have the same size, the privateness of the symbol seen later during the link wins (!) -- this is a bit lame, but it matches ld64 and this behavior takes 2 lines less to implement than the less surprising "result is non-private external), so match ld64. (Example: `int a` in two .c files, both built with -fcommon, one built with -fvisibility=hidden and one without.) This also makes `__dyld_private` a true TU-local symbol, matching ld64. To make this work, make the `const char*` StringRefZ ctor to correctly set `size` (without this, writing the string table crashed when calling getName() on the __dyld_private symbol). Mention in CommonSymbol's comment that common symbols are now disabled by default in clang. Mention in -keep_private_externs's HelpText that the flag only has an effect with `-r` (which we don't implement yet -- so this patch here doesn't regress any behavior around -r + -keep_private_externs)). ld64 doesn't explicitly document it, but the commit text of http://reviews.llvm.org/rL216146 does, and ld64's OutputFile::buildSymbolTable() checks `_options.outputKind() == Options::kObjectFile` before calling `_options.keepPrivateExterns()` (the only reference to that function). Fixes PR48536. Differential Revision: https://reviews.llvm.org/D93609
39 lines
1.2 KiB
ArmAsm
39 lines
1.2 KiB
ArmAsm
# REQUIRES: x86
|
|
|
|
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-macos %s -o %t.o
|
|
# RUN: %lld -dylib %t.o -o %t.dylib -lSystem
|
|
# RUN: llvm-objdump --macho --weak-bind %t.dylib | FileCheck %s
|
|
# CHECK-NOT: __got
|
|
# CHECK-NOT: __la_symbol_ptr
|
|
|
|
# RUN: llvm-objdump --macho --all-headers %t.dylib | \
|
|
# RUN: FileCheck --check-prefix=HEADERS %s
|
|
# HEADERS-NOT: WEAK_DEFINES
|
|
# HEADERS-NOT: BINDS_TO_WEAK
|
|
|
|
## Check that N_WEAK_DEF isn't set in the symbol table.
|
|
## This is different from ld64, which makes private extern weak symbols non-weak
|
|
## for binds and relocations, but it still marks them as weak in the symbol table.
|
|
## Since `nm -m` doesn't look at N_WEAK_DEF for N_PEXT symbols this is not
|
|
## observable, but it feels slightly more correct.
|
|
# RUN: llvm-readobj --syms %t.dylib | FileCheck --check-prefix=SYMS %s
|
|
# SYMS-NOT: WeakDef (0x80)
|
|
|
|
.globl _use
|
|
_use:
|
|
mov _weak_private_extern_gotpcrel@GOTPCREL(%rip), %rax
|
|
callq _weak_private_extern
|
|
retq
|
|
|
|
.private_extern _weak_private_extern
|
|
.globl _weak_private_extern
|
|
.weak_definition _weak_private_extern
|
|
_weak_private_extern:
|
|
retq
|
|
|
|
.private_extern _weak_private_extern_gotpcrel
|
|
.globl _weak_private_extern_gotpcrel
|
|
.weak_definition _weak_private_extern_gotpcrel
|
|
_weak_private_extern_gotpcrel:
|
|
.quad 0x1234
|