This code runs after clearOutputSections.

llvm-svn: 308066

llvm-svn: 308057

NFC, just makes the OutputSectionCommand available.

llvm-svn: 308056

llvm-svn: 308034

Previously we used precompiled objects in gdb-index.s and
debug-gnu-pubnames.s testcases. We can avoid that.

Differential revision: https://reviews.llvm.org/D35360

llvm-svn: 308005

In filling the .got sections, InputSection::OutSecOff was added twice
when finding the position to apply a relocation: first time in
InputSection::writeTo() and then in SectionBase::getOffset().

Differential revision: https://reviews.llvm.org/D34232

llvm-svn: 308003

The /appcontainer flag was added in r299728, and the lib.exe dependency
for creating import libraries was removed in r275242. Update the docs
accordingly.

The PDB support also needs updating, but I'll leave that for someone
who's more familiar with the current status (probably rnk).

llvm-svn: 307998

This was previously erroring out if one of the dead symbols was a
TLS symbol and we were able to discard all TLS sections.

Differential Revision: https://reviews.llvm.org/D35397

llvm-svn: 307984

PT_TLS is a type of program header, so we wouldn't expect to see
one in an object file. This error should probably be referring to
the fact that we didn't see a section with the flag SHF_TLS, which
would normally cause us to create a PT_TLS program header.

Differential Revision: https://reviews.llvm.org/D35395

llvm-svn: 307983

Summary:
We've accumulated about five or so data structures that are widely
referenced:
- PDBBuilder
- Type table
- Id table
- PDB string table
- Type server handler

I'm about to rewrite type server handling, and I need a new class in LLD
where I can put its state. By creating a new PDBLinker class, I hope to
put it there next.

Reviewers: ruiu

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D35392

llvm-svn: 307979

Functions declared in Strings.h should provide generic string operations
for the linker, but some of them are too specific to some features. This
patch moves them to the location where they are used.

llvm-svn: 307949

Summary:
This would have caught the invalid object file I used in my test case in
r307726. The OOB was only caught by ASan later, which is slow and
doesn't work on some platforms. LLD should do some basic input
validation itself. This check isn't perfect, so relocations can reach
OOB by up to seven bytes, but it's better than what we had and probably
cheap.

Reviewers: ruiu

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D35371

llvm-svn: 307948

Summary:
This fixes type indices for SDK or CRT static archives. Previously we'd
try to look next to the archive object file path, which would not exist
on the local machine.

Also error out if we can't resolve a type server record. Hypothetically
we can recover from this error by discarding debug info for this object,
but that is not yet implemented.

Reviewers: ruiu, amccarth

Subscribers: aprantl, hiraditya, llvm-commits

Differential Revision: https://reviews.llvm.org/D35369

llvm-svn: 307946

I have a patch to let DwarfContext defer to lld for getting section
contents and relocations.

That is a pretty big performance improvement.

This is just a refactoring to make that easier to do.

This change makes the *creation* of gdb index a dedicated step and
makes that templated. That is so that we can uses Elf_Rel in the code.

llvm-svn: 307867

This re-commits r307726 with valid line table relocations.

llvm-svn: 307829

llvm-svn: 307823

We were producing bogus warnings without it.

llvm-svn: 307820

Patch removes restriction about moving location counter
backwards outside of output sections declarations.

That may be useful for some apps relying on such scripts, 
known example is linux kernel.

Differential revision: https://reviews.llvm.org/D34977

llvm-svn: 307794

This fixes PR33712.

Imagine following script and code:

VER1 { global: foo; local: *; };
VER2 { global: foo; };

.global bar
bar:
.symver bar, foo@VER1

.global zed
zed:
.symver zed, foo@@VER2

We add foo@@VER2 as foo to symbol table, because have to resolve references to
foo for default symbols.
Later we are trying to assign symbol versions from script. For that we are searching for 'foo'
again. Here it is placed under VER1 and VER2 at the same time, we find it twice and trying to
set version again both times, hence LLD shows a warning.
Though sample code is correct: we have 2 different versions of foo.

Patch gives a symbol version extracted from name a priority over version set by script.

Differential revision: https://reviews.llvm.org/D35207

llvm-svn: 307792

When version script was used, binding opf undefined weak symbols sometimes
was calculated as STB_LOCAL, making them non-preemtible what
broke correct relocations handling logic for them.

Fixes PR33738.

Differential revision: https://reviews.llvm.org/D35263

llvm-svn: 307767

Revert "[PDB] Tweak bad type index error handling"

check-lld with asan detects use-after-poison.

This reverts commits r307733 and r307726.

llvm-svn: 307752

llvm-svn: 307750

llvm-svn: 307733

llvm-svn: 307728

Translate invalid type indices to a sentinel value instead of skipping
the record. Skipping records isn't a good recovery method, because we
can skip a scope open or close record, which will confuse the scope
management code.

We currently have lots of invalid type indices on Microsoft-provided
standard libraries, because the LF_TYPESERVER2 records contain absolute
paths that are only valid on their build servers. Our type server
handlers need to look at other things (GUIDs) to find these type server
PDBs.

llvm-svn: 307726

llvm-svn: 307703

Thanks to Rui for the suggestion.

llvm-svn: 307690

It was intially implemented in D19517 but then broken.
Patch fixes PR33707, testcase is based on PR's case.

Differential revision: https://reviews.llvm.org/D35119

llvm-svn: 307652

r307367 via D34345 split out the temporary address state used within
processCommands() and assignAddresses(). Due to the way that getSymbolValue
is used by the ScriptParser there is no way of giving the current
OutputSection to getSymbolValue() without somehow accessing the created
addressState. The suggestion was that by making a pointer that would go out
of scope we would find out by ASAN/MSAN or a crash if someone had misused
currentAddressState.

Differential Revision: https://reviews.llvm.org/D34345

llvm-svn: 307637

This is enough to link a working hello world executable, with
a call to an imported function, a string constant passed to
the imported function, and loads from a global variable.

Differential Revision: https://reviews.llvm.org/D34964

llvm-svn: 307629

This is part of the continuing effort to increase parity between
LLD and MSVC PDBs.  link still doesn't like our PDBs, so the most
obvious thing to check was whether adding an empty publics stream
would get it to do something else.  It still fails in the same way
but at least this removes one more variable from the equation.
The next logical step would be to try creating an empty globals
stream.

Differential Revision: https://reviews.llvm.org/D35224

llvm-svn: 307598

lld-link is apparently a symlink to lld.  Our pdb writing code
uses llvm::sys::fs::getMainExecutable() and writes that value
into the PDB, which will resolve symlinks etc.  But what we
really want is the exact value of argv[0], which matches what
the MS linker does.  Fix this by just writing argv[0] instead
of calling getMainExecutable.

llvm-svn: 307592

Differential Revision: https://reviews.llvm.org/D35152

llvm-svn: 307590

This was originally reverted because of two issues.
  1) Printing ANSI color escape codes even when outputting to
     a file
  2) Module name comparisons were failing when comparing a PDB
     generated on one machine to a PDB generated on another
     machine.

I attempted to fix #2 by adding command line options which let
you specify prefixes to strip from the beginning of embedded
paths, which effectively lets us specify a path to "base" each
PDB from and only compare the parts under the base.  But this is
tricky because PDB paths always use Windows path syntax, even
when they are created on non-Windows hosts.  A problem still
existed when constructing the prefix to strip, where we were
accidentally using a host-specific path separator instead of
a Windows path separator.

This resubmission fixes the issue on Linux (and I have verified
that the test now passes on Linux).

llvm-svn: 307571

This reverts commit 180af3fdbdb17ec35b45ec1f925fd743b28d37e1.

This is still breaking due to linux-specific path differences.

llvm-svn: 307559

A test was checked in on Friday that worked by checking in an
object file and PDB generated locally by MSVC, and then having
the test run lld-link on the object file and diffing LLD's PDB
against the checked in PDB.

This failed because part of the diffing algorithm involves
determining if two modules are the same, and if so drilling into
the module and diffing individual fields of the module.  The
only thing we can use to make this determination though is the
"name" of the module, which is a path to where the module (obj
file) was read from on the machine where it was linked.  This
fails for obvious reasons when comparing a PDB generated on one
machine to a PDB on another machine.

The fix employed here is to add two command line options to the
diff subcommand, which allow the user to specify a "binary root
path".  The bin root path, if specified, is stripped from the
beginning of any embedded PDB paths.  The test is updated to
specify the user's local test output directory for the left
PDB, and is hardcoded to the location where the original PDB
was created for the right PDB.  This way all the equivalence
comparisons should succeed.

llvm-svn: 307555

This reverts commit 147f45ff24456aea59575fa4ac16c8fa554df46a.

Revert "Revert "Revert "Revert "Replace trivial use of external rc.exe by writing our own .res file.""""

This reverts commit 61a90a67ed54a1f0dfeab457b65abffa129569e4.

The patches were intially reverted because they were causing a failure
on CrWinClangLLD.  Unfortunately, this was done haphazardly and didn't
compile, so the revert was reverted again quickly to fix this.  One that
was done, the revert of the revert was itself reverted.  This allowed me
to finally fix the actual bug in r307452.  This patch re-enables the
code path that had originally been causing the bug, now that it (should)
be fixed.

llvm-svn: 307460

This is failing on Linux for unknown reasons, so I need to
get the bots green while I investigate.

llvm-svn: 307459

Summary:
The original cvtres.exe sets the high bit when an identifier offset
points to a string.  Even though this is not mentioned in the spec, and
in fact does not seem to cause errors with most cases, for some reason
this causes a failure in Chromium where the new resource file is not
verified as a new version.  This patch sets this high bit flag, and also
adds a test case to check that the output of our library is always
identical to original cvtres.

Reviewers: zturner, ruiu

Subscribers: llvm-commits, hiraditya

Differential Revision: https://reviews.llvm.org/D35099

llvm-svn: 307452

1) Don't write a /src/headerblock stream.  This appears to be
   written conditionally by MSVC, but it's not clear what the
   condition is.  For now, just remove it since we dont' know
   what it is anyway and the particular pdb we've checked in
   for the test doesn't have one.
2) Write a valid timestamp for the PDB file signature.  This
   leads to non-reproducible builds, but it matches the default
   behavior of link, so it should be out default as well.  If
   we need reproducibility, we should add a separate command
   line option for it that is off by default.
3) Write an empty FPO stream.  MSVC seems to always write an
   FPO stream.  This change makes the stream directory match
   up, although we still need to make the contents of the FPO
   stream match.

llvm-svn: 307436