[ELF] Move InputFiles global variables (memoryBuffers, objectFiles, etc) into Ctx. NFC

lld/AMDGPU: Fix asserts if no object files are involved in link

Fixes issue 47690. The reproduction steps produced a shared object
from clang directly, and then fed the shared object back into
lld.

lld/AMDGPU: Fix asserts if no object files are involved in link

Fixes issue 47690. The reproduction steps produced a shared object
from clang directly, and then fed the shared object back into
lld. With no regular object files, this assert was hit. I'm not sure
if we need to or should be looking for equivalent fields in shared
objects.

show more ...

[AMDGPU][LLD] Adding support for ABI version 5 option

Code object version 5 will use the same EFlags as version 4, so we only need to add an additional case

Differential Revision: https://reviews.l

[AMDGPU][LLD] Adding support for ABI version 5 option

Code object version 5 will use the same EFlags as version 4, so we only need to add an additional case

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

show more ...

[ELF] Don't rely on Symbols.h's transitive inclusion of InputFiles.h. NFC

[ELF] Clean up headers. NFC

[ELF] Replace noneRel = R_*_NONE with static constexpr. NFC

All architectures define R_*_NONE to 0.

[lld][AMDGPU] Handle R_AMDGPU_REL16 relocation.

This patch is a followup patch to https://reviews.llvm.org/D105760 which adds this relocation. This handles the relocation in lld.

The s_branch famil

[lld][AMDGPU] Handle R_AMDGPU_REL16 relocation.

This patch is a followup patch to https://reviews.llvm.org/D105760 which adds this relocation. This handles the relocation in lld.

The s_branch family of instruction does the following:
PC = PC + signext(simm * 4) + 4

so we we do the opposite on the target address before writing it in the instruction stream.

Reviewed By: MaskRay

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

show more ...

AMDGPU/LLD: Add target id and code object v4 support to linker

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

[lib/Object] - Refine interface of ELFFile<ELFT>. NFCI.

`ELFFile<ELFT>` has many methods that take pointers,
though they assume that arguments are never null and
hence could take references instead.

[lib/Object] - Refine interface of ELFFile<ELFT>. NFCI.

`ELFFile<ELFT>` has many methods that take pointers,
though they assume that arguments are never null and
hence could take references instead.

This patch performs such clean-up.

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

show more ...

[ELF] Use namespace qualifiers (lld:: or elf::) instead of `namespace lld { namespace elf {`

Similar to D74882. This reverts much code from commit
bd8cfe65f5fee4ad573adc2172359c9552e8cdc0 (D68323) a

[ELF] Use namespace qualifiers (lld:: or elf::) instead of `namespace lld { namespace elf {`

Similar to D74882. This reverts much code from commit
bd8cfe65f5fee4ad573adc2172359c9552e8cdc0 (D68323) and fixes some
problems before D68323.

Sorry for the churn but D68323 was a mistake. Namespace qualifiers avoid
bugs where the definition does not match the declaration from the
header. See
https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-implement-previously-declared-functions (D74515)

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

show more ...

[ELF] Rename relocateOne() to relocate() and pass `Relocation` to it

Symbol information can be used to improve out-of-range/misalignment diagnostics.
It also helps R_ARM_CALL/R_ARM_THM_CALL which ha

[ELF] Rename relocateOne() to relocate() and pass `Relocation` to it

Symbol information can be used to improve out-of-range/misalignment diagnostics.
It also helps R_ARM_CALL/R_ARM_THM_CALL which has different behaviors with different symbol types.

There are many (67) relocateOne() call sites used in thunks, {Arm,AArch64}errata, PLT, etc.
Rename them to `relocateNoSym()` to be clearer that there is no symbol information.

Reviewed By: grimar, peter.smith

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

show more ...

[ELF] Wrap things in `namespace lld { namespace elf {`, NFC

This makes it clear `ELF/**/*.cpp` files define things in the `lld::elf`
namespace and simplifies `elf::foo` to `foo`.

Reviewed By: atana

[ELF] Wrap things in `namespace lld { namespace elf {`, NFC

This makes it clear `ELF/**/*.cpp` files define things in the `lld::elf`
namespace and simplifies `elf::foo` to `foo`.

Reviewed By: atanasyan, grimar, ruiu

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

llvm-svn: 373885

show more ...

[Coding style change] Rename variables so that they start with a lowercase letter

This patch is mechanically generated by clang-llvm-rename tool that I wrote
using Clang Refactoring Engine just for

[Coding style change] Rename variables so that they start with a lowercase letter

This patch is mechanically generated by clang-llvm-rename tool that I wrote
using Clang Refactoring Engine just for creating this patch. You can see the
source code of the tool at https://reviews.llvm.org/D64123. There's no manual
post-processing; you can generate the same patch by re-running the tool against
lld's code base.

Here is the main discussion thread to change the LLVM coding style:
https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html
In the discussion thread, I proposed we use lld as a testbed for variable
naming scheme change, and this patch does that.

I chose to rename variables so that they are in camelCase, just because that
is a minimal change to make variables to start with a lowercase letter.

Note to downstream patch maintainers: if you are maintaining a downstream lld
repo, just rebasing ahead of this commit would cause massive merge conflicts
because this patch essentially changes every line in the lld subdirectory. But
there's a remedy.

clang-llvm-rename tool is a batch tool, so you can rename variables in your
downstream repo with the tool. Given that, here is how to rebase your repo to
a commit after the mass renaming:

1. rebase to the commit just before the mass variable renaming,
2. apply the tool to your downstream repo to mass-rename variables locally, and
3. rebase again to the head.

Most changes made by the tool should be identical for a downstream repo and
for the head, so at the step 3, almost all changes should be merged and
disappear. I'd expect that there would be some lines that you need to merge by
hand, but that shouldn't be too many.

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

llvm-svn: 365595

show more ...

[ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for absolute relocation types in writable sections

Summary:
Our rule to create R_*_RELATIVE for absolute relocation types wer

[ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for absolute relocation types in writable sections

Summary:
Our rule to create R_*_RELATIVE for absolute relocation types were
loose. D63121 made it stricter but it failed to create R_*_RELATIVE for
R_ARM_TARGET1 and R_PPC64_TOC. rLLD363236 worked around that by
reinstating the original behavior for ARM and PPC64.

This patch is an attempt to simplify the logic.

Note, in ld.bfd, R_ARM_TARGET2 --target2=abs also creates
R_ARM_RELATIVE. This seems a very uncommon scenario (moreover,
--target2=got-rel is the default), so I do not implement any logic
related to it.

Also, delete R_AARCH64_ABS32 from AArch64::getDynRel. We don't have
working ILP32 support yet. Allowing it would create an incorrect
R_AARCH64_RELATIVE.

For MIPS, the (if SymbolRel, then RelativeRel) code is to keep its
behavior unchanged.

Note, in ppc64-abs64-dyn.s, R_PPC64_TOC gets an incorrect addend because
computeAddend() doesn't compute the correct address. We seem to have the
wrong behavior for a long time. The important thing seems that a dynamic
relocation R_PPC64_TOC should not be created as the dynamic loader will
error R_PPC64_TOC is not supported.

Reviewers: atanasyan, grimar, peter.smith, ruiu, sfertile, espindola

Reviewed By: ruiu

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

llvm-svn: 363928

show more ...

[ELF] Make the rule to create relative relocations in a writable section stricter

The current rule is loose: `!Sym.IsPreemptible || Expr == R_GOT`.

When the symbol is non-preemptable, this allows a

[ELF] Make the rule to create relative relocations in a writable section stricter

The current rule is loose: `!Sym.IsPreemptible || Expr == R_GOT`.

When the symbol is non-preemptable, this allows absolute relocation
types with smaller numbers of bits, e.g. R_X86_64_{8,16,32}. They are
disallowed by ld.bfd and gold, e.g.

ld.bfd: a.o: relocation R_X86_64_8 against `.text' can not be used when making a shared object; recompile with -fPIC

This patch:

a) Add TargetInfo::SymbolicRel to represent relocation types that resolve to a
symbol value (e.g. R_AARCH_ABS64, R_386_32, R_X86_64_64).

As a side benefit, we currently (ab)use GotRel (R_*_GLOB_DAT) to resolve
GOT slots that are link-time constants. Since we now use Target->SymbolRel
to do the job, we can remove R_*_GLOB_DAT from relocateOne() for all targets.
R_*_GLOB_DAT cannot be used as static relocation types.
b) Change the condition to `!Sym.IsPreemptible && Type != Target->SymbolicRel || Expr == R_GOT`.

Some tests are caught by the improved error checking (ld.bfd/gold also
issue errors on them). Many misuse .long where .quad should be used
instead.

Reviewed By: ruiu

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

llvm-svn: 363059

show more ...

[ELF] Delete GotEntrySize and GotPltEntrySize

GotEntrySize and GotPltEntrySize were added in D22288. Later, with
the introduction of wordsize() (then Config->Wordsize), they become
redundant, becaus

[ELF] Delete GotEntrySize and GotPltEntrySize

GotEntrySize and GotPltEntrySize were added in D22288. Later, with
the introduction of wordsize() (then Config->Wordsize), they become
redundant, because there is no target that sets GotEntrySize or
GotPltEntrySize to a number different from Config->Wordsize.

Reviewed By: grimar, ruiu

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

llvm-svn: 362220

show more ...

Improve error message for unknown relocations.

Previously, we showed the following message for an unknown relocation:

foo.o: unrecognized reloc 256

This patch improves it so that the error messa

Improve error message for unknown relocations.

Previously, we showed the following message for an unknown relocation:

foo.o: unrecognized reloc 256

This patch improves it so that the error message includes a symbol name:

foo.o: unknown relocation (256) against symbol bar

llvm-svn: 354040

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[ELF] - Do not fail on R_*_NONE relocations when parsing the debug info.

This is https://bugs.llvm.org//show_bug.cgi?id=38919.

Currently, LLD may report "unsupported relocation target while parsing

[ELF] - Do not fail on R_*_NONE relocations when parsing the debug info.

This is https://bugs.llvm.org//show_bug.cgi?id=38919.

Currently, LLD may report "unsupported relocation target while parsing debug info"
when parsing the debug information.

At the same time LLD does that for zeroed R_X86_64_NONE relocations,
which obviously has "invalid" targets.

The nature of R_*_NONE relocation assumes them should be ignored.
This patch teaches LLD to stop reporting the debug information parsing errors for them.

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

llvm-svn: 343078

show more ...

AMDGPU/LLD: Handle R_AMDGPU_REL64 relocation

Requires r334443 from llvm

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

llvm-svn: 334444

Rename SymbolBody -> Symbol

Now that we have only SymbolBody as the symbol class. So, "SymbolBody"
is a bit strange name now. This is a mechanical change generated by

perl -i -pe s/SymbolBody/Sym

Rename SymbolBody -> Symbol

Now that we have only SymbolBody as the symbol class. So, "SymbolBody"
is a bit strange name now. This is a mechanical change generated by

perl -i -pe s/SymbolBody/Symbol/g $(git grep -l SymbolBody lld/ELF lld/COFF)

nd clang-format-diff.

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

llvm-svn: 317370

show more ...

[lld] unified COFF and ELF error handling on new Common/ErrorHandler

Summary:
The COFF linker and the ELF linker have long had similar but separate
Error.h and Error.cpp files to implement error han

[lld] unified COFF and ELF error handling on new Common/ErrorHandler

Summary:
The COFF linker and the ELF linker have long had similar but separate
Error.h and Error.cpp files to implement error handling. This change
introduces new error handling code in Common/ErrorHandler.h, changes the
COFF and ELF linkers to use it, and removes the old, separate
implementations.

Reviewers: ruiu

Reviewed By: ruiu

Subscribers: smeenai, jyknight, emaste, sdardis, nemanjai, nhaehnle, mgorny, javed.absar, kbarton, fedor.sergeev, llvm-commits

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

llvm-svn: 316624

show more ...

Simplify.

llvm-svn: 316486

LLD/ELF/AMDGPU: Process AMDGPU-specific e_flags

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

llvm-svn: 316483

Add base relative relocation record that can be used for the following case (OpenCL example):

static __global int Var = 0;
__global int* Ptr[] = {&Var};
...

In this case Var is a non premptable sy

Add base relative relocation record that can be used for the following case (OpenCL example):

static __global int Var = 0;
__global int* Ptr[] = {&Var};
...

In this case Var is a non premptable symbol and so its address can be used as the value of Ptr, with a base relative relocation that will add the delta between the ELF address and the actual load address. Such relocations do not require a symbol.

This also fixes LLD which was incorrectly generating a PCREL64 for this case.

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

llvm-svn: 315936

show more ...