2020-04-03 02:54:05 +08:00
|
|
|
//===- Symbols.h ------------------------------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLD_MACHO_SYMBOLS_H
|
|
|
|
#define LLD_MACHO_SYMBOLS_H
|
|
|
|
|
2021-02-04 02:31:40 +08:00
|
|
|
#include "InputFiles.h"
|
2020-04-03 02:54:05 +08:00
|
|
|
#include "InputSection.h"
|
|
|
|
#include "Target.h"
|
2020-05-19 11:28:50 +08:00
|
|
|
#include "lld/Common/ErrorHandler.h"
|
2020-04-03 02:54:05 +08:00
|
|
|
#include "lld/Common/Strings.h"
|
|
|
|
#include "llvm/Object/Archive.h"
|
2020-09-25 05:44:14 +08:00
|
|
|
#include "llvm/Support/MathExtras.h"
|
2020-04-03 02:54:05 +08:00
|
|
|
|
|
|
|
namespace lld {
|
|
|
|
namespace macho {
|
|
|
|
|
|
|
|
class InputSection;
|
2020-07-31 05:28:41 +08:00
|
|
|
class MachHeaderSection;
|
2020-04-03 02:54:05 +08:00
|
|
|
|
|
|
|
struct StringRefZ {
|
|
|
|
StringRefZ(const char *s) : data(s), size(-1) {}
|
|
|
|
StringRefZ(StringRef s) : data(s.data()), size(s.size()) {}
|
|
|
|
|
|
|
|
const char *data;
|
|
|
|
const uint32_t size;
|
|
|
|
};
|
|
|
|
|
|
|
|
class Symbol {
|
|
|
|
public:
|
|
|
|
enum Kind {
|
|
|
|
DefinedKind,
|
|
|
|
UndefinedKind,
|
2020-09-25 05:44:14 +08:00
|
|
|
CommonKind,
|
2020-04-22 04:37:57 +08:00
|
|
|
DylibKind,
|
2020-05-15 03:43:51 +08:00
|
|
|
LazyKind,
|
2020-07-31 05:28:41 +08:00
|
|
|
DSOHandleKind,
|
2020-04-03 02:54:05 +08:00
|
|
|
};
|
|
|
|
|
2020-07-25 06:55:25 +08:00
|
|
|
virtual ~Symbol() {}
|
|
|
|
|
2020-04-03 02:54:05 +08:00
|
|
|
Kind kind() const { return static_cast<Kind>(symbolKind); }
|
|
|
|
|
[lld/mac] Implement support for private extern symbols
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
2020-12-18 02:30:18 +08:00
|
|
|
StringRef getName() const {
|
|
|
|
if (nameSize == (uint32_t)-1)
|
|
|
|
nameSize = strlen(nameData);
|
|
|
|
return {nameData, nameSize};
|
|
|
|
}
|
2020-04-03 02:54:05 +08:00
|
|
|
|
2020-07-31 05:28:41 +08:00
|
|
|
virtual uint64_t getVA() const { return 0; }
|
2020-04-03 02:54:05 +08:00
|
|
|
|
2020-07-31 05:28:41 +08:00
|
|
|
virtual uint64_t getFileOffset() const {
|
|
|
|
llvm_unreachable("attempt to get an offset from a non-defined symbol");
|
|
|
|
}
|
2020-05-19 11:28:50 +08:00
|
|
|
|
2020-12-16 10:05:06 +08:00
|
|
|
virtual bool isWeakDef() const { llvm_unreachable("cannot be weak def"); }
|
|
|
|
|
|
|
|
// Only undefined or dylib symbols can be weak references. A weak reference
|
|
|
|
// need not be satisfied at runtime, e.g. due to the symbol not being
|
|
|
|
// available on a given target platform.
|
|
|
|
virtual bool isWeakRef() const { llvm_unreachable("cannot be a weak ref"); }
|
2020-07-25 06:55:25 +08:00
|
|
|
|
2020-08-13 10:50:09 +08:00
|
|
|
virtual bool isTlv() const { llvm_unreachable("cannot be TLV"); }
|
|
|
|
|
2020-08-25 12:57:59 +08:00
|
|
|
// Whether this symbol is in the GOT or TLVPointer sections.
|
|
|
|
bool isInGot() const { return gotIndex != UINT32_MAX; }
|
|
|
|
|
2020-08-28 06:54:42 +08:00
|
|
|
// Whether this symbol is in the StubsSection.
|
|
|
|
bool isInStubs() const { return stubsIndex != UINT32_MAX; }
|
|
|
|
|
2020-08-13 10:50:09 +08:00
|
|
|
// The index of this symbol in the GOT or the TLVPointer section, depending
|
|
|
|
// on whether it is a thread-local. A given symbol cannot be referenced by
|
|
|
|
// both these sections at once.
|
2020-06-14 11:00:06 +08:00
|
|
|
uint32_t gotIndex = UINT32_MAX;
|
|
|
|
|
2020-08-28 06:54:42 +08:00
|
|
|
uint32_t stubsIndex = UINT32_MAX;
|
|
|
|
|
2020-09-05 09:02:07 +08:00
|
|
|
uint32_t symtabIndex = UINT32_MAX;
|
|
|
|
|
2021-02-04 02:31:40 +08:00
|
|
|
InputFile *getFile() const { return file; }
|
|
|
|
|
2020-04-03 02:54:05 +08:00
|
|
|
protected:
|
2021-02-04 02:31:40 +08:00
|
|
|
Symbol(Kind k, StringRefZ name, InputFile *file)
|
|
|
|
: symbolKind(k), nameData(name.data), nameSize(name.size), file(file) {}
|
2020-04-03 02:54:05 +08:00
|
|
|
|
|
|
|
Kind symbolKind;
|
[lld/mac] Implement support for private extern symbols
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
2020-12-18 02:30:18 +08:00
|
|
|
const char *nameData;
|
|
|
|
mutable uint32_t nameSize;
|
2021-02-04 02:31:40 +08:00
|
|
|
InputFile *file;
|
2020-04-03 02:54:05 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
class Defined : public Symbol {
|
|
|
|
public:
|
2021-02-04 02:31:40 +08:00
|
|
|
Defined(StringRefZ name, InputFile *file, InputSection *isec, uint32_t value,
|
|
|
|
bool isWeakDef, bool isExternal, bool isPrivateExtern)
|
|
|
|
: Symbol(DefinedKind, name, file), isec(isec), value(value),
|
[lld/mac] Implement support for private extern symbols
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
2020-12-18 02:30:18 +08:00
|
|
|
overridesWeakDef(false), privateExtern(isPrivateExtern),
|
|
|
|
weakDef(isWeakDef), external(isExternal) {}
|
2020-07-25 06:55:25 +08:00
|
|
|
|
|
|
|
bool isWeakDef() const override { return weakDef; }
|
[lld/mac] Implement support for private extern symbols
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
2020-12-18 02:30:18 +08:00
|
|
|
bool isExternalWeakDef() const {
|
|
|
|
return isWeakDef() && isExternal() && !privateExtern;
|
|
|
|
}
|
2020-09-18 23:40:46 +08:00
|
|
|
bool isTlv() const override {
|
|
|
|
return !isAbsolute() && isThreadLocalVariables(isec->flags);
|
|
|
|
}
|
2020-08-13 10:50:09 +08:00
|
|
|
|
2020-08-25 12:57:59 +08:00
|
|
|
bool isExternal() const { return external; }
|
2020-09-18 23:40:46 +08:00
|
|
|
bool isAbsolute() const { return isec == nullptr; }
|
2020-08-25 12:57:59 +08:00
|
|
|
|
2020-09-18 23:40:46 +08:00
|
|
|
uint64_t getVA() const override;
|
|
|
|
uint64_t getFileOffset() const override;
|
2020-07-31 05:28:41 +08:00
|
|
|
|
2020-09-18 23:40:46 +08:00
|
|
|
static bool classof(const Symbol *s) { return s->kind() == DefinedKind; }
|
2020-07-31 05:28:41 +08:00
|
|
|
|
2021-02-04 02:31:40 +08:00
|
|
|
InputFile *file;
|
2020-04-03 02:54:05 +08:00
|
|
|
InputSection *isec;
|
|
|
|
uint32_t value;
|
|
|
|
|
2020-08-28 06:59:30 +08:00
|
|
|
bool overridesWeakDef : 1;
|
[lld/mac] Implement support for private extern symbols
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
2020-12-18 02:30:18 +08:00
|
|
|
bool privateExtern : 1;
|
2020-08-28 06:59:30 +08:00
|
|
|
|
2020-07-25 06:55:25 +08:00
|
|
|
private:
|
2020-08-28 06:59:30 +08:00
|
|
|
const bool weakDef : 1;
|
|
|
|
const bool external : 1;
|
2020-04-03 02:54:05 +08:00
|
|
|
};
|
|
|
|
|
2020-12-17 08:14:57 +08:00
|
|
|
// This enum does double-duty: as a symbol property, it indicates whether & how
|
|
|
|
// a dylib symbol is referenced. As a DylibFile property, it indicates the kind
|
|
|
|
// of referenced symbols contained within the file. If there are both weak
|
|
|
|
// and strong references to the same file, we will count the file as
|
|
|
|
// strongly-referenced.
|
2020-12-16 10:05:06 +08:00
|
|
|
enum class RefState : uint8_t { Unreferenced = 0, Weak = 1, Strong = 2 };
|
|
|
|
|
2020-04-03 02:54:05 +08:00
|
|
|
class Undefined : public Symbol {
|
|
|
|
public:
|
2021-02-04 02:31:40 +08:00
|
|
|
Undefined(StringRefZ name, InputFile *file, RefState refState)
|
|
|
|
: Symbol(UndefinedKind, name, file), refState(refState) {
|
2020-12-16 10:05:06 +08:00
|
|
|
assert(refState != RefState::Unreferenced);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool isWeakRef() const override { return refState == RefState::Weak; }
|
2020-04-03 02:54:05 +08:00
|
|
|
|
|
|
|
static bool classof(const Symbol *s) { return s->kind() == UndefinedKind; }
|
2020-12-16 10:05:06 +08:00
|
|
|
|
|
|
|
RefState refState : 2;
|
2020-04-03 02:54:05 +08:00
|
|
|
};
|
|
|
|
|
2020-09-25 05:44:14 +08:00
|
|
|
// On Unix, it is traditionally allowed to write variable definitions without
|
|
|
|
// initialization expressions (such as "int foo;") to header files. These are
|
|
|
|
// called tentative definitions.
|
|
|
|
//
|
|
|
|
// Using tentative definitions is usually considered a bad practice; you should
|
|
|
|
// write only declarations (such as "extern int foo;") to header files.
|
|
|
|
// Nevertheless, the linker and the compiler have to do something to support
|
|
|
|
// bad code by allowing duplicate definitions for this particular case.
|
|
|
|
//
|
|
|
|
// The compiler creates common symbols when it sees tentative definitions.
|
|
|
|
// (You can suppress this behavior and let the compiler create a regular
|
[lld/mac] Implement support for private extern symbols
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
2020-12-18 02:30:18 +08:00
|
|
|
// defined symbol by passing -fno-common. -fno-common is the default in clang
|
|
|
|
// as of LLVM 11.0.) When linking the final binary, if there are remaining
|
|
|
|
// common symbols after name resolution is complete, the linker converts them
|
|
|
|
// to regular defined symbols in a __common section.
|
2020-09-25 05:44:14 +08:00
|
|
|
class CommonSymbol : public Symbol {
|
|
|
|
public:
|
[lld/mac] Implement support for private extern symbols
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
2020-12-18 02:30:18 +08:00
|
|
|
CommonSymbol(StringRefZ name, InputFile *file, uint64_t size, uint32_t align,
|
|
|
|
bool isPrivateExtern)
|
2021-02-04 02:31:40 +08:00
|
|
|
: Symbol(CommonKind, name, file), size(size),
|
[lld/mac] Implement support for private extern symbols
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
2020-12-18 02:30:18 +08:00
|
|
|
align(align != 1 ? align : llvm::PowerOf2Ceil(size)),
|
|
|
|
privateExtern(isPrivateExtern) {
|
2020-09-25 05:44:14 +08:00
|
|
|
// TODO: cap maximum alignment
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool classof(const Symbol *s) { return s->kind() == CommonKind; }
|
|
|
|
|
|
|
|
const uint64_t size;
|
|
|
|
const uint32_t align;
|
[lld/mac] Implement support for private extern symbols
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
2020-12-18 02:30:18 +08:00
|
|
|
const bool privateExtern;
|
2020-09-25 05:44:14 +08:00
|
|
|
};
|
|
|
|
|
2020-04-22 04:37:57 +08:00
|
|
|
class DylibSymbol : public Symbol {
|
|
|
|
public:
|
2020-12-16 10:05:06 +08:00
|
|
|
DylibSymbol(DylibFile *file, StringRefZ name, bool isWeakDef,
|
|
|
|
RefState refState, bool isTlv)
|
2021-02-04 02:31:40 +08:00
|
|
|
: Symbol(DylibKind, name, file), refState(refState), weakDef(isWeakDef),
|
|
|
|
tlv(isTlv) {}
|
2020-07-25 06:55:25 +08:00
|
|
|
|
|
|
|
bool isWeakDef() const override { return weakDef; }
|
2020-12-16 10:05:06 +08:00
|
|
|
bool isWeakRef() const override { return refState == RefState::Weak; }
|
|
|
|
bool isReferenced() const { return refState != RefState::Unreferenced; }
|
2020-08-13 10:50:09 +08:00
|
|
|
bool isTlv() const override { return tlv; }
|
2020-08-28 06:54:42 +08:00
|
|
|
bool hasStubsHelper() const { return stubsHelperIndex != UINT32_MAX; }
|
2021-02-04 02:31:40 +08:00
|
|
|
DylibFile *getFile() const { return cast<DylibFile>(file); }
|
2020-08-13 10:50:09 +08:00
|
|
|
|
2020-04-22 04:37:57 +08:00
|
|
|
static bool classof(const Symbol *s) { return s->kind() == DylibKind; }
|
|
|
|
|
2020-08-28 06:54:42 +08:00
|
|
|
uint32_t stubsHelperIndex = UINT32_MAX;
|
[lld-macho] Support calls to functions in dylibs
Summary:
This diff implements lazy symbol binding -- very similar to the PLT
mechanism in ELF.
ELF's .plt section is broken up into two sections in Mach-O:
StubsSection and StubHelperSection. Calls to functions in dylibs will
end up calling into StubsSection, which contains indirect jumps to
addresses stored in the LazyPointerSection (the counterpart to ELF's
.plt.got).
Initially, the LazyPointerSection contains addresses that point into one
of the entry points in the middle of the StubHelperSection. The code in
StubHelperSection will push on the stack an offset into the
LazyBindingSection. The push is followed by a jump to the beginning of
the StubHelperSection (similar to PLT0), which then calls into
dyld_stub_binder. dyld_stub_binder is a non-lazily bound symbol, so this
call looks it up in the GOT.
The stub binder will look up the bind opcodes in the LazyBindingSection
at the given offset. The bind opcodes will tell the binder to update the
address in the LazyPointerSection to point to the symbol, so that
subsequent calls don't have to redo the symbol resolution. The binder
will then jump to the resolved symbol.
Depends on D78269.
Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78270
2020-05-06 08:38:10 +08:00
|
|
|
uint32_t lazyBindOffset = UINT32_MAX;
|
2020-07-25 06:55:25 +08:00
|
|
|
|
2020-12-16 10:05:06 +08:00
|
|
|
RefState refState : 2;
|
|
|
|
|
2020-07-25 06:55:25 +08:00
|
|
|
private:
|
2020-12-16 10:05:06 +08:00
|
|
|
const bool weakDef : 1;
|
|
|
|
const bool tlv : 1;
|
2020-04-22 04:37:57 +08:00
|
|
|
};
|
|
|
|
|
2020-05-15 03:43:51 +08:00
|
|
|
class LazySymbol : public Symbol {
|
|
|
|
public:
|
|
|
|
LazySymbol(ArchiveFile *file, const llvm::object::Archive::Symbol &sym)
|
2021-02-04 02:31:40 +08:00
|
|
|
: Symbol(LazyKind, sym.getName(), file), sym(sym) {}
|
2020-05-15 03:43:51 +08:00
|
|
|
|
2021-02-04 02:31:40 +08:00
|
|
|
ArchiveFile *getFile() const { return cast<ArchiveFile>(file); }
|
2020-05-15 03:43:51 +08:00
|
|
|
void fetchArchiveMember();
|
|
|
|
|
2021-02-04 02:31:40 +08:00
|
|
|
static bool classof(const Symbol *s) { return s->kind() == LazyKind; }
|
|
|
|
|
2020-05-15 03:43:51 +08:00
|
|
|
private:
|
|
|
|
const llvm::object::Archive::Symbol sym;
|
|
|
|
};
|
|
|
|
|
2020-07-31 05:28:41 +08:00
|
|
|
// The Itanium C++ ABI requires dylibs to pass a pointer to __cxa_atexit which
|
|
|
|
// does e.g. cleanup of static global variables. The ABI document says that the
|
|
|
|
// pointer can point to any address in one of the dylib's segments, but in
|
|
|
|
// practice ld64 seems to set it to point to the header, so that's what's
|
|
|
|
// implemented here.
|
|
|
|
//
|
|
|
|
// The ARM C++ ABI uses __dso_handle similarly, but I (int3) have not yet
|
|
|
|
// tested this on an ARM platform.
|
|
|
|
//
|
|
|
|
// DSOHandle effectively functions like a Defined symbol, but it doesn't belong
|
|
|
|
// to an InputSection.
|
|
|
|
class DSOHandle : public Symbol {
|
|
|
|
public:
|
|
|
|
DSOHandle(const MachHeaderSection *header)
|
2021-02-04 02:31:40 +08:00
|
|
|
: Symbol(DSOHandleKind, name, nullptr), header(header) {}
|
2020-04-03 02:54:05 +08:00
|
|
|
|
2020-07-31 05:28:41 +08:00
|
|
|
const MachHeaderSection *header;
|
|
|
|
|
|
|
|
uint64_t getVA() const override;
|
|
|
|
|
|
|
|
uint64_t getFileOffset() const override;
|
|
|
|
|
2020-08-28 06:59:48 +08:00
|
|
|
bool isWeakDef() const override { return false; }
|
|
|
|
|
|
|
|
bool isTlv() const override { return false; }
|
|
|
|
|
2020-07-31 05:28:41 +08:00
|
|
|
static constexpr StringRef name = "___dso_handle";
|
|
|
|
|
2020-08-28 06:59:48 +08:00
|
|
|
static bool classof(const Symbol *s) { return s->kind() == DSOHandleKind; }
|
2020-07-31 05:28:41 +08:00
|
|
|
};
|
2020-05-19 11:28:50 +08:00
|
|
|
|
2020-04-03 02:54:05 +08:00
|
|
|
union SymbolUnion {
|
|
|
|
alignas(Defined) char a[sizeof(Defined)];
|
|
|
|
alignas(Undefined) char b[sizeof(Undefined)];
|
2020-09-25 05:44:14 +08:00
|
|
|
alignas(CommonSymbol) char c[sizeof(CommonSymbol)];
|
|
|
|
alignas(DylibSymbol) char d[sizeof(DylibSymbol)];
|
|
|
|
alignas(LazySymbol) char e[sizeof(LazySymbol)];
|
|
|
|
alignas(DSOHandle) char f[sizeof(DSOHandle)];
|
2020-04-03 02:54:05 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
template <typename T, typename... ArgT>
|
2020-08-28 06:59:30 +08:00
|
|
|
T *replaceSymbol(Symbol *s, ArgT &&... arg) {
|
2020-04-03 02:54:05 +08:00
|
|
|
static_assert(sizeof(T) <= sizeof(SymbolUnion), "SymbolUnion too small");
|
|
|
|
static_assert(alignof(T) <= alignof(SymbolUnion),
|
|
|
|
"SymbolUnion not aligned enough");
|
|
|
|
assert(static_cast<Symbol *>(static_cast<T *>(nullptr)) == nullptr &&
|
|
|
|
"Not a Symbol");
|
|
|
|
|
2020-08-28 06:59:30 +08:00
|
|
|
return new (s) T(std::forward<ArgT>(arg)...);
|
2020-04-03 02:54:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace macho
|
|
|
|
|
|
|
|
std::string toString(const macho::Symbol &);
|
2020-11-20 23:14:57 +08:00
|
|
|
std::string toMachOString(const llvm::object::Archive::Symbol &);
|
|
|
|
|
2020-04-03 02:54:05 +08:00
|
|
|
} // namespace lld
|
|
|
|
|
|
|
|
#endif
|