llvm-svn: 195854

llvm-svn: 195853

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

llvm-svn: 195801

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

This reverts accidental commit r195794.

llvm-svn: 195795

llvm-svn: 195794

The current mapping for /section one character options is really bogus.
Map to the correct flags.

llvm-svn: 195774

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

In order not to overrun a StringRef and copy the trailing garbage, we need to
set the maximum length to be copied by strncpy.

llvm-svn: 195688

llvm-svn: 195663

llvm-svn: 195662

llvm-svn: 195661

llvm-svn: 195618

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

Comment from Rui Ueyema.

llvm-svn: 195598

llvm-svn: 195597

This is needed before any of the search paths are searched for.

llvm-svn: 195596

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

llvm-svn: 195593

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

llvm-svn: 195584

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

No change in functionality.

llvm-svn: 195582

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 is the first step towards DLL creation support. Resource-only DLLs
don't have entry point address.

llvm-svn: 195510

llvm-svn: 195393

llvm-svn: 195389

llvm-svn: 195388

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

llvm-svn: 195289

llvm-svn: 195284

llvm-svn: 195282

llvm-svn: 195281

llvm-svn: 195279

So that the LLD won't print error message saying that it couldn't find
/implib or /safeseh files.

llvm-svn: 195276

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