The only data in .edata whose length varies is the string. This patch moves
all the strings to the end of the section, so that 16-bit or 32-bit integers
are aligned on correct boundaries.
llvm-svn: 197213
This is the first patch to emit data for the DLL export table. The DLL export
table is the data used by the Windows loader to find the address of exported
function from DLL. With this patch, LLD is able to emit a valid DLL export
table which the Windows loader can interpret and load.
The data structure of the DLL export table is described in the Microsoft
PE/COFF Specification, section 5.3.
DLL support is not complete yet; the linker needs to emit an import library
for a DLL, otherwise the linker cannot link against the DLL. We also do not
support export-only-by-ordinal yet.
llvm-svn: 197212
DLLNameAtom is an atom whose content is a string. IdataAtom is not going to
be the only place we need such atom, so I want to generalize it.
llvm-svn: 197137
I'm planning to create a new pass for the DLL export table, and I want to use
the class both from IdataPass and the new pass, EdataPass. So move the class to
a common place.
llvm-svn: 197132
/DLLEXPORT is a command line option to export a symbol. __declspec(dllexport)
uses that to make the linker to export DLLExport'ed functions, by adding the
option to .drectve section.
This patch implements the parser of the command line option.
llvm-svn: 197122
Before this patch, we had the following class hierarchy.
Chunk -> AtomChunk -> SectionChunk -> GenericSectionChunk
-> BaseRelocChunk
-> HeaderChunk
Chunk represented the generic concept of contiguous range in an output
file. AtomChunk represented a chunk consists of atoms.
That class hierarchy had many issues: 1) BaseRelocChunk does not really
consist of atoms, so inheriting from AtomChunk was plainly wrong, and 2)
the hierarchy is unecessarily too deep.
This patch correct them. The new hierachy is shown below.
Chunk -> SectionChunk -> AtomChunk
-> BaseRelocChunk
-> HeaderChunk
In the new hierarchy, AtomChunk represents a chunk consists of atoms. Other
types of sections (currently only BaseRelocChunk) should inherit directly
from SectionChunk.
llvm-svn: 197038
This patch is to basically move the functionality to construct Data Directory
from IdataPass to WriterPECOFF.
Data Directory is a part of the PE/COFF header and contains the addresses of
the import tables.
We used to represent the link from Data Directory to the import tables as
relocation references. The idea behind it is that, because relocation
references are processed by the Writer, we wouldn't have to do anything special
to fill the addresses of the import tables. I thought that the addresses would
be set "automatically".
But it turned out that that design made the pass and the writer rather
complicated. In order to make relocation references between Data Directory to
the import tables, these data structures needed to be represented as Atom.
However, because Data Directory is not a section content but a part of the
PE/COFF header, it did not fit well as an Atom. So we ended up having
complicated code both in IdataPass and the writer.
This patch simplifies it.
One side effect of this patch is that we now have ".idata.a", ".idata.d" and
"idata.t" sections for the import address table, the import directory table,
and the import lookup table. The writer looks for the sections by name to find
the start addresses of the sections. We probably should have a better way to
find a specific atom from the core linking result, but currently using the
section name seems to be the easiest way to do that. The Windows loader do not
care about the import table's section layout.
llvm-svn: 197016
If section size is not multiple of 512, the writer added NULL bytes at the end
of it to make it so. That is not required by the PE/COFF spec, and the MSVC's
linker does not do that too. So we don't need to do that, too.
llvm-svn: 197002
Code to create COFF section header was scattered across many member functions
of SectionChunk. Consolidate it to a member function of SectionHeaderTableChunk.
llvm-svn: 196895
/ALTERNATENAME is a rarely-used, undocumented command line option that is
needed to link LLD for release build. It seems that the option is for defining
an weak alias; /alternatename:foo=bar defines weak symbol "foo" for "bar".
If "foo" is defined in an input file, it'll be linked normally and the command
line option will have no effect. If it's not defined, "foo" will be handled
as an alias for "bar".
This patch implements the parser for the option. The actual weak alias handling
will be implemented in a separate patch.
llvm-svn: 196743
Because compare() and its heper functions no longer have to be members of
LayoutPass class, we can remove it from the class. No functionality change.
llvm-svn: 196715
The comparator used in the layout pass has many calls of map::find(). Because
std::sort runs the comparator N*log2(N) times, the maps are looked up with the
same key again and again. The map lookup is not a very fast operation. It made
the pass slow.
This patch eliminates the duplicate map lookups using decorate-sort-undecorate
idiom. The pass used to take 1.1 seconds when linking LLD with LLD on Windows,
but it now takes only 0.3 seconds. Overall performance gain in that case is from
6.1 seconds to 5.2 seconds.
Differential Revision: http://llvm-reviews.chandlerc.com/D2358
llvm-svn: 196714
GroupedSectionsPass was a complicated pass. That pass's job was to reorder
atoms by section name, so that the atoms with the same section prefix will be
emitted consecutively to the executable. The pass added layout edges to atoms,
and let the layout pass to actually reorder them.
This patch simplifies the design by making GroupedSectionPass to directly
reorder atoms, rather than adding layout edges. This resembles ELF's
ArrayOrderPass.
This patch improves the performance of LLD; it used to take 7.1 seconds to
link LLD with LLD on my Macbook Pro, but it now takes 6.1 seconds.
llvm-svn: 196628
Currently we do not de-duplicate library files specified by /defaultlib option.
As a result, the same files are added multiple times to the input graph. In
particular, some popular files, such as kernel32.lib or oldnames.lib, are added
more than 10 times during linking of LLD. That makes the linker slower, as it
needs to parse the same file again and again.
This patch solves the issue by de-duplicating. The same file will be added only
once to the input graph. This patch improved the LLD linking time from 10.5
seconds to 7.7 seconds on my 4-core Core i7 Macbook Pro.
llvm-svn: 196504
Emitting idata atoms to their own section would make debugging easier.
The Windows loader do not really care about whether the DLL import table is
in .rdata or its own .idata section, so there is no change in functionality.
llvm-svn: 196458
If /functionpadmin is specified, the linker is supposed to make room at the
beginning of each function, so that self-modifying program would easily
hotpatch existing functions. Since I'm not sure if this feature is really used,
I'll make LLD to ignore the option for now.
llvm-svn: 196363
/DEBUG option is to make the linker to emit debug information to the resulting
executable. It's not for enable debugging of the linker itself.
llvm-svn: 196040
This is a patch to let the PECOFF writer to use the information passed
by the parser for /section option. The implementation of /section should
now be complete.
llvm-svn: 195893
/MERGE option is a bit complicated for many reasons. Firstly, it takes both
positive and negative arguments. That means we have to have one of three
distinctive values (set, clear or unchange) for each permission bit. In this
patch we represent the three values using two bitmasks.
Secondly, the permissions specified by the parameter is bitwise or-ed with the
default permissions of a section. There is an exception for that rule; if one
of READ, WRITE or EXECUTE bit is specified, unspecified bits need to be
cleared. (So if you specify only WRITE for example, the resulting section will
not have WRITE nor EXECUTE bits.)
Lastly, multiple /merge options are allowed.
llvm-svn: 195882
Atom ordinals are the indeces in a file. Currently the PECOFF reader assigns
ordinals for each section, so it's (incorrectly) assigning duplicate ordinals.
llvm-svn: 195852
Instead of having multiple SectionChunks for each section (.text, .data,
.rdata and .bss), we could have one chunk writer that can emit any sections.
This patch does that -- removing all section-sepcific chunk writers and
replace them with one "generic" writer.
This change should simplify the code because it eliminates similar-but-
slightly-different classes.
It also fixes an issue in the previous design. Before this patch, we could
emit only limited set of sections (i.e. .text, .data, .rdata and .bss). With
this patch, we can emit any sections.
llvm-svn: 195797
According to the PE/COFF spec, a section with IMAGE_SCN_LNK_INFO should only
appear in an object file, and not allowed in an executable. So I believe
treating it as the same way as IMAGE_SCN_LNK_INFO is the right thing.
llvm-svn: 195692
This patch won't change the output because the layout of linker internal
atoms is forced by layout-{before,after} references. Ordinals of the linker
internal atoms are not currently used. (That's why it's working even if there
are atoms having the same ordinals.)
llvm-svn: 195610
Change the attribute from sectionBasedOnContent to sectionCustomRequired
because its the right attribute for atoms read from COFF files to have.
COFF atoms should basically be emitted to the section having the same name
as input. Permissions/attributes should not affect that.
There's no functionality change because the writer doesn't yet use the
section name. The writer will be modified in a following patch, so that atoms
are written to its customSectionName()'s section.
llvm-svn: 195595
Looks like -L paths are not positional. They need to be added to a list of
search paths and those needs to be searched when lld looks for a library.
llvm-svn: 195594
If /subsystem option is not specified, the linker needs to infer it from the
entry point function. If "main" or "wmain" is defined, it's a console
application. If "WinMain" or "wWinMain" is defined, it's a GUI application.
llvm-svn: 195592
This adds LinkerScript support by creating a type Script which is of type
FileNode in the InputGraph. Once the LinkerScript Parser converts the
LinkerScript into a sequence of command, the commands are handled by the
equivalent LinkerScript node for the current Flavor/Target. For ELF, a
ELFGNULdScript gets created which converts the commands to ELF nodes and ELF
control nodes(ELFGroup for handling Group nodes).
Since the Inputfile type has to be determined in the Driver, the Driver needs
to determine the complete path of the file that needs to be processed by the
Linker. Due to this, few tests have been removed since the Driver uses paths
that doesnot exist.
llvm-svn: 195583
Hidden nodes could be a result of expansion, where a flavor might decide to keep
the node that we want to expand but discard it from being processed by the
resolver.
Verifies with unittests.
llvm-svn: 195516
Flavors may like to expand InputGraph nodes, when a filenode after parsing
results in more elements. One such example is while parsing GNU linker scripts.
The linker scripts after parsing would result in a lot of filenodes and probably
controlnodes too.
Adds unittests to verify functionality.
llvm-svn: 195515
This adds functionality to limit shared library undefined atoms to be added
only once by the Resolver.
Dynamic libraries may be processed more than once if they exist within a
Group.
Also adds a test to verify the change.
llvm-svn: 195307
It's allowed to specify library files *before* object files in the command
line. Object files seems to be processed first, and then their undefined
symbols are resolved from the libraries. This patch implements the compatible
behavior.
llvm-svn: 195295
NativeReferenceIvarsV1 cannot handle more than 65535 relocation targets
because its field to point to the target table is of type uint16_t. Because
of that limitation, the LLD couldn't link a file containing more than 65535
relocations. 65535 is not a big number - the LLD couldn't even link itself
with V1.
This patch solves the issue by adding NativeReferenceIvarsV2 support. The
new structure has more bits for the target table, so it can handle a large
number of relocatinos.
V2 structure is larger than V1. In order to prevent file bloating, V2 format
is used only when the resulting file cannot be represented in V1 format. The
writer and the reader support both V1 and V2 formats.
Differential Revision: http://llvm-reviews.chandlerc.com/D2217
llvm-svn: 195270
The fallback atom was used only when it's searching for a symbol in a library;
if an undefined symbol was not found in a library, the LLD looked for its
fallback symbol in the library.
Although it worked in most cases, because symbols with fallbacks usually occur
only in OLDNAMES.LIB (a standard library), that behavior was incompatible with
link.exe. This patch fixes the issue so that the semantics is the same as
MSVC's link.exe
The new (and correct, I believe) behavior is this:
- If there's no definition for an undefined atom, replace the undefined atom
with its fallback and then proceed (e.g. look in the next file or stop
linking as usual.)
Weak External symbols are underspecified in the Microsoft PE/COFF spec. However,
as long as I observed the behavior of link.exe, this seems to be what we want
for compatibility.
Differential Revision: http://llvm-reviews.chandlerc.com/D2162
llvm-svn: 195269
The maximum number of references the file with NativeReferenceIvarsV1 can
contain is 65534. If a file larger than that is converted to Native format,
the conversion will fail without any error message. This caused a subtle bug
that the LLD would produce a broken executable only when input files contain
too many references.
This issue exists since the RoundTripNativeTest is introduced in r193585. Since
then, it seems that nobody have linked any program having more than 65534
relocations with the LLD. Otherwise we would have found it earlier.
llvm-svn: 194987
This patch does not change the meaning of the program, but if something's wrong
in the linker or the compiler and the control reaches to the gap of imported
function table, it will stop immediately because of the presence of INT3. If
NOP, it'd fall through to the next call instruction, which is usually a
completely foreign function call.
llvm-svn: 194860
We can add multiple undefined atoms having the same name to the symbol table.
If such atoms are added, the symbol table compares their canBeNull attributes,
and select one having a stronger constraint. If their canBeNulls are the same,
the choice is arbitrary. Currently it choose the existing one.
This patch changes the preference, so that the symbol table choose the new one
if the new atom has a greater canBeNull or a fallback atom. This shouldn't
change the behavior except the case described below.
A new undefined atom may have a new fallback atom attribute. By choosing the new
atom, we can update the fallback atom during Core Linking. PE/COFF actually need
that. For example, _lseek is an alias for __lseek on Windows. One of an object
file in OLDNAMES.LIB has an undefined atom for _lseek with the fallback to
__lseek. When the linker tries to resolve _read, it supposed to read the file
from OLDNAMES.LIB and use the new fallback from the file. Currently LLD cannot
handle such case because duplicate undefined atoms with the same attributes are
ignored.
Differential Revision: http://llvm-reviews.chandlerc.com/D2161
llvm-svn: 194777
YAML files tend to be very large compared to binary formats because of ASCII
format inefficiency. And the YAML reader consumes an excessively large amount
of memory when parsing a large file. It's very slow too.
For example, I observed that 6MB executable became 120MB YAML file, and the
YAML reader consumed more than 1.5GB memory to load it. The YAML reader even
caused OOM error on 32 bit, causing the entire process to fail.
This patch sets the limit on the YAML file size the linker will try to load in
the RoundTripYAML test as a safeguard.
llvm-svn: 194666
The result of sizeof(SymbolTable<ELFT>::SymbolEntry) in DynamicSymbolTable
<ELFT>::write() was different from the same expression in RelocationTable
<ELFT>::write(), although the same template parameters were passed. They were
40 and 32, respectively. As a result, the same vector was treated as a
vector of 40 byte values in some places and a vector of 32 values in other
places. That caused an weird issue, resulting in collapse of the rela.dyn
section.
I suspect that this is a padding size calculation bug in MSVC 2012, but I
may be wrong. Reordering the fields to eliminate padding seems to fix the
issue.
llvm-svn: 194349
This patch adds support for converting normalized mach-o to and from binary
mach-o. It also changes WriterMachO (which previously directly wrote a
mach-o binary given a set of Atoms) to instead do it in two steps. The first
step uses normalizedFromAtoms() to convert Atoms to normalized mach-o, and the
second step uses writeBinary() which to generate the mach-o binary file.
llvm-svn: 194167
These fields are for /align option. Section alignment can be set per-section
basis with /section option too. In order to avoid name conflicts, rename the
existing identifiers to become more specific. No functionality change.
llvm-svn: 194160
/section command line option is to set/reset attributes of the Characteristics
field in the section header. You can set non-default values with this option.
You can make .data section executable with this, for example.
This patch implements the parser of the command line option. The code to use
the parsed values will be committed in a separate patch.
llvm-svn: 194133
I'm not sure if it is really an alias for /nodefaultlib, but I can say that
they are at least similar. Making it an alias would be better than ignoring it.
llvm-svn: 194131
/defaultlib options can be specified implicitly via the .drectve section, and
it's pretty common that multiple object files add the same library, such as
user32.lib, to the input. We shouldn't add the same library multiple times.
llvm-svn: 194129
We wrapped the linker internal file with a virtual archive file, so that the
linker internal file was linked only when it's actually used. This was to avoid
__ImageBase being included to the resulting executable. __ImageBase used to
occupy four bytes when emitted to executable.
And then it turned out that the implementation of __ImageBase was wrong -- it
shouldn't have been a regular atom but an absolute atom. Absolute atoms point
to some memory location, but they don't occupy disk space themselves. So it
wouldn't increase executable size (except the symbol table.) That means that
it's OK to link the linker internal file unconditionally.
So this patch does that, removing the wrapper archive file. Doing this
simplifies the code.
llvm-svn: 194127
msvcrt.lib contains "/disallowlib" command line option in its .drectve section.
I couldn't spot any documentation for the option. Ignore it for now so that we
can link the library without error.
llvm-svn: 194114
n_desc field in MachO string table was not initialized. On Unix,
test/darwin/hello-world.objtxt did not fail because I think an nlist object
is always allocated to a fresh heap initialized with zeros. On Windows,
uninitialized fields are filled with 0xCC when compiled with /GZ. Because
of that the test was failing on Windows.
llvm-svn: 193909
Bugs that would be caught by this assertion would also be caught by
RoundTripYAMLPass test. We've enabled the pass for PECOFF, so we can remove
this.
llvm-svn: 193886
The data directory in the PE/COFF header consisted of list of data directory
atoms. This patch changes it -- now there's only one data directory entry that
contains former data directories. That's easier to handle in the writer as well
as to write to/read from YAML/Native files. The main purpose of this refactoring
is to enable RoundTrip tests for PE/COFF.
There's no functionality change.
llvm-svn: 193854
This reverts commit r193479.
The atoms are already added to the file, so re-adding them caused the YAML
writer to write the same atoms twice. That made the YAML reader to fail with
"duplicate atom name" error.
This is not the only error we've got for RoundTripYAMLPass for PECOFF, so we
cannot enable the test yet. More fixes will come.
Differential Revision: http://llvm-reviews.chandlerc.com/D2069
llvm-svn: 193762
Rui Ueyama