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

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

llvm-svn: 195169

This should improve code readability as the class definitions are now
more readable than before.

llvm-svn: 195159

No need to do that in ReaderCOFF.cpp.

llvm-svn: 195109

llvm-svn: 195108

llvm-svn: 195107

llvm-svn: 195106

llvm-svn: 195105

llvm-svn: 195096

llvm-svn: 195062

llvm-svn: 195051

llvm-svn: 194988

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

llvm-svn: 194982

No functionality change.

llvm-svn: 194914

llvm-svn: 194913

llvm-svn: 194911

llvm-svn: 194909

llvm-svn: 194908

end() was evaluated every time through a loop. This patch eliminates it.

llvm-svn: 194894

llvm-svn: 194890

llvm-svn: 194887

llvm-svn: 194877

llvm-svn: 194866

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

llvm-svn: 194851

llvm-svn: 194847

llvm-svn: 194793

llvm-svn: 194791

Also slightly reduces PECOFFLinkingContext's memory footprint (~128B).

llvm-svn: 194787

llvm-svn: 194784

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

llvm-svn: 194776