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

llvm-svn: 194768

llvm-svn: 194757

llvm-svn: 194754

llvm-svn: 194746

Writing arguments after the redirection of input ("< somefile") seems a bit
strange. Changes the order.

llvm-svn: 194727

llvm-svn: 194723

llvm-svn: 194722

llvm-svn: 194721

llvm-svn: 194677

llvm-svn: 194675

llvm-svn: 194671

llvm-svn: 194668

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

llvm-svn: 194643

This dependency needs to be cleaned up at some point. .directve handling needs the link.exe option parser.

llvm-svn: 194642

llvm-svn: 194641

llvm-svn: 194624

llvm-svn: 194620

llvm-svn: 194619

No functionality change.

llvm-svn: 194560

llvm-svn: 194556

This reverts commit r194551 because it broke the buildbot.

llvm-svn: 194552

llvm-svn: 194551

llvm-svn: 194550

llvm-svn: 194545

llvm-svn: 194539

llvm-svn: 194492

llvm-svn: 194481

llvm-svn: 194364

no functionality change.

llvm-svn: 194360

llvm-svn: 194359

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

llvm-svn: 194322

llvm-svn: 194305

llvm-svn: 194299

llvm-svn: 194292

llvm-svn: 194290

llvm-svn: 194280