This change seems to make the linker about 10% faster.
Reading symbol name is not very cheap because it needs strlen()
on the string table. We were wasting time on reading non-external
symbol names that would never be used by the linker.

llvm-svn: 239332

MSVC profiler reported that this stable_sort takes 7% time
when self-linking. As a result, createSection was taking 10% time.
Now createSection takes 3%. This small change actually makes
the linker a bit but perceptibly faster.

llvm-svn: 239292

This is NFC but makes log message a bit nicer because it doesn't
append .\ (or ./ on Unix) to files in the current directory.

llvm-svn: 239290

llvm-svn: 239289

llvm-svn: 239288

We forgot to check for auxiliary symbol's type. So we sometimes read
garbage as associative section definitions.

Associative sections are considered as not live themselves by the
garbage collector because they are live only when associaited sections
are live.

By reading more data (or garbage) as associative section definitions,
we treated more sections as non-GC-roots, that caused the linker to
discard too many sections by mistake. That caused another mysterious
bug (such as some global constructors don't run at all for some reason.)

llvm-svn: 239287

Now that all InputFile subclasses have MemoryBufferRefs and
provides the same set of functions. Implement that in the base class.

llvm-svn: 239281

I don't know what the right thing to do here, but at least 1 does
not seem like a correct value. If we do not align common chunks at
all, a small program which calls puts() from global dtors crashes
mysteriously in a kernel32's function.

I believe the crash was caused by symbols overlapping each other,
and my guess is that alignment has something to do with that, but
I am not 100% sure. Needs investigating.

llvm-svn: 239280

llvm-svn: 239272

This change doesn't change its functionality since the value
passed here is converted to uint16_t immediately.

llvm-svn: 239271

llvm-svn: 239270

llvm-svn: 239269

llvm-svn: 239268

llvm-svn: 239267

/include'ed symbols are already added to Config->GCRoots.
Marking symbols twice doesn't have any effect.

llvm-svn: 239266

llvm-svn: 239244

This option disables dead-stripping.

llvm-svn: 239243

llvm-svn: 239242

llvm-svn: 239239

Default output filename is the same as the first object file's
name with its extension replaced with ".exe".

llvm-svn: 239238

llvm-svn: 239237

Chunk has writeTo function which takes uint8_t *Buf.
writeHeaderTo feels more consistent with that because this member
function also takes uint8_t *Buf.

llvm-svn: 239236

llvm-svn: 239235

llvm-svn: 239234

llvm-svn: 239233

llvm-svn: 239232

Previously, half of the constructor for .idata contents was in Chunks.cpp
and the rest was in Writer.cpp. This patch moves the latter to Chunks.cpp.
Now IdataContents class manages everything for .idata section.

llvm-svn: 239230

In this design, Chunk is the only thing that knows how to write
its contents to output file as well as how to apply relocations
there. The writer shouldn't know about the details.

llvm-svn: 239216

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

llvm-svn: 239212

llvm-svn: 239073

llvm-svn: 239072

Not only entry point symbol but also symbols specified by /include
option must be preserved, as they will never be dead-stripped.

http://reviews.llvm.org/D10220

llvm-svn: 239005

llvm-svn: 238937

This is mainly for readability. OutputSection objects are still owned
by the writer using SpecificBumpPtrAllocator.

llvm-svn: 238936

Avoid saying this is based on sections because it's not very accurate.
That we don't split section into smaller chunks of data does not mean
that the linker is built on top of that.
In reality, most part of the code do not care about underlying data,
so they are neither based on "atoms" nor sections.
The symbol table only cares about symbol names and their types.
The writer handles list of chunks, which look like just blobs,
and the writer doesn't care what those chunks are backed by.
The only thing that interact with sections is SectionChunk, which is
abstracted away as one type of Chunk.

llvm-svn: 238902

llvm-svn: 238901

llvm-svn: 238786

In r238690, I made all files have only MemoryBufferRefs. This change
is to do the same thing for the bitcode file reader. Also updated
a few variable names to match with other code.

llvm-svn: 238782

Symbols exported by DLLs can be imported not by name but by
small number or ordinal. Usually, symbols have both ordinals
and names, and in that case ordinals are called "hints" and
used by the loader as hints.

However, symbols can have only ordinals. They are called
import-by-ordinal symbols. You need to manage ordinals by hand
so that they will never change if you choose to use the feature.
But it's supposed to make dynamic linking faster because
it needs no string comparison. Not sure if that claim still
stands in year 2015, though. Anyways, the feature exists,
and this patch implements that.

llvm-svn: 238780

I'm adding ordinal-only (nameless) imports to the import table.
The chunk for that type is going to be different from LookupChunk.
Without this change, we cannot add objects of the new type to the
vectors.

llvm-svn: 238779