method to get a SymbolBody and into the callers, and kill now dead
includes.

This removes the need to have the SymbolBody definition when we're
defining the inline method and makes it a better inline method. That was
the only reason for a lot of header includes here. Removing these and
using forward declarations actually uncovers a bunch of cross-header
dependencies that I've fixed while I'm here, and will allow me to
introduce some *important* inline code into Chunks.h that requires the
definition of ObjectFile.

No functionality changed at this point.

Differential Revision: http://reviews.llvm.org/D10789

llvm-svn: 240982

Compilers recognize "main" function and don't mangle its name.
But if you use a different function as a user-defined entry name,
and if you didn't define that function with extern C, your entry
point function name is mangled. And the linker has to be able to
find that. This is relatively rare but can happen.

llvm-svn: 240953

llvm-svn: 240951

Most build system depends on existence or time stamp of a file.
This patch is to create an empty file for /pdb:<filename> option
just to satisfy some build rules.

llvm-svn: 240948

Mangled dllexported symbols may be defined in a library.
If that's the case, we have to read a member file from the library.

llvm-svn: 240947

llvm-svn: 240940

The previous logic to find default entry name or subsystem does not
seem correct (i.e. was not compatible with MSVC linker). Previously,
default entry name was inferred from CRT functions and user-defined
entry functions. Subsystem was inferred from CRT functions.

Default entry name and subsystem are now inferred based on the
following table. Note that we no longer use CRT functions to infer
them.

               Entry name           Subsystem
  main         mainCRTStartup       console
  wmain        wmainCRTStartup      console
  WinMain      WinMainCRTStartup    windows
  wWinMain     wWinMainCRTStartup   windows

llvm-svn: 240922

Usually dllexported symbols are defined with 'extern "C"',
so identifying them is easy. We can just do hash table lookup
to look up exported symbols.

However, C++ non-member functions are also allowed to be exported,
and they can be specified with unmangled name. So, if /export:foo
is given, we need to look up not only "foo" but also its all
mangled names. In MSVC mangling scheme, that means that we need to
look up any symbol which starts with "?foo@@Y".

In this patch, we scan the entire symbol table to search for
a mangled symbol. The symbol table is a DenseMap, and that doesn't
support table lookup by string prefix. This is of course very
inefficient. But that should be probably OK because the user
should always add 'extern "C"' to dllexported symbols.

llvm-svn: 240919

This test was flaky because stdout and stderr can be mixed.

llvm-svn: 240918

llvm-svn: 240917

llvm-svn: 240916

This option is sometimes used to create a resource-only DLL that
doesn't need any initialization.

llvm-svn: 240915

llvm-svn: 240914

This option is to ignore remaining undefined symbols and force
the linker to create an output file anyways.

The existing code assumes that there's no undefined symbol after
reportRemainingUndefines(). That assumption is legitimate.
I also don't want to mess up the existing code for this minor feature.
In order to keep it as is, remaining undefined symbols are replaced
with dummy defined symbols.

llvm-svn: 240913

llvm-svn: 240901

If LINK is defined and not empty, it's supposed to contain
command line options.

llvm-svn: 240900

llvm-svn: 240899

llvm-svn: 240898

When comparing two COMDAT sections, we need to take section values
and associative sections into account. This patch fixes that bug.
It fixes a crash bug of llvm-tblgen when linked with /opt:lldicf.

One thing I don't understand yet is that this logic seems to be
too strict. MSVC linker is able to create more compact executables
(which of course work correctly). With this ICF algorithm, LLD is
able to make executable smaller, but the outputs are larger than
MSVC's. There must be something I'm missing here.

llvm-svn: 240897

This function is actually *very* hot. It is hard to see currently
because the call graph is very recursive, but I'm working to remove that
and when I do this function becomes significantly higher on the profile
(up to 5%!) and so worth avoiding the call overhead.

No specific perf gain I can measure yet (below the noise), but likely to
have more impact as we stop cluttering the call graph.

Differential Revision: http://reviews.llvm.org/D10788

llvm-svn: 240873

StringRefs. This uses the LLVM hashing rather than the standard library
and a closed addressed hash table rather than chaining.

This improves the Windows self-link of LLD by 4.4% (averaged over 10
runs, with well under 1% of variance on each).

There is still some room to improve here. Two things I clearly see in
the profile:

1) This is one of the biggest stress tests for the LLVM hashing code. It
   actually consumes something like 3-4% of the link time after the
   change.
2) The way that StringRef keys are handled in the DenseMap interface is
   pretty suboptimal. We pay the price of checking for empty and
   tombstone keys when we could only possibly be looking for a normal
   key. But fixing this requires invasive API changes.

So there is still some headroom here.

Differential Revision: http://reviews.llvm.org/D10684

llvm-svn: 240871

llvm-svn: 240862

llvm-svn: 240859

llvm-svn: 240846

Because the address table of the delay-import table contains
absolute address, it needs to be added to the base relocation
table.

llvm-svn: 240844

There were a few issues with the previous delay-import tables.

 - "Attribute" field should have been 1 instead of 0.
   (I don't know the meaning of this field, though.)
 - LEA and CALL operands had wrong addresses.
 - Address tables are in .didat (which is read-only).
   They should have been in .data.

llvm-svn: 240837

llvm-svn: 240818

This flag can be used to produce a map file, which is essentially a list
of objects linked into the final output file together with the RVAs of
their symbols. Because our format differs from MSVC's we expose it as a
separate flag.

Differential Revision: http://reviews.llvm.org/D10773

llvm-svn: 240812

llvm-svn: 240806

llvm-svn: 240802

llvm-svn: 240781

llvm-svn: 240765

That allows to remove duplicated long switch/case statements.

No functional changes.

llvm-svn: 240764

llvm-svn: 240763

llvm-svn: 240759

llvm-svn: 240758

We were resolving entry symbols and /include'd symbols after all other
symbols are resolved. But looks like it's too late. I found that it
causes some program to fail to link.

Let's say we have an object file A which defines symbols X and Y in an
archive. We also have another file B after A which defines X, Y and
_DLLMainCRTStartup in another archive. They conflict each other, so
either A or B can be linked.

If we have _DLLMainCRTStartup as an undefined symbol, file B is always
chosen. If not, there's a chance that A is chosen. If the linker
find it needs _DllMainCRTStartup after that, it's too late.

This patch adds undefined symbols to the symbol table as soon as
possible to fix the issue.

llvm-svn: 240757

Absolute symbols were always handled as external symbols, so if two
or more object files define the same absolute symbol, they would
conflict even if the symbol is private to each file.
This patch fixes that bug.

llvm-svn: 240756

Currently the new LLD supports only x86-64.

llvm-svn: 240749

llvm-svn: 240732