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

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

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

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

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

llvm-svn: 307750

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

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

llvm-svn: 307590

In preparation for the addition of rangeThunks() calculate the addresses
of all the inputSections so that ThunkSections can be inserted at the right
place.

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

llvm-svn: 307373

This is relative to PR33173,

Previously if something wrong happened on DWARF parsers side during parsing
object for building gdb index (like was in PR: unsupported relocation) 
then LLD continued and finished the link. DWARF parsers sure showed error
message on their side, but that is all.

Patch changes behavior to fail the link in this case and show more
detailed message.

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

llvm-svn: 307370

The assignAddresses() function accumulates state in the LinkerScript that
prevents it from being called multiple times. This change moves the state
into a separate structure AddressState that is created at the start of the
function and disposed of at the end.

CurAddressState is used rather than passing a reference to the state as a
parameter to the functions used by assignAddresses(). This is because the
getSymbolValue function needs to be executed in the context of AddressState
but it is stored in ScriptParser when AddressState is not available.

The AddressState is also used in a limited context by processCommands()

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

llvm-svn: 307367

This fixes last testcase provided in PR28414.
In short issue is next: when we had X@@Version symbol in object A,
we did not resolve it to X early. Then when in another object B
we had reference to undefined X, symbol X from archive was fetched.
Since both archive and object A contains another symbol Z, duplicate
symbol definition was triggered as a result.

Correct behavior is to use X@@Version from object A instead and do not fetch
any symbols from archive.

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

llvm-svn: 307364

llvm-svn: 307279

It is now just after the OutputSections are created, which is as early
as it can possibly go.

llvm-svn: 307225

llvm-svn: 307220

This avoids having to compute relocation section sizes early, removing
the last use of assignOffsets.

llvm-svn: 307219

llvm-svn: 307217

llvm-svn: 307214

llvm-svn: 307211

llvm-svn: 307209

This is a bit simpler and avoids a walk over OutputSections.

llvm-svn: 307178

llvm-svn: 307167

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

llvm-svn: 307162

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