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

compile error.

llvm-svn: 197344

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

Symbol names exported from a DLL should be undecorated, not prefixed by
an underscore ones.

llvm-svn: 197307

llvm-svn: 197306

/EXPORT command line option can take an ordinal, NONAME flag, and DATA flag.
This patch is to parse these optional arguments.

llvm-svn: 197217

I should have run it before submitting but forgot to do that. Doing it now...

llvm-svn: 197214

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

We had lld::coff and lld::pecoff namespaces for no reason. Unify them.

llvm-svn: 197201

The file currently has only one function. Function that is useful both for
IdataPass and EdataPass will be added to that file.

llvm-svn: 197140

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

llvm-svn: 197039

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

Also removed unused field.

llvm-svn: 197027

No functionality change.

llvm-svn: 197025

Because sections no longer have trailing NULL bytes, size() and rawSize() now
return the same value.

llvm-svn: 197020

llvm-svn: 197019

llvm-svn: 197018

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

llvm-svn: 197009

llvm-svn: 197008

llvm-svn: 197007

llvm-svn: 197006

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

llvm-svn: 196994

The base class has a member function with the same name. We should avoid it
being shadowed.

llvm-svn: 196992

llvm-svn: 196991

llvm-svn: 196898

llvm-svn: 196897

llvm-svn: 196896

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

llvm-svn: 196891

... because they are used only in the function for relocations.

llvm-svn: 196890

llvm-svn: 196884

Use of static is recommended by the style guide.

llvm-svn: 196877

llvm-svn: 196867

These member functions are not overriden and not intended to be, so adding
virtual does not make sense.

llvm-svn: 196866