Attempt to fix Windows buildbots From 307131 Replaced return {ET, false};
with return std::make_pair(ET, false);

llvm-svn: 307137

This change permits there to be more than one thunk to be associated with
a symbol. For interworking thunks we only require one thunk, but range
extension thunks may require more than one.

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

llvm-svn: 307136

On ARM the interworking thunks are only produced for branch instructions
that can't be changed into a blx instruction so only Thumb callers would
call Thumb thunks and only ARM callers would call ARM thunks. With range
extension thunks branch and link instructions may need a Thunk. These
instructions can be rewritten as a blx and can use either ARM or Thumb
thunks.

We introduce an isCompatibleWith() function so that a caller can check if
an existing Thunk is compatible before reusing it.

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

llvm-svn: 307132

The allocateHeaders() function is called at the end of assignAddresses(), it
decides whether the ELF header and program header table can be allocated to
a PT_LOAD program header. As the function alters state, it prevents
assignAddresses() from being called multiple times.

This change splits out the call to allocateHeaders() from assignAddresses()
this will permit assignAddresses() to be called while processing range
extension thunks without trying to allocateHeaders().

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

llvm-svn: 307131

This is a semantic revert of r306036.

We have to change the names, otherwise dynamic relocations will point
to the wrong name.

llvm-svn: 307110

This is finally getting to the point where output sections are
constructed.

createOrphanCommands and fabricateDefaultCommands are moved out so
they can be merged with existing code in followup commits.

llvm-svn: 307107

Now addSectionSymbols operates on the linker script.

llvm-svn: 307102

Now all of finalizeSections works on the linker script.

llvm-svn: 307101

Now addPredefinedSections operates only on the linker script.

llvm-svn: 307100

Summary:
If the output file is a character file (e.g. /dev/null) unlinking it could
potentially destabilize the user's system.  For example,
unlinking causes `lld %input -o /dev/null` to replace /dev/null with a
regular file, which will lead to unexpected behavior in other programs
that read from /dev/null, and worse than expected peformance for
programs that write to /dev/null.

This makes it possible to run the test-release.sh script as root.
Prior to this patch, the ELF/basic.s test would replace
/dev/null with a regular file, which would cause crashes in llvm
test-suite programs that piped /dev/null to stdin.

For example, if you run the test-relase.sh script as root,

Reviewers: ruiu

Reviewed By: ruiu

Subscribers: emaste, llvm-commits

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

llvm-svn: 307092

Before we would sometimes not mention that the relocation was in a ro
area before.

llvm-svn: 307089

llvm-svn: 307083

We now don't produce "has undefined version" errors when producing
binaries even when there is a linker script.

llvm-svn: 307082

This is PR28414. 
Previously LLD was unable to link following:
(failed with undefined symbol bar)

Version script:
SOME_VERSION { global: *; };

.global _start
.global bar
.symver _start, bar@@SOME_VERSION
_start:
  jmp bar
Manual has next description:

.symver name, name2@@nodename
In this case, the symbol name must exist and be defined within the file being assembled. It is similar to name2@nodename. 
The difference is name2@@nodename will also be used to resolve references to name2 by the linker
https://sourceware.org/binutils/docs/as/Symver.html

Patch implements that. If we have name@@ver symbol and name is undefined, name@@ver is used to resolve references to name.
If name is defined then multiple definition error is emited, that is consistent with what bfd do.

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

llvm-svn: 307077

Two more places.

llvm-svn: 307076

llvm-svn: 307044

Now removeUnusedSyntheticSections operates entirely on the linker
script.

llvm-svn: 307043

llvm-svn: 307041

* Return type changed to void, because it was unused.
* std::find_if -> llvm::find_if

llvm-svn: 307039

Script commands are processed before unused synthetic sections are
removed. Therefore, if a linker script matches one of these sections
it'll get emitted as an empty output section because the logic for
removing unused synthetic sections ignores script commands which
could have already matched and captured one of these sections. This
patch fixes that by also removing the unused synthetic sections from
the script commands.

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

llvm-svn: 307037

Since yaml2obj is now able to parse integer values as relocation types,
there is no need to keep hex edited elf object for this test,
we can produce it on fly, just like this patch do.

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

llvm-svn: 307032

This patch makes changes to allow sections without the SHF_ALLOC bit to be
assigned to segments in a linker script.

The assignment of output sections to segments is performed in
LinkerScript::createPhdrs. Previously, this function would bail as soon as it
encountered an output section which did not have the SHF_ALLOC bit set, thus
preventing any output section without SHF_ALLOC from being assigned to a
segment.

This restriction has now been removed from LinkerScript::createPhdrs and instead
a check for SHF_ALLOC has been added to LinkerScript::adjustSectionsAfterSorting
to not propagate program headers to sections without SHF_ALLOC which matches the
behaviour of bfd linker scripts.

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

llvm-svn: 307013

This reverts commit r306813 because it broke linking of the
FreeBSD base system.

llvm-svn: 306996

A plain empty entry point function that returns 0 seems to produce
a binary that loads and runs fine in wine.

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

llvm-svn: 306963

Summary:
This reverts commit 51931072a7c9a52540baf76fc30ef391d2529a2f.

This revert was originally done because the integrations of the new
WindowsResource library into LLD was causing error in chromium, due to
bugs in how resource sections were handled.  These bugs were fixed,
meaning that the features may be reintegrated.

Subscribers: hiraditya, llvm-commits

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

llvm-svn: 306941

Type records have a unique type index, but symbol records do
not.  Instead, symbol records refer to other symbol records
by referencing their offset in the symbol stream.  In a sense
this is the analogue of the TypeIndex, but we are not printing
it in the dumper.  Printing it not only gives us more useful
information when manually investigating the contents of a PDB,
but also allows us to write better tests by enabling us to
verify that fields that reference other symbol records do
so correctly.

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

llvm-svn: 306890

This is a short-term fix for PR33650 aimed to get the modules build bots green again.

Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.

Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)

Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.

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

Corresponding LLVM change is r306878.

llvm-svn: 306880

Summary:
There have been bugs with the WindowsResource library, such as incorrect
symbols for addresses.  Directly checking the .rsrc in the final PE will
help ensure this doesn't happen again.

Subscribers: llvm-commits

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

llvm-svn: 306854

This is PR28414. 
Previously LLD was unable to link following:
(failed with undefined symbol bar)

```
Version script:
SOME_VERSION { global: *; };

.global _start
.global bar
.symver _start, bar@@SOME_VERSION
_start:
  jmp bar
```

Manual has next description:
//
.symver name, name2@@nodename
In this case, the symbol name must exist and be defined within the file being assembled. It is similar to name2@nodename. 
**The difference is name2@@nodename will also be used to resolve references to name2 by the linker**
https://sourceware.org/binutils/docs/as/Symver.html
//

Patch implements that. If we have name@@ver symbol and name is undefined, 
name@@ver is used to resolve references to name.

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

llvm-svn: 306813

llvm-svn: 306796

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

llvm-svn: 306772

llvm-svn: 306700

This reverts commit d4c7e9fc63c10dbab0c30186ef8575474a704496.

This is done in order to address the failure of CrWinClangLLD etc. bots.
These throw an error of "side-by-side configuration is incorrect" during
compilation, which sounds suspiciously related to these manifest
changes.

Revert "Switch external cvtres.exe for llvm's own resource library."

This reverts commit 71fe8ef283a9dab9a3f21432c98466cbc23990d1.

llvm-svn: 306618

Now that _GLOBAL_OFFSET_TABLE_ is defined, we can just use R_PC for it
if needed.

llvm-svn: 306614

llvm-svn: 306609

We could have add this function either Symbol or SymbolBody. I added it
to Symbol at first. But I noticed that if I've added it to SymbolBody,
we could've removed SymbolBody::setName(). So I'll do that in this patch.

llvm-svn: 306590

This patch adds a utility function to Symbol. This function should
be useful in https://reviews.llvm.org/D33680 too.

llvm-svn: 306587

Summary:
In order to do this without switching on the symbol kind multiple times,
I created Defined::getChunkAndOffset and use that instead of
SymbolBody::getRVA in the inner relocation loop.

Now we get the symbol's chunk before switching over relocation types, so
we can test if it has been discarded outside the inner relocation type
switch. This also simplifies application of section relative
relocations. Previously we would switch on symbol kind to compute the
RVA, then the relocation type, and then the symbol kind again to get the
output section so we could subtract that from the symbol RVA. Now we
*always* have an OutputSection, so applying SECREL and SECTION
relocations isn't as much of a special case.

I'm still not quite happy with the cleanliness of this code. I'm not
sure what offsets and bases we should be using during the relocation
processing loop: VA, RVA, or OutputSectionOffset.

Reviewers: ruiu, pcc

Reviewed By: ruiu

Subscribers: majnemer, inglorion, llvm-commits, aprantl

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

llvm-svn: 306566

Add support for the most common SPARC relocations.
Make DT_PLTGOT point to the PLT on SPARC.
Mark the PLT as executable on SPARC.

This adds a basic test that creates a SPARV9 executable
that invokes the exit system call on OpenBSD.

Patch by Mark Kettenis.

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

llvm-svn: 306565

This is PR33596. Previously LLD would crash
because BYTE command synthesized output section,
but it was not assigned to Sec member of OutputSectionCommand.

Behaviour of -script and -r combination is not well defined,
but it seems after this change LLD naturally inherits behavior of
GNU linkers - creates output section requested in script and does not
crash anymore.

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

llvm-svn: 306527