Refactor the parser so that the parser can return arbitrary type of parse
result other than a vector of ExportDesc. Parsers for non-EXPORTS directives
will be implemented in different patches. No functionality change.
llvm-svn: 198993
The main goal of this patch is to allow "mach-o encoded as yaml" and "native
encoded as yaml" documents to be intermixed. They are distinguished via
yaml tags at the start of the document. This will enable all mach-o test cases
to be written using yaml instead of checking in object files.
The Registry was extend to allow yaml tag handlers to be registered. The
mach-o Reader adds a yaml tag handler for the tag "!mach-o".
Additionally, this patch fixes some buffer ownership issues. When parsing
mach-o binaries, the mach-o atoms can have pointers back into the memory
mapped .o file. But with yaml encoded mach-o, name and content are ephemeral,
so a copyRefs parameter was added to cause the mach-o atoms to make their
own copy.
llvm-svn: 198986
Module-definition (.def) files are the file containing linker directives,
such as export symbols. Because link.exe supports the same features as command
line options, just as some Linker Script commands overlaps with command line
options, use of module-definition file is not really necessary. It provides
an alternative way to specify some linker options.
This patch implements EXPORTS directive. Other directives will be implemented
in the future.
llvm-svn: 198925
Currently LLD always print a warning message if the same symbol is specified
more than once for /export option. It's a bit annoying because specifying the
same symbol with compatible options is actually safe and considered as a
normal use case. This patch makes LLD to warn only when incompatible export
options are given.
llvm-svn: 198104
Each export symbol descriptor has unique name attribute, so std::set is
better container than std::vector for it. No functionality change.
llvm-svn: 198102
I'm not 100% sure but it looks like DLL entry symbol (DLL initializer function
name) should be _DllMainCRTStartup@12. The reason why I'm not very sure is
because I have no idea what "@12" suffix is, but without it the symbol won't
be resolved...
llvm-svn: 198072
Currently .drectve section contents are parsed after other sections are parsed.
That order may result in wrong results if other sections depend on command line
options in the directive section.
For example, if a weak symbol is defined using /alternatename option in the
directive section, we have to read it first and then read the text section
contents. Otherwise the weak symbol won't be defined.
This patch changes the order to fix the issue.
llvm-svn: 198071
There are many object files in the standard library who have empty .drective
sections. Parsing the empty string is not wrong but a waste.
llvm-svn: 198067
There was a bug that the linker does not report an error if symbols specified
by -u (or /include on Windows) are not resolved. This patch fixes it by adding
such symbols to the dead strip root.
llvm-svn: 198041
Command line argument separator on Windows is colon. We used to accept space
as a separator, but we removed most of the code for that. This patch is to
delete the remaining code.
llvm-svn: 198032
Subsystem field in the PE/COFF file header has no meanining for the DLL.
It looks like MSVC link.exe sets the default subsystem (Windows GUI) to
the field if no /subsystem option is specified.
llvm-svn: 198015
It will configure resonable defaults for other settings in the
MachOLinkingContext object based on the parameters.
Patch by Joe Ranieri
llvm-svn: 197851
If a symbol in an import library is marked as "data", the linker will not
create a jump table entry for the symbol, since jump table makes sense only
for a symbol pointing to a function.
I don't think NONAME attribute has a meaning when creating an import library.
The attribute is emitted for debugging purpose.
llvm-svn: 197803
If the linker is instructed to create a DLL, it will also create an import
library (.lib file) to describe the symbols exported by the DLL. This patch is
to create the import library file.
There is a convenient command "lib.exe" which can create an import library
from a module definition file (.def file). The command is used in this patch.
llvm-svn: 197801
Default ordinals were assigned in EdataPass, and the assigned values were
then discarded in the pass. No code other than EdataPass would not be able
to get all of the information about ordinals. That's not ideal since I'm
writing code to emit an Import Library file, which also needs ordinals.
This is a patch to move the code to assign default ordinals from EdataPass
to LinkingContext::verify(), so that assigned ordinals will be available
anywhere.
No functionality change.
llvm-svn: 197797
The main changes are in:
include/lld/Core/Reference.h
include/lld/ReaderWriter/Reader.h
Everything else is details to support the main change.
1) Registration based Readers
Previously, lld had a tangled interdependency with all the Readers. It would
have been impossible to make a streamlined linker (say for a JIT) which
just supported one file format and one architecture (no yaml, no archives, etc).
The old model also required a LinkingContext to read an object file, which
would have made .o inspection tools awkward.
The new model is that there is a global Registry object. You programmatically
register the Readers you want with the registry object. Whenever you need to
read/parse a file, you ask the registry to do it, and the registry tries each
registered reader.
For ease of use with the existing lld code base, there is one Registry
object inside the LinkingContext object.
2) Changing kind value to be a tuple
Beside Readers, the registry also keeps track of the mapping for Reference
Kind values to and from strings. Along with that, this patch also fixes
an ambiguity with the previous Reference::Kind values. The problem was that
we wanted to reuse existing relocation type values as Reference::Kind values.
But then how can the YAML write know how to convert a value to a string? The
fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace
(e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and
a 16-bit value. This tuple system allows conversion to and from strings with
no ambiguities.
llvm-svn: 197727
Executable files do not use a string table, so section names longer than 8
characters are not permitted. Long section names should just be truncated.
llvm-svn: 197470
If NONAME option is given for an export, that symbol will be exported only by
its ordinal. LLD will not emit the symbol name to the export table.
llvm-svn: 197371
OrdinalBase is an addend to the ordinals. We used to always set 1 to the field.
Although it produced a valid a DLL export table, it'd be a waste if the first
ordinal does not start with 1 -- we had to have NULL fields at the beginning of
the export address table. By setting the ordinal base, we can eliminate the
NULL fields.
llvm-svn: 197367
You can specify exported function's ordinal by /export:func,@<number> command
line option, but LLD ignored the option until now. This patch implements the
feature.
Ordinal is basically the index into the exported function address table. So,
for example, if /export:foo,@42 is specified, the linker writes foo's address
to 42th entry in the address table. Windows supports import-by-ordinal; you
can not only import a function by name, but by its ordinal. If you want to
allow your DLL users to import your functions by their ordinals, you need to
make sure that your functions are always exported with the same ordinals.
This is the feature for that situation.
llvm-svn: 197364
The following are the most significant peculiarities of MIPS target:
- MIPS ABI requires some special tags in the dynamic table.
- GOT consists of two parts local and global. The local part contains
entries refer locally visible symbols. The global part contains entries
refer global symbols.
- Entries in the .dynsym section which have corresponded entries in the
GOT should be:
* Emitted at the end of .dynsym section
* Sorted accordingly to theirs GOT counterparts
- There are "paired" relocations. One or more R_MIPS_HI16 and R_MIPS_GOT16
relocations should be followed by R_MIPS_LO16 relocation. To calculate
result of R_MIPS_HI16 and R_MIPS_GOT16 relocations we need to combine
addends from these relocations and paired R_MIPS_LO16 relocation.
The patch reviewed by Michael Spencer, Shankar Easwaran, Rui Ueyama.
http://llvm-reviews.chandlerc.com/D2156
llvm-svn: 197342
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
Joey Gouly