2015-08-14 22:12:54 +08:00
|
|
|
//===- Symbols.h ------------------------------------------------*- C++ -*-===//
|
2015-05-29 03:09:30 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// 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
|
2015-05-29 03:09:30 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLD_COFF_SYMBOLS_H
|
|
|
|
#define LLD_COFF_SYMBOLS_H
|
|
|
|
|
|
|
|
#include "Chunks.h"
|
|
|
|
#include "Config.h"
|
2017-10-03 05:00:41 +08:00
|
|
|
#include "lld/Common/LLVM.h"
|
2017-11-29 04:39:17 +08:00
|
|
|
#include "lld/Common/Memory.h"
|
2015-05-29 03:09:30 +08:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
|
|
|
#include "llvm/Object/Archive.h"
|
|
|
|
#include "llvm/Object/COFF.h"
|
2015-07-06 05:54:42 +08:00
|
|
|
#include <atomic>
|
2015-05-29 03:09:30 +08:00
|
|
|
#include <memory>
|
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
namespace lld {
|
2019-07-24 03:00:01 +08:00
|
|
|
|
|
|
|
std::string toString(coff::Symbol &b);
|
|
|
|
|
|
|
|
// There are two different ways to convert an Archive::Symbol to a string:
|
|
|
|
// One for Microsoft name mangling and one for Itanium name mangling.
|
|
|
|
// Call the functions toCOFFString and toELFString, not just toString.
|
|
|
|
std::string toCOFFString(const coff::Archive::Symbol &b);
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
namespace coff {
|
|
|
|
|
|
|
|
using llvm::object::Archive;
|
|
|
|
using llvm::object::COFFSymbolRef;
|
2015-05-29 23:45:35 +08:00
|
|
|
using llvm::object::coff_import_header;
|
2015-06-30 08:10:54 +08:00
|
|
|
using llvm::object::coff_symbol_generic;
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
class ArchiveFile;
|
|
|
|
class InputFile;
|
2017-07-27 07:05:24 +08:00
|
|
|
class ObjFile;
|
2016-12-10 05:55:24 +08:00
|
|
|
class SymbolTable;
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
// The base class for real symbol classes.
|
2017-11-04 05:21:47 +08:00
|
|
|
class Symbol {
|
2015-05-29 03:09:30 +08:00
|
|
|
public:
|
|
|
|
enum Kind {
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
// The order of these is significant. We start with the regular defined
|
2019-01-15 03:05:21 +08:00
|
|
|
// symbols as those are the most prevalent and the zero tag is the cheapest
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
// to set. Among the defined kinds, the lower the kind is preferred over
|
2018-08-27 22:22:25 +08:00
|
|
|
// the higher kind when testing whether one symbol should take precedence
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
// over another.
|
|
|
|
DefinedRegularKind = 0,
|
2015-06-20 15:21:57 +08:00
|
|
|
DefinedCommonKind,
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
DefinedLocalImportKind,
|
|
|
|
DefinedImportThunkKind,
|
|
|
|
DefinedImportDataKind,
|
|
|
|
DefinedAbsoluteKind,
|
[COFF] Improve synthetic symbol handling
Summary:
The main change is that we can have SECREL and SECTION relocations
against ___safe_se_handler_table, which is important for handling the
debug info in the MSVCRT.
Previously we were using DefinedRelative for __safe_se_handler_table and
__ImageBase, and after we implement CFGuard, we plan to extend it to
handle __guard_fids_table, __guard_longjmp_table, and more. However,
DefinedRelative is really only suitable for implementing __ImageBase,
because it lacks a Chunk, which you need in order to figure out the
output section index and output section offset when resolving SECREl and
SECTION relocations.
This change renames DefinedRelative to DefinedSynthetic and gives it a
Chunk. One wart is that __ImageBase doesn't have a chunk. It points to
the PE header, effectively. We could split DefinedRelative and
DefinedSynthetic if we think that's cleaner and creates fewer special
cases.
I also added safeseh.s, which checks that we don't emit a safe seh table
entries pointing to garbage collected handlers and that we don't emit a
table at all when there are no handlers.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: inglorion, pcc, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34577
llvm-svn: 306293
2017-06-26 23:39:52 +08:00
|
|
|
DefinedSyntheticKind,
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
|
2015-06-16 03:06:53 +08:00
|
|
|
UndefinedKind,
|
2019-09-04 04:32:16 +08:00
|
|
|
LazyArchiveKind,
|
|
|
|
LazyObjectKind,
|
[LLD] [COFF] Support linking directly against DLLs in MinGW mode
GNU ld.bfd supports linking directly against DLLs without using an
import library, and some projects have picked up on this habit.
(There's no one single unsurmountable issue with using import
libraries, but this is a regularly surfacing missing feature.)
As long as one is linking by name (instead of by ordinal), the DLL
export table contains most of the information needed. (One can
inspect what section a symbol points at, to see if it's a function
or data symbol. The practical implementation of this loops over all
sections for each symbol, but as long as they're not very many, that
should hopefully be tolerable performance wise.)
One exception where the information in the DLL isn't entirely enough
is on i386 with stdcall functions; depending on how they're done,
the exported function name can be a plain undecorated name, while
the import library would contain the full decorated symbol name. This
issue is addressed separately in a different patch.
This is implemented mimicing the structure of a regular import library,
with one InputFile corresponding to the static archive that just adds
lazy symbols, which then are fetched when they are needed. When such
a symbol is fetched, we synthesize a coff_import_header structure
in memory and create a regular ImportFile out of it.
The implementation could be even smaller by just creating ImportFiles
for every symbol available immediately, but that would have the
drawback of actually ending up importing all symbols unless running
with GC enabled (and mingw mode defaults to having it disabled for
historical reasons).
Differential Revision: https://reviews.llvm.org/D104530
2021-06-16 21:59:46 +08:00
|
|
|
LazyDLLSymbolKind,
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
|
|
|
|
LastDefinedCOFFKind = DefinedCommonKind,
|
[COFF] Improve synthetic symbol handling
Summary:
The main change is that we can have SECREL and SECTION relocations
against ___safe_se_handler_table, which is important for handling the
debug info in the MSVCRT.
Previously we were using DefinedRelative for __safe_se_handler_table and
__ImageBase, and after we implement CFGuard, we plan to extend it to
handle __guard_fids_table, __guard_longjmp_table, and more. However,
DefinedRelative is really only suitable for implementing __ImageBase,
because it lacks a Chunk, which you need in order to figure out the
output section index and output section offset when resolving SECREl and
SECTION relocations.
This change renames DefinedRelative to DefinedSynthetic and gives it a
Chunk. One wart is that __ImageBase doesn't have a chunk. It points to
the PE header, effectively. We could split DefinedRelative and
DefinedSynthetic if we think that's cleaner and creates fewer special
cases.
I also added safeseh.s, which checks that we don't emit a safe seh table
entries pointing to garbage collected handlers and that we don't emit a
table at all when there are no handlers.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: inglorion, pcc, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34577
llvm-svn: 306293
2017-06-26 23:39:52 +08:00
|
|
|
LastDefinedKind = DefinedSyntheticKind,
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
Kind kind() const { return static_cast<Kind>(symbolKind); }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
// Returns the symbol name.
|
2020-05-03 10:53:49 +08:00
|
|
|
StringRef getName() {
|
|
|
|
// COFF symbol names are read lazily for a performance reason.
|
|
|
|
// Non-external symbol names are never used by the linker except for logging
|
|
|
|
// or debugging. Their internal references are resolved not by name but by
|
|
|
|
// symbol index. And because they are not external, no one can refer them by
|
|
|
|
// name. Object files contain lots of non-external symbols, and creating
|
|
|
|
// StringRefs for them (which involves lots of strlen() on the string table)
|
|
|
|
// is a waste of time.
|
|
|
|
if (nameData == nullptr)
|
|
|
|
computeName();
|
|
|
|
return StringRef(nameData, nameSize);
|
|
|
|
}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
[COFF] Support MinGW automatic dllimport of data
Normally, in order to reference exported data symbols from a different
DLL, the declarations need to have the dllimport attribute, in order to
use the __imp_<var> symbol (which contains an address to the actual
variable) instead of the variable itself directly. This isn't an issue
in the same way for functions, since any reference to the function without
the dllimport attribute will end up as a reference to a thunk which loads
the actual target function from the import address table (IAT).
GNU ld, in MinGW environments, supports automatically importing data
symbols from DLLs, even if the references didn't have the appropriate
dllimport attribute. Since the PE/COFF format doesn't support the kind
of relocations that this would require, the MinGW's CRT startup code
has an custom framework of their own for manually fixing the missing
relocations once module is loaded and the target addresses in the IAT
are known.
For this to work, the linker (originall in GNU ld) creates a list of
remaining references needing fixup, which the runtime processes on
startup before handing over control to user code.
While this feature is rather controversial, it's one of the main features
allowing unix style libraries to be used on windows without any extra
porting effort.
Some sort of automatic fixing of data imports is also necessary for the
itanium C++ ABI on windows (as clang implements it right now) for importing
vtable pointers in certain cases, see D43184 for some discussion on that.
The runtime pseudo relocation handler supports 8/16/32/64 bit addresses,
either PC relative references (like IMAGE_REL_*_REL32*) or absolute
references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32,
IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a
relocation against the corresponding IAT slot. For the absolute references,
a normal base relocation is created, to update the embedded address
in case the image is loaded at a different address.
The list of runtime pseudo relocations contains the RVA of the
imported symbol (the IAT slot), the RVA of the location the relocation
should be applied to, and a size of the memory location. When the
relocations are fixed at runtime, the difference between the actual
IAT slot value and the IAT slot address is added to the reference,
doing the right thing for both absolute and relative references.
With this patch alone, things work fine for i386 binaries, and mostly
for x86_64 binaries, with feature parity with GNU ld. Despite this,
there are a few gotchas:
- References to data from within code works fine on both x86 architectures,
since their relocations consist of plain 32 or 64 bit absolute/relative
references. On ARM and AArch64, references to data doesn't consist of
a plain 32 or 64 bit embedded address or offset in the code. On ARMNT,
it's usually a MOVW+MOVT instruction pair represented by a
IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of
the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR
instruction pair with an even more complex encoding, storing a PC
relative address (with a range of +/- 4 GB). This could theoretically
be remedied by extending the runtime pseudo relocation handler with new
relocation types, to support these instruction encodings. This isn't an
issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64.
- For x86_64, if references in code are encoded as 32 bit PC relative
offsets, the runtime relocation will fail if the target turns out to be
out of range for a 32 bit offset.
- Fixing up the relocations at runtime requires making sections writable
if necessary, with the VirtualProtect function. In Windows Store/UWP apps,
this function is forbidden.
These limitations are addressed by a few later patches in lld and
llvm.
Differential Revision: https://reviews.llvm.org/D50917
llvm-svn: 340726
2018-08-27 16:43:31 +08:00
|
|
|
void replaceKeepingName(Symbol *other, size_t size);
|
|
|
|
|
2016-12-08 07:17:02 +08:00
|
|
|
// Returns the file from which this symbol was created.
|
|
|
|
InputFile *getFile();
|
|
|
|
|
2017-07-28 02:25:59 +08:00
|
|
|
// Indicates that this symbol will be included in the final image. Only valid
|
|
|
|
// after calling markLive.
|
|
|
|
bool isLive() const;
|
|
|
|
|
2019-09-04 04:32:16 +08:00
|
|
|
bool isLazy() const {
|
[LLD] [COFF] Support linking directly against DLLs in MinGW mode
GNU ld.bfd supports linking directly against DLLs without using an
import library, and some projects have picked up on this habit.
(There's no one single unsurmountable issue with using import
libraries, but this is a regularly surfacing missing feature.)
As long as one is linking by name (instead of by ordinal), the DLL
export table contains most of the information needed. (One can
inspect what section a symbol points at, to see if it's a function
or data symbol. The practical implementation of this loops over all
sections for each symbol, but as long as they're not very many, that
should hopefully be tolerable performance wise.)
One exception where the information in the DLL isn't entirely enough
is on i386 with stdcall functions; depending on how they're done,
the exported function name can be a plain undecorated name, while
the import library would contain the full decorated symbol name. This
issue is addressed separately in a different patch.
This is implemented mimicing the structure of a regular import library,
with one InputFile corresponding to the static archive that just adds
lazy symbols, which then are fetched when they are needed. When such
a symbol is fetched, we synthesize a coff_import_header structure
in memory and create a regular ImportFile out of it.
The implementation could be even smaller by just creating ImportFiles
for every symbol available immediately, but that would have the
drawback of actually ending up importing all symbols unless running
with GC enabled (and mingw mode defaults to having it disabled for
historical reasons).
Differential Revision: https://reviews.llvm.org/D104530
2021-06-16 21:59:46 +08:00
|
|
|
return symbolKind == LazyArchiveKind || symbolKind == LazyObjectKind ||
|
|
|
|
symbolKind == LazyDLLSymbolKind;
|
2019-09-04 04:32:16 +08:00
|
|
|
}
|
|
|
|
|
2020-05-03 10:53:49 +08:00
|
|
|
private:
|
|
|
|
void computeName();
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
protected:
|
2016-12-10 05:55:24 +08:00
|
|
|
friend SymbolTable;
|
2017-11-04 05:21:47 +08:00
|
|
|
explicit Symbol(Kind k, StringRef n = "")
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
: symbolKind(k), isExternal(true), isCOMDAT(false),
|
2017-11-21 09:14:14 +08:00
|
|
|
writtenToSymtab(false), pendingArchiveLoad(false), isGCRoot(false),
|
2020-10-06 18:54:49 +08:00
|
|
|
isRuntimePseudoReloc(false), deferUndefined(false), canInline(true),
|
|
|
|
nameSize(n.size()), nameData(n.empty() ? nullptr : n.data()) {}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
const unsigned symbolKind : 8;
|
|
|
|
unsigned isExternal : 1;
|
|
|
|
|
2019-07-10 17:10:01 +08:00
|
|
|
public:
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
// This bit is used by the \c DefinedRegular subclass.
|
|
|
|
unsigned isCOMDAT : 1;
|
|
|
|
|
2017-11-21 09:14:14 +08:00
|
|
|
// This bit is used by Writer::createSymbolAndStringTable() to prevent
|
|
|
|
// symbols from being written to the symbol table more than once.
|
|
|
|
unsigned writtenToSymtab : 1;
|
|
|
|
|
2017-11-01 00:10:24 +08:00
|
|
|
// True if this symbol was referenced by a regular (non-bitcode) object.
|
|
|
|
unsigned isUsedInRegularObj : 1;
|
|
|
|
|
|
|
|
// True if we've seen both a lazy and an undefined symbol with this symbol
|
|
|
|
// name, which means that we have enqueued an archive member load and should
|
|
|
|
// not load any more archive members to resolve the same symbol.
|
|
|
|
unsigned pendingArchiveLoad : 1;
|
|
|
|
|
2017-11-14 02:38:53 +08:00
|
|
|
/// True if we've already added this symbol to the list of GC roots.
|
|
|
|
unsigned isGCRoot : 1;
|
|
|
|
|
2018-09-26 14:13:39 +08:00
|
|
|
unsigned isRuntimePseudoReloc : 1;
|
|
|
|
|
2020-10-06 18:54:49 +08:00
|
|
|
// True if we want to allow this symbol to be undefined in the early
|
|
|
|
// undefined check pass in SymbolTable::reportUnresolvable(), as it
|
|
|
|
// might be fixed up later.
|
|
|
|
unsigned deferUndefined : 1;
|
|
|
|
|
|
|
|
// False if LTO shouldn't inline whatever this symbol points to. If a symbol
|
|
|
|
// is overwritten after LTO, LTO shouldn't inline the symbol because it
|
|
|
|
// doesn't know the final contents of the symbol.
|
|
|
|
unsigned canInline : 1;
|
|
|
|
|
2016-12-12 06:15:20 +08:00
|
|
|
protected:
|
2019-04-20 06:51:49 +08:00
|
|
|
// Symbol name length. Assume symbol lengths fit in a 32-bit integer.
|
|
|
|
uint32_t nameSize;
|
|
|
|
|
|
|
|
const char *nameData;
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// The base class for any defined symbols, including absolute symbols,
|
|
|
|
// etc.
|
2017-11-04 05:21:47 +08:00
|
|
|
class Defined : public Symbol {
|
2015-05-29 03:09:30 +08:00
|
|
|
public:
|
2017-11-04 05:21:47 +08:00
|
|
|
Defined(Kind k, StringRef n) : Symbol(k, n) {}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
static bool classof(const Symbol *s) { return s->kind() <= LastDefinedKind; }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
// Returns the RVA (relative virtual address) of this symbol. The
|
|
|
|
// writer sets and uses RVAs.
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
uint64_t getRVA();
|
2015-05-29 03:09:30 +08:00
|
|
|
|
[COFF] Allow debug info to relocate against discarded symbols
Summary:
In order to do this without switching on the symbol kind multiple times,
I created Defined::getChunkAndOffset and use that instead of
SymbolBody::getRVA in the inner relocation loop.
Now we get the symbol's chunk before switching over relocation types, so
we can test if it has been discarded outside the inner relocation type
switch. This also simplifies application of section relative
relocations. Previously we would switch on symbol kind to compute the
RVA, then the relocation type, and then the symbol kind again to get the
output section so we could subtract that from the symbol RVA. Now we
*always* have an OutputSection, so applying SECREL and SECTION
relocations isn't as much of a special case.
I'm still not quite happy with the cleanliness of this code. I'm not
sure what offsets and bases we should be using during the relocation
processing loop: VA, RVA, or OutputSectionOffset.
Reviewers: ruiu, pcc
Reviewed By: ruiu
Subscribers: majnemer, inglorion, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34650
llvm-svn: 306566
2017-06-29 01:06:35 +08:00
|
|
|
// Returns the chunk containing this symbol. Absolute symbols and __ImageBase
|
|
|
|
// do not have chunks, so this may return null.
|
|
|
|
Chunk *getChunk();
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
};
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2017-02-03 07:58:14 +08:00
|
|
|
// Symbols defined via a COFF object file or bitcode file. For COFF files, this
|
|
|
|
// stores a coff_symbol_generic*, and names of internal symbols are lazily
|
|
|
|
// loaded through that. For bitcode files, Sym is nullptr and the name is stored
|
2019-04-20 06:51:49 +08:00
|
|
|
// as a decomposed StringRef.
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
class DefinedCOFF : public Defined {
|
2017-11-04 05:21:47 +08:00
|
|
|
friend Symbol;
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
public:
|
2017-02-03 07:58:14 +08:00
|
|
|
DefinedCOFF(Kind k, InputFile *f, StringRef n, const coff_symbol_generic *s)
|
|
|
|
: Defined(k, n), file(f), sym(s) {}
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
static bool classof(const Symbol *s) {
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
return s->kind() <= LastDefinedCOFFKind;
|
|
|
|
}
|
|
|
|
|
2017-02-03 07:58:14 +08:00
|
|
|
InputFile *getFile() { return file; }
|
2015-07-03 04:33:48 +08:00
|
|
|
|
2015-07-10 01:43:50 +08:00
|
|
|
COFFSymbolRef getCOFFSymbol();
|
|
|
|
|
2017-02-03 07:58:14 +08:00
|
|
|
InputFile *file;
|
2016-12-08 07:17:02 +08:00
|
|
|
|
|
|
|
protected:
|
2015-06-30 08:10:54 +08:00
|
|
|
const coff_symbol_generic *sym;
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// Regular defined symbols read from object file symbol tables.
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
class DefinedRegular : public DefinedCOFF {
|
2015-05-29 03:09:30 +08:00
|
|
|
public:
|
2017-02-03 07:58:14 +08:00
|
|
|
DefinedRegular(InputFile *f, StringRef n, bool isCOMDAT,
|
|
|
|
bool isExternal = false,
|
|
|
|
const coff_symbol_generic *s = nullptr,
|
|
|
|
SectionChunk *c = nullptr)
|
2017-02-04 07:05:17 +08:00
|
|
|
: DefinedCOFF(DefinedRegularKind, f, n, s), data(c ? &c->repl : nullptr) {
|
2017-02-03 07:58:14 +08:00
|
|
|
this->isExternal = isExternal;
|
|
|
|
this->isCOMDAT = isCOMDAT;
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
static bool classof(const Symbol *s) {
|
2015-05-29 03:09:30 +08:00
|
|
|
return s->kind() == DefinedRegularKind;
|
|
|
|
}
|
|
|
|
|
2017-07-28 02:25:59 +08:00
|
|
|
uint64_t getRVA() const { return (*data)->getRVA() + sym->Value; }
|
|
|
|
SectionChunk *getChunk() const { return *data; }
|
|
|
|
uint32_t getValue() const { return sym->Value; }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2015-06-26 06:00:42 +08:00
|
|
|
SectionChunk **data;
|
2015-06-20 15:21:57 +08:00
|
|
|
};
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
class DefinedCommon : public DefinedCOFF {
|
2015-06-20 15:21:57 +08:00
|
|
|
public:
|
2017-02-03 07:58:14 +08:00
|
|
|
DefinedCommon(InputFile *f, StringRef n, uint64_t size,
|
|
|
|
const coff_symbol_generic *s = nullptr,
|
|
|
|
CommonChunk *c = nullptr)
|
|
|
|
: DefinedCOFF(DefinedCommonKind, f, n, s), data(c), size(size) {
|
|
|
|
this->isExternal = true;
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
}
|
2015-06-20 15:21:57 +08:00
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
static bool classof(const Symbol *s) {
|
2015-06-20 15:21:57 +08:00
|
|
|
return s->kind() == DefinedCommonKind;
|
|
|
|
}
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
uint64_t getRVA() { return data->getRVA(); }
|
2017-08-15 03:07:27 +08:00
|
|
|
CommonChunk *getChunk() { return data; }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
private:
|
2016-12-10 05:55:24 +08:00
|
|
|
friend SymbolTable;
|
2017-02-03 07:58:14 +08:00
|
|
|
uint64_t getSize() const { return size; }
|
2015-06-26 03:10:58 +08:00
|
|
|
CommonChunk *data;
|
2017-02-03 07:58:14 +08:00
|
|
|
uint64_t size;
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// Absolute symbols.
|
|
|
|
class DefinedAbsolute : public Defined {
|
|
|
|
public:
|
2015-06-26 11:09:23 +08:00
|
|
|
DefinedAbsolute(StringRef n, COFFSymbolRef s)
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
: Defined(DefinedAbsoluteKind, n), va(s.getValue()) {
|
|
|
|
isExternal = s.isExternal();
|
|
|
|
}
|
2015-06-26 11:09:23 +08:00
|
|
|
|
|
|
|
DefinedAbsolute(StringRef n, uint64_t v)
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
: Defined(DefinedAbsoluteKind, n), va(v) {}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
static bool classof(const Symbol *s) {
|
2015-05-29 03:09:30 +08:00
|
|
|
return s->kind() == DefinedAbsoluteKind;
|
|
|
|
}
|
|
|
|
|
[opt] Devirtualize the SymbolBody type hierarchy and start compacting
its members into the base class.
First, to help motivate this kind of change, understand that in
a self-link, LLD creates 5.5 million defined regular symbol bodies (and
6 million symbol bodies total). A significant portion of its time is
spent allocating the memory for these symbols, and befor ethis patch
the defined regular symbol body objects alone consumed some 420mb of
memory during the self link.
As a consequence, I think it is worth expending considerable effort to
make these objects as memory efficient as possible. This is the first of
several components of that. This change starts with the goal of removing
the virtual functins from SymbolBody so that it can avoid having a vptr
embedded in it when it already contains a "kind" member, and that member
can be much more compact than a vptr.
The primary way of doing this is to sink as much of the logic that we
would have to dispatch for into data in the base class. As part of this,
I made the various flags bits that will pack into a bitfield with the
kind tag. I also sank the Name down to eliminate the dispatch for that,
and used LLVM's RTTI-style dispatch for everything else (most of which
is cold and so doesn't matter terribly if we get minutely worse lowering
than a vtable dispatch).
As I was doing this, I wanted to make the RTTI-dispatch (which would
become much hotter than before) as efficient as possible, so I've
re-organized the tags somewhat. Notably, the common case (regular
defined symbols) is now zero which we can test for faster.
I also needed to rewrite the comparison routine used during resolving
symbols. This proved to be quite complex as the semantics of the
existing one were very subtle due to the back-and-forth virtual dispatch
caused by re-dispatching with reversed operands. I've consolidated it to
a single function and tried to comment it quite a bit more to help
explain what is going on. However, this may need more comments or other
explanations. It at least passes all the regression tests. I'm not
working on Windows, so I can't fully test it.
With all of these changes, the size of a DefinedRegular symbol on
a 64-bit build goes from 80 bytes to 64 bytes, and we save approximately
84mb or 20% of the memory consumed by these symbol bodies during the
link.
The link time appears marginally faster as well, and the profile hotness
of the memory allocation subsystem got a bit better, but there is still
a lot of allocation traffic.
Differential Revision: http://reviews.llvm.org/D10792
llvm-svn: 241001
2015-06-30 05:35:48 +08:00
|
|
|
uint64_t getRVA() { return va - config->imageBase; }
|
2015-07-25 07:51:14 +08:00
|
|
|
void setVA(uint64_t v) { va = v; }
|
2020-01-06 19:54:12 +08:00
|
|
|
uint64_t getVA() const { return va; }
|
2019-12-30 06:32:22 +08:00
|
|
|
|
2018-02-18 04:41:38 +08:00
|
|
|
// Section index relocations against absolute symbols resolve to
|
|
|
|
// this 16 bit number, and it is the largest valid section index
|
|
|
|
// plus one. This variable keeps it.
|
|
|
|
static uint16_t numOutputSections;
|
2017-06-23 07:33:04 +08:00
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
private:
|
2015-06-26 11:09:23 +08:00
|
|
|
uint64_t va;
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
[COFF] Improve synthetic symbol handling
Summary:
The main change is that we can have SECREL and SECTION relocations
against ___safe_se_handler_table, which is important for handling the
debug info in the MSVCRT.
Previously we were using DefinedRelative for __safe_se_handler_table and
__ImageBase, and after we implement CFGuard, we plan to extend it to
handle __guard_fids_table, __guard_longjmp_table, and more. However,
DefinedRelative is really only suitable for implementing __ImageBase,
because it lacks a Chunk, which you need in order to figure out the
output section index and output section offset when resolving SECREl and
SECTION relocations.
This change renames DefinedRelative to DefinedSynthetic and gives it a
Chunk. One wart is that __ImageBase doesn't have a chunk. It points to
the PE header, effectively. We could split DefinedRelative and
DefinedSynthetic if we think that's cleaner and creates fewer special
cases.
I also added safeseh.s, which checks that we don't emit a safe seh table
entries pointing to garbage collected handlers and that we don't emit a
table at all when there are no handlers.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: inglorion, pcc, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34577
llvm-svn: 306293
2017-06-26 23:39:52 +08:00
|
|
|
// This symbol is used for linker-synthesized symbols like __ImageBase and
|
|
|
|
// __safe_se_handler_table.
|
|
|
|
class DefinedSynthetic : public Defined {
|
2015-07-25 06:58:44 +08:00
|
|
|
public:
|
[COFF] Improve synthetic symbol handling
Summary:
The main change is that we can have SECREL and SECTION relocations
against ___safe_se_handler_table, which is important for handling the
debug info in the MSVCRT.
Previously we were using DefinedRelative for __safe_se_handler_table and
__ImageBase, and after we implement CFGuard, we plan to extend it to
handle __guard_fids_table, __guard_longjmp_table, and more. However,
DefinedRelative is really only suitable for implementing __ImageBase,
because it lacks a Chunk, which you need in order to figure out the
output section index and output section offset when resolving SECREl and
SECTION relocations.
This change renames DefinedRelative to DefinedSynthetic and gives it a
Chunk. One wart is that __ImageBase doesn't have a chunk. It points to
the PE header, effectively. We could split DefinedRelative and
DefinedSynthetic if we think that's cleaner and creates fewer special
cases.
I also added safeseh.s, which checks that we don't emit a safe seh table
entries pointing to garbage collected handlers and that we don't emit a
table at all when there are no handlers.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: inglorion, pcc, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34577
llvm-svn: 306293
2017-06-26 23:39:52 +08:00
|
|
|
explicit DefinedSynthetic(StringRef name, Chunk *c)
|
|
|
|
: Defined(DefinedSyntheticKind, name), c(c) {}
|
2015-07-25 06:58:44 +08:00
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
static bool classof(const Symbol *s) {
|
[COFF] Improve synthetic symbol handling
Summary:
The main change is that we can have SECREL and SECTION relocations
against ___safe_se_handler_table, which is important for handling the
debug info in the MSVCRT.
Previously we were using DefinedRelative for __safe_se_handler_table and
__ImageBase, and after we implement CFGuard, we plan to extend it to
handle __guard_fids_table, __guard_longjmp_table, and more. However,
DefinedRelative is really only suitable for implementing __ImageBase,
because it lacks a Chunk, which you need in order to figure out the
output section index and output section offset when resolving SECREl and
SECTION relocations.
This change renames DefinedRelative to DefinedSynthetic and gives it a
Chunk. One wart is that __ImageBase doesn't have a chunk. It points to
the PE header, effectively. We could split DefinedRelative and
DefinedSynthetic if we think that's cleaner and creates fewer special
cases.
I also added safeseh.s, which checks that we don't emit a safe seh table
entries pointing to garbage collected handlers and that we don't emit a
table at all when there are no handlers.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: inglorion, pcc, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34577
llvm-svn: 306293
2017-06-26 23:39:52 +08:00
|
|
|
return s->kind() == DefinedSyntheticKind;
|
2015-07-25 06:58:44 +08:00
|
|
|
}
|
|
|
|
|
[COFF] Improve synthetic symbol handling
Summary:
The main change is that we can have SECREL and SECTION relocations
against ___safe_se_handler_table, which is important for handling the
debug info in the MSVCRT.
Previously we were using DefinedRelative for __safe_se_handler_table and
__ImageBase, and after we implement CFGuard, we plan to extend it to
handle __guard_fids_table, __guard_longjmp_table, and more. However,
DefinedRelative is really only suitable for implementing __ImageBase,
because it lacks a Chunk, which you need in order to figure out the
output section index and output section offset when resolving SECREl and
SECTION relocations.
This change renames DefinedRelative to DefinedSynthetic and gives it a
Chunk. One wart is that __ImageBase doesn't have a chunk. It points to
the PE header, effectively. We could split DefinedRelative and
DefinedSynthetic if we think that's cleaner and creates fewer special
cases.
I also added safeseh.s, which checks that we don't emit a safe seh table
entries pointing to garbage collected handlers and that we don't emit a
table at all when there are no handlers.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: inglorion, pcc, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34577
llvm-svn: 306293
2017-06-26 23:39:52 +08:00
|
|
|
// A null chunk indicates that this is __ImageBase. Otherwise, this is some
|
|
|
|
// other synthesized chunk, like SEHTableChunk.
|
[COFF] Allow debug info to relocate against discarded symbols
Summary:
In order to do this without switching on the symbol kind multiple times,
I created Defined::getChunkAndOffset and use that instead of
SymbolBody::getRVA in the inner relocation loop.
Now we get the symbol's chunk before switching over relocation types, so
we can test if it has been discarded outside the inner relocation type
switch. This also simplifies application of section relative
relocations. Previously we would switch on symbol kind to compute the
RVA, then the relocation type, and then the symbol kind again to get the
output section so we could subtract that from the symbol RVA. Now we
*always* have an OutputSection, so applying SECREL and SECTION
relocations isn't as much of a special case.
I'm still not quite happy with the cleanliness of this code. I'm not
sure what offsets and bases we should be using during the relocation
processing loop: VA, RVA, or OutputSectionOffset.
Reviewers: ruiu, pcc
Reviewed By: ruiu
Subscribers: majnemer, inglorion, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34650
llvm-svn: 306566
2017-06-29 01:06:35 +08:00
|
|
|
uint32_t getRVA() { return c ? c->getRVA() : 0; }
|
|
|
|
Chunk *getChunk() { return c; }
|
2015-07-25 06:58:44 +08:00
|
|
|
|
|
|
|
private:
|
[COFF] Improve synthetic symbol handling
Summary:
The main change is that we can have SECREL and SECTION relocations
against ___safe_se_handler_table, which is important for handling the
debug info in the MSVCRT.
Previously we were using DefinedRelative for __safe_se_handler_table and
__ImageBase, and after we implement CFGuard, we plan to extend it to
handle __guard_fids_table, __guard_longjmp_table, and more. However,
DefinedRelative is really only suitable for implementing __ImageBase,
because it lacks a Chunk, which you need in order to figure out the
output section index and output section offset when resolving SECREl and
SECTION relocations.
This change renames DefinedRelative to DefinedSynthetic and gives it a
Chunk. One wart is that __ImageBase doesn't have a chunk. It points to
the PE header, effectively. We could split DefinedRelative and
DefinedSynthetic if we think that's cleaner and creates fewer special
cases.
I also added safeseh.s, which checks that we don't emit a safe seh table
entries pointing to garbage collected handlers and that we don't emit a
table at all when there are no handlers.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: inglorion, pcc, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34577
llvm-svn: 306293
2017-06-26 23:39:52 +08:00
|
|
|
Chunk *c;
|
2015-07-25 06:58:44 +08:00
|
|
|
};
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
// This class represents a symbol defined in an archive file. It is
|
|
|
|
// created from an archive file header, and it knows how to load an
|
|
|
|
// object file from an archive to replace itself with a defined
|
2019-09-04 04:32:16 +08:00
|
|
|
// symbol. If the resolver finds both Undefined and LazyArchive for
|
|
|
|
// the same name, it will ask the LazyArchive to load a file.
|
|
|
|
class LazyArchive : public Symbol {
|
2015-05-29 03:09:30 +08:00
|
|
|
public:
|
2019-09-04 04:32:16 +08:00
|
|
|
LazyArchive(ArchiveFile *f, const Archive::Symbol s)
|
|
|
|
: Symbol(LazyArchiveKind, s.getName()), file(f), sym(s) {}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2019-09-04 04:32:16 +08:00
|
|
|
static bool classof(const Symbol *s) { return s->kind() == LazyArchiveKind; }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2019-08-23 03:40:07 +08:00
|
|
|
MemoryBufferRef getMemberBuffer();
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
ArchiveFile *file;
|
2019-08-31 07:24:41 +08:00
|
|
|
const Archive::Symbol sym;
|
2019-08-31 00:50:10 +08:00
|
|
|
};
|
|
|
|
|
2019-09-04 04:32:16 +08:00
|
|
|
class LazyObject : public Symbol {
|
|
|
|
public:
|
2022-01-05 07:11:44 +08:00
|
|
|
LazyObject(InputFile *f, StringRef n) : Symbol(LazyObjectKind, n), file(f) {}
|
2019-09-04 04:32:16 +08:00
|
|
|
static bool classof(const Symbol *s) { return s->kind() == LazyObjectKind; }
|
2022-01-05 07:11:44 +08:00
|
|
|
InputFile *file;
|
2019-09-04 04:32:16 +08:00
|
|
|
};
|
|
|
|
|
2021-07-21 04:56:00 +08:00
|
|
|
// MinGW only.
|
[LLD] [COFF] Support linking directly against DLLs in MinGW mode
GNU ld.bfd supports linking directly against DLLs without using an
import library, and some projects have picked up on this habit.
(There's no one single unsurmountable issue with using import
libraries, but this is a regularly surfacing missing feature.)
As long as one is linking by name (instead of by ordinal), the DLL
export table contains most of the information needed. (One can
inspect what section a symbol points at, to see if it's a function
or data symbol. The practical implementation of this loops over all
sections for each symbol, but as long as they're not very many, that
should hopefully be tolerable performance wise.)
One exception where the information in the DLL isn't entirely enough
is on i386 with stdcall functions; depending on how they're done,
the exported function name can be a plain undecorated name, while
the import library would contain the full decorated symbol name. This
issue is addressed separately in a different patch.
This is implemented mimicing the structure of a regular import library,
with one InputFile corresponding to the static archive that just adds
lazy symbols, which then are fetched when they are needed. When such
a symbol is fetched, we synthesize a coff_import_header structure
in memory and create a regular ImportFile out of it.
The implementation could be even smaller by just creating ImportFiles
for every symbol available immediately, but that would have the
drawback of actually ending up importing all symbols unless running
with GC enabled (and mingw mode defaults to having it disabled for
historical reasons).
Differential Revision: https://reviews.llvm.org/D104530
2021-06-16 21:59:46 +08:00
|
|
|
class LazyDLLSymbol : public Symbol {
|
|
|
|
public:
|
|
|
|
LazyDLLSymbol(DLLFile *f, DLLFile::Symbol *s, StringRef n)
|
|
|
|
: Symbol(LazyDLLSymbolKind, n), file(f), sym(s) {}
|
|
|
|
static bool classof(const Symbol *s) {
|
|
|
|
return s->kind() == LazyDLLSymbolKind;
|
|
|
|
}
|
|
|
|
|
|
|
|
DLLFile *file;
|
|
|
|
DLLFile::Symbol *sym;
|
|
|
|
};
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
// Undefined symbols.
|
2017-11-04 05:21:47 +08:00
|
|
|
class Undefined : public Symbol {
|
2015-05-29 03:09:30 +08:00
|
|
|
public:
|
2017-11-04 05:21:47 +08:00
|
|
|
explicit Undefined(StringRef n) : Symbol(UndefinedKind, n) {}
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
static bool classof(const Symbol *s) { return s->kind() == UndefinedKind; }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
|
|
|
// An undefined symbol can have a fallback symbol which gives an
|
|
|
|
// undefined symbol a second chance if it would remain undefined.
|
|
|
|
// If it remains undefined, it'll be replaced with whatever the
|
|
|
|
// Alias pointer points to.
|
2017-11-04 05:21:47 +08:00
|
|
|
Symbol *weakAlias = nullptr;
|
2015-07-04 13:28:41 +08:00
|
|
|
|
|
|
|
// If this symbol is external weak, try to resolve it to a defined
|
|
|
|
// symbol by searching the chain of fallback symbols. Returns the symbol if
|
|
|
|
// successful, otherwise returns null.
|
|
|
|
Defined *getWeakAlias();
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// Windows-specific classes.
|
|
|
|
|
2015-05-29 23:49:09 +08:00
|
|
|
// This class represents a symbol imported from a DLL. This has two
|
|
|
|
// names for internal use and external use. The former is used for
|
|
|
|
// name resolution, and the latter is used for the import descriptor
|
|
|
|
// table in an output. The former has "__imp_" prefix.
|
|
|
|
class DefinedImportData : public Defined {
|
|
|
|
public:
|
2016-12-10 05:55:24 +08:00
|
|
|
DefinedImportData(StringRef n, ImportFile *f)
|
2017-05-22 14:01:37 +08:00
|
|
|
: Defined(DefinedImportDataKind, n), file(f) {
|
|
|
|
}
|
2015-05-29 23:49:09 +08:00
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
static bool classof(const Symbol *s) {
|
2015-05-29 23:49:09 +08:00
|
|
|
return s->kind() == DefinedImportDataKind;
|
|
|
|
}
|
|
|
|
|
2016-12-10 05:55:24 +08:00
|
|
|
uint64_t getRVA() { return file->location->getRVA(); }
|
[COFF] Allow debug info to relocate against discarded symbols
Summary:
In order to do this without switching on the symbol kind multiple times,
I created Defined::getChunkAndOffset and use that instead of
SymbolBody::getRVA in the inner relocation loop.
Now we get the symbol's chunk before switching over relocation types, so
we can test if it has been discarded outside the inner relocation type
switch. This also simplifies application of section relative
relocations. Previously we would switch on symbol kind to compute the
RVA, then the relocation type, and then the symbol kind again to get the
output section so we could subtract that from the symbol RVA. Now we
*always* have an OutputSection, so applying SECREL and SECTION
relocations isn't as much of a special case.
I'm still not quite happy with the cleanliness of this code. I'm not
sure what offsets and bases we should be using during the relocation
processing loop: VA, RVA, or OutputSectionOffset.
Reviewers: ruiu, pcc
Reviewed By: ruiu
Subscribers: majnemer, inglorion, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34650
llvm-svn: 306566
2017-06-29 01:06:35 +08:00
|
|
|
Chunk *getChunk() { return file->location; }
|
|
|
|
void setLocation(Chunk *addressTable) { file->location = addressTable; }
|
|
|
|
|
2016-12-10 05:55:24 +08:00
|
|
|
StringRef getDLLName() { return file->dllName; }
|
|
|
|
StringRef getExternalName() { return file->externalName; }
|
|
|
|
uint16_t getOrdinal() { return file->hdr->OrdinalHint; }
|
2015-05-29 23:49:09 +08:00
|
|
|
|
2016-12-10 05:55:24 +08:00
|
|
|
ImportFile *file;
|
2020-11-18 10:02:13 +08:00
|
|
|
|
|
|
|
// This is a pointer to the synthetic symbol associated with the load thunk
|
|
|
|
// for this symbol that will be called if the DLL is delay-loaded. This is
|
|
|
|
// needed for Control Flow Guard because if this DefinedImportData symbol is a
|
|
|
|
// valid call target, the corresponding load thunk must also be marked as a
|
|
|
|
// valid call target.
|
|
|
|
DefinedSynthetic *loadThunkSym = nullptr;
|
2015-05-29 23:49:09 +08:00
|
|
|
};
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
// This class represents a symbol for a jump table entry which jumps
|
|
|
|
// to a function in a DLL. Linker are supposed to create such symbols
|
|
|
|
// without "__imp_" prefix for all function symbols exported from
|
|
|
|
// DLLs, so that you can call DLL functions as regular functions with
|
|
|
|
// a regular name. A function pointer is given as a DefinedImportData.
|
|
|
|
class DefinedImportThunk : public Defined {
|
|
|
|
public:
|
2015-07-26 05:54:50 +08:00
|
|
|
DefinedImportThunk(StringRef name, DefinedImportData *s, uint16_t machine);
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
static bool classof(const Symbol *s) {
|
2015-05-29 03:09:30 +08:00
|
|
|
return s->kind() == DefinedImportThunkKind;
|
|
|
|
}
|
|
|
|
|
2015-07-25 09:16:06 +08:00
|
|
|
uint64_t getRVA() { return data->getRVA(); }
|
2016-12-13 02:42:09 +08:00
|
|
|
Chunk *getChunk() { return data; }
|
2015-05-29 03:09:30 +08:00
|
|
|
|
2017-05-25 06:30:06 +08:00
|
|
|
DefinedImportData *wrappedSym;
|
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
private:
|
2016-12-13 02:42:09 +08:00
|
|
|
Chunk *data;
|
2015-05-29 03:09:30 +08:00
|
|
|
};
|
|
|
|
|
2018-08-07 14:42:53 +08:00
|
|
|
// If you have a symbol "foo" in your object file, a symbol name
|
|
|
|
// "__imp_foo" becomes automatically available as a pointer to "foo".
|
2015-06-25 11:31:47 +08:00
|
|
|
// This class is for such automatically-created symbols.
|
|
|
|
// Yes, this is an odd feature. We didn't intend to implement that.
|
|
|
|
// This is here just for compatibility with MSVC.
|
|
|
|
class DefinedLocalImport : public Defined {
|
|
|
|
public:
|
|
|
|
DefinedLocalImport(StringRef n, Defined *s)
|
2017-05-22 14:01:37 +08:00
|
|
|
: Defined(DefinedLocalImportKind, n), data(make<LocalImportChunk>(s)) {}
|
2015-06-25 11:31:47 +08:00
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
static bool classof(const Symbol *s) {
|
2015-06-25 11:31:47 +08:00
|
|
|
return s->kind() == DefinedLocalImportKind;
|
|
|
|
}
|
|
|
|
|
2016-12-10 05:55:24 +08:00
|
|
|
uint64_t getRVA() { return data->getRVA(); }
|
2016-12-13 02:42:09 +08:00
|
|
|
Chunk *getChunk() { return data; }
|
2015-06-25 11:31:47 +08:00
|
|
|
|
|
|
|
private:
|
2016-12-13 02:42:09 +08:00
|
|
|
LocalImportChunk *data;
|
2015-06-25 11:31:47 +08:00
|
|
|
};
|
|
|
|
|
2015-07-14 06:01:27 +08:00
|
|
|
inline uint64_t Defined::getRVA() {
|
|
|
|
switch (kind()) {
|
|
|
|
case DefinedAbsoluteKind:
|
|
|
|
return cast<DefinedAbsolute>(this)->getRVA();
|
[COFF] Improve synthetic symbol handling
Summary:
The main change is that we can have SECREL and SECTION relocations
against ___safe_se_handler_table, which is important for handling the
debug info in the MSVCRT.
Previously we were using DefinedRelative for __safe_se_handler_table and
__ImageBase, and after we implement CFGuard, we plan to extend it to
handle __guard_fids_table, __guard_longjmp_table, and more. However,
DefinedRelative is really only suitable for implementing __ImageBase,
because it lacks a Chunk, which you need in order to figure out the
output section index and output section offset when resolving SECREl and
SECTION relocations.
This change renames DefinedRelative to DefinedSynthetic and gives it a
Chunk. One wart is that __ImageBase doesn't have a chunk. It points to
the PE header, effectively. We could split DefinedRelative and
DefinedSynthetic if we think that's cleaner and creates fewer special
cases.
I also added safeseh.s, which checks that we don't emit a safe seh table
entries pointing to garbage collected handlers and that we don't emit a
table at all when there are no handlers.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: inglorion, pcc, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34577
llvm-svn: 306293
2017-06-26 23:39:52 +08:00
|
|
|
case DefinedSyntheticKind:
|
|
|
|
return cast<DefinedSynthetic>(this)->getRVA();
|
2015-07-14 06:01:27 +08:00
|
|
|
case DefinedImportDataKind:
|
|
|
|
return cast<DefinedImportData>(this)->getRVA();
|
|
|
|
case DefinedImportThunkKind:
|
|
|
|
return cast<DefinedImportThunk>(this)->getRVA();
|
|
|
|
case DefinedLocalImportKind:
|
|
|
|
return cast<DefinedLocalImport>(this)->getRVA();
|
|
|
|
case DefinedCommonKind:
|
|
|
|
return cast<DefinedCommon>(this)->getRVA();
|
|
|
|
case DefinedRegularKind:
|
|
|
|
return cast<DefinedRegular>(this)->getRVA();
|
2019-09-04 04:32:16 +08:00
|
|
|
case LazyArchiveKind:
|
|
|
|
case LazyObjectKind:
|
[LLD] [COFF] Support linking directly against DLLs in MinGW mode
GNU ld.bfd supports linking directly against DLLs without using an
import library, and some projects have picked up on this habit.
(There's no one single unsurmountable issue with using import
libraries, but this is a regularly surfacing missing feature.)
As long as one is linking by name (instead of by ordinal), the DLL
export table contains most of the information needed. (One can
inspect what section a symbol points at, to see if it's a function
or data symbol. The practical implementation of this loops over all
sections for each symbol, but as long as they're not very many, that
should hopefully be tolerable performance wise.)
One exception where the information in the DLL isn't entirely enough
is on i386 with stdcall functions; depending on how they're done,
the exported function name can be a plain undecorated name, while
the import library would contain the full decorated symbol name. This
issue is addressed separately in a different patch.
This is implemented mimicing the structure of a regular import library,
with one InputFile corresponding to the static archive that just adds
lazy symbols, which then are fetched when they are needed. When such
a symbol is fetched, we synthesize a coff_import_header structure
in memory and create a regular ImportFile out of it.
The implementation could be even smaller by just creating ImportFiles
for every symbol available immediately, but that would have the
drawback of actually ending up importing all symbols unless running
with GC enabled (and mingw mode defaults to having it disabled for
historical reasons).
Differential Revision: https://reviews.llvm.org/D104530
2021-06-16 21:59:46 +08:00
|
|
|
case LazyDLLSymbolKind:
|
2015-07-14 06:01:27 +08:00
|
|
|
case UndefinedKind:
|
|
|
|
llvm_unreachable("Cannot get the address for an undefined symbol.");
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown symbol kind");
|
|
|
|
}
|
|
|
|
|
[COFF] Allow debug info to relocate against discarded symbols
Summary:
In order to do this without switching on the symbol kind multiple times,
I created Defined::getChunkAndOffset and use that instead of
SymbolBody::getRVA in the inner relocation loop.
Now we get the symbol's chunk before switching over relocation types, so
we can test if it has been discarded outside the inner relocation type
switch. This also simplifies application of section relative
relocations. Previously we would switch on symbol kind to compute the
RVA, then the relocation type, and then the symbol kind again to get the
output section so we could subtract that from the symbol RVA. Now we
*always* have an OutputSection, so applying SECREL and SECTION
relocations isn't as much of a special case.
I'm still not quite happy with the cleanliness of this code. I'm not
sure what offsets and bases we should be using during the relocation
processing loop: VA, RVA, or OutputSectionOffset.
Reviewers: ruiu, pcc
Reviewed By: ruiu
Subscribers: majnemer, inglorion, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34650
llvm-svn: 306566
2017-06-29 01:06:35 +08:00
|
|
|
inline Chunk *Defined::getChunk() {
|
|
|
|
switch (kind()) {
|
|
|
|
case DefinedRegularKind:
|
|
|
|
return cast<DefinedRegular>(this)->getChunk();
|
|
|
|
case DefinedAbsoluteKind:
|
|
|
|
return nullptr;
|
|
|
|
case DefinedSyntheticKind:
|
|
|
|
return cast<DefinedSynthetic>(this)->getChunk();
|
|
|
|
case DefinedImportDataKind:
|
|
|
|
return cast<DefinedImportData>(this)->getChunk();
|
|
|
|
case DefinedImportThunkKind:
|
|
|
|
return cast<DefinedImportThunk>(this)->getChunk();
|
|
|
|
case DefinedLocalImportKind:
|
|
|
|
return cast<DefinedLocalImport>(this)->getChunk();
|
|
|
|
case DefinedCommonKind:
|
|
|
|
return cast<DefinedCommon>(this)->getChunk();
|
2019-09-04 04:32:16 +08:00
|
|
|
case LazyArchiveKind:
|
|
|
|
case LazyObjectKind:
|
[LLD] [COFF] Support linking directly against DLLs in MinGW mode
GNU ld.bfd supports linking directly against DLLs without using an
import library, and some projects have picked up on this habit.
(There's no one single unsurmountable issue with using import
libraries, but this is a regularly surfacing missing feature.)
As long as one is linking by name (instead of by ordinal), the DLL
export table contains most of the information needed. (One can
inspect what section a symbol points at, to see if it's a function
or data symbol. The practical implementation of this loops over all
sections for each symbol, but as long as they're not very many, that
should hopefully be tolerable performance wise.)
One exception where the information in the DLL isn't entirely enough
is on i386 with stdcall functions; depending on how they're done,
the exported function name can be a plain undecorated name, while
the import library would contain the full decorated symbol name. This
issue is addressed separately in a different patch.
This is implemented mimicing the structure of a regular import library,
with one InputFile corresponding to the static archive that just adds
lazy symbols, which then are fetched when they are needed. When such
a symbol is fetched, we synthesize a coff_import_header structure
in memory and create a regular ImportFile out of it.
The implementation could be even smaller by just creating ImportFiles
for every symbol available immediately, but that would have the
drawback of actually ending up importing all symbols unless running
with GC enabled (and mingw mode defaults to having it disabled for
historical reasons).
Differential Revision: https://reviews.llvm.org/D104530
2021-06-16 21:59:46 +08:00
|
|
|
case LazyDLLSymbolKind:
|
[COFF] Allow debug info to relocate against discarded symbols
Summary:
In order to do this without switching on the symbol kind multiple times,
I created Defined::getChunkAndOffset and use that instead of
SymbolBody::getRVA in the inner relocation loop.
Now we get the symbol's chunk before switching over relocation types, so
we can test if it has been discarded outside the inner relocation type
switch. This also simplifies application of section relative
relocations. Previously we would switch on symbol kind to compute the
RVA, then the relocation type, and then the symbol kind again to get the
output section so we could subtract that from the symbol RVA. Now we
*always* have an OutputSection, so applying SECREL and SECTION
relocations isn't as much of a special case.
I'm still not quite happy with the cleanliness of this code. I'm not
sure what offsets and bases we should be using during the relocation
processing loop: VA, RVA, or OutputSectionOffset.
Reviewers: ruiu, pcc
Reviewed By: ruiu
Subscribers: majnemer, inglorion, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D34650
llvm-svn: 306566
2017-06-29 01:06:35 +08:00
|
|
|
case UndefinedKind:
|
|
|
|
llvm_unreachable("Cannot get the chunk of an undefined symbol.");
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown symbol kind");
|
|
|
|
}
|
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
// A buffer class that is large enough to hold any Symbol-derived
|
2017-11-01 00:10:24 +08:00
|
|
|
// object. We allocate memory using this class and instantiate a symbol
|
|
|
|
// using the placement new.
|
|
|
|
union SymbolUnion {
|
2017-11-01 01:07:47 +08:00
|
|
|
alignas(DefinedRegular) char a[sizeof(DefinedRegular)];
|
|
|
|
alignas(DefinedCommon) char b[sizeof(DefinedCommon)];
|
|
|
|
alignas(DefinedAbsolute) char c[sizeof(DefinedAbsolute)];
|
|
|
|
alignas(DefinedSynthetic) char d[sizeof(DefinedSynthetic)];
|
2019-09-04 04:32:16 +08:00
|
|
|
alignas(LazyArchive) char e[sizeof(LazyArchive)];
|
2017-11-01 01:07:47 +08:00
|
|
|
alignas(Undefined) char f[sizeof(Undefined)];
|
|
|
|
alignas(DefinedImportData) char g[sizeof(DefinedImportData)];
|
|
|
|
alignas(DefinedImportThunk) char h[sizeof(DefinedImportThunk)];
|
|
|
|
alignas(DefinedLocalImport) char i[sizeof(DefinedLocalImport)];
|
2019-09-04 04:32:16 +08:00
|
|
|
alignas(LazyObject) char j[sizeof(LazyObject)];
|
[LLD] [COFF] Support linking directly against DLLs in MinGW mode
GNU ld.bfd supports linking directly against DLLs without using an
import library, and some projects have picked up on this habit.
(There's no one single unsurmountable issue with using import
libraries, but this is a regularly surfacing missing feature.)
As long as one is linking by name (instead of by ordinal), the DLL
export table contains most of the information needed. (One can
inspect what section a symbol points at, to see if it's a function
or data symbol. The practical implementation of this loops over all
sections for each symbol, but as long as they're not very many, that
should hopefully be tolerable performance wise.)
One exception where the information in the DLL isn't entirely enough
is on i386 with stdcall functions; depending on how they're done,
the exported function name can be a plain undecorated name, while
the import library would contain the full decorated symbol name. This
issue is addressed separately in a different patch.
This is implemented mimicing the structure of a regular import library,
with one InputFile corresponding to the static archive that just adds
lazy symbols, which then are fetched when they are needed. When such
a symbol is fetched, we synthesize a coff_import_header structure
in memory and create a regular ImportFile out of it.
The implementation could be even smaller by just creating ImportFiles
for every symbol available immediately, but that would have the
drawback of actually ending up importing all symbols unless running
with GC enabled (and mingw mode defaults to having it disabled for
historical reasons).
Differential Revision: https://reviews.llvm.org/D104530
2021-06-16 21:59:46 +08:00
|
|
|
alignas(LazyDLLSymbol) char k[sizeof(LazyDLLSymbol)];
|
2016-12-10 05:55:24 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
template <typename T, typename... ArgT>
|
2017-11-04 06:48:47 +08:00
|
|
|
void replaceSymbol(Symbol *s, ArgT &&... arg) {
|
2018-02-14 01:32:31 +08:00
|
|
|
static_assert(std::is_trivially_destructible<T>(),
|
|
|
|
"Symbol types must be trivially destructible");
|
2017-11-01 00:10:24 +08:00
|
|
|
static_assert(sizeof(T) <= sizeof(SymbolUnion), "Symbol too small");
|
|
|
|
static_assert(alignof(T) <= alignof(SymbolUnion),
|
|
|
|
"SymbolUnion not aligned enough");
|
2018-02-15 06:43:43 +08:00
|
|
|
assert(static_cast<Symbol *>(static_cast<T *>(nullptr)) == nullptr &&
|
|
|
|
"Not a Symbol");
|
2020-10-06 18:54:49 +08:00
|
|
|
bool canInline = s->canInline;
|
2017-11-01 00:10:24 +08:00
|
|
|
new (s) T(std::forward<ArgT>(arg)...);
|
2020-10-06 18:54:49 +08:00
|
|
|
s->canInline = canInline;
|
2016-12-10 05:55:24 +08:00
|
|
|
}
|
2015-05-29 03:09:30 +08:00
|
|
|
} // namespace coff
|
2017-01-06 18:04:08 +08:00
|
|
|
|
2015-05-29 03:09:30 +08:00
|
|
|
} // namespace lld
|
|
|
|
|
|
|
|
#endif
|