Commit Graph

573 Commits

Author SHA1 Message Date
Fangrui Song 50564ca075 [ELF] Rename adjustRelaxExpr to adjustTlsExpr and delete the unused `data` parameter. NFC
Reviewed By: psmith

Differential Revision: https://reviews.llvm.org/D91995
2020-11-25 09:00:55 -08:00
Fangrui Song 572d18397c [ELF] Add TargetInfo::adjustGotPcExpr for `R_GOT_PC` relaxations. NFC
With this change, `TargetInfo::adjustRelaxExpr` is only related to TLS
relaxations and a subsequent clean-up can delete the `data` parameter.

Differential Revision: https://reviews.llvm.org/D92079
2020-11-25 08:43:26 -08:00
Fangrui Song 07837b8f49 [ELF] Use namespace qualifiers (lld:: or elf::) instead of `namespace lld { namespace elf {`
Similar to D74882. This reverts much code from commit
bd8cfe65f5 (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
2020-05-15 08:49:53 -07:00
Benjamin Kramer adcd026838 Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 23:25:25 +01:00
Fangrui Song 1e57038bf2 [ELF] Pass `Relocation` to relaxGot and relaxTls{GdToIe,GdToLe,LdToLe,IeToLe}
These functions call relocateOne(). This patch is a prerequisite for
making relocateOne() aware of `Symbol` (D73254).

Reviewed By: grimar, nickdesaulniers

Differential Revision: https://reviews.llvm.org/D73250
2020-01-23 10:39:25 -08:00
Alex Richardson 441410be47 [ELF] Avoid false-positive assert in getErrPlace()
This assertion was added as part of D70659 but did not account for .bss
input sections. I noticed that this assert was incorrectly triggering
while building FreeBSD for MIPS64. Fixed by relaxing the assert to also
account for SHT_NOBITS input sections and adjust the test
mips-jalr-non-function.s to link a file with a .bss section first.

Reviewed By: MaskRay, grimar
Differential Revision: https://reviews.llvm.org/D72567
2020-01-15 14:32:25 +00:00
Fangrui Song 2d077d6dfa [ELF] Make TargetInfo::writeIgotPlt a no-op
RELA targets don't read initial .got.plt entries.
REL targets (ARM, x86-32) write the address of the IFUNC resolver to the
entry (`write32le(buf, s.getVA())`).

The default writeIgotPlt() is not meaningful. Make it a no-op. AArch64
and x86-64 will have 0 as initial .got.plt entries associated with
IFUNC.

Reviewed By: peter.smith

Differential Revision: https://reviews.llvm.org/D72474
2020-01-10 09:59:22 -08:00
Alex Richardson 1444e6e2e6 Re-apply "[ELF] Allow getErrPlace() to work before Out::bufferStart is set"
This time with a fix for the UBSAN failure.

Differential Revision: https://reviews.llvm.org/D70659
2020-01-09 20:26:31 +00:00
Vlad Tsyrklevich 17063abd1e Revert "[ELF] Allow getErrPlace() to work before Out::bufferStart is set"
This reverts commit 2bbd32f5e8, it was
causing UBSan failures like the following:
lld/ELF/Target.cpp:103:41: runtime error: applying non-zero offset 24 to null pointer
2019-12-13 09:43:51 -08:00
Alex Richardson 2bbd32f5e8 [ELF] Allow getErrPlace() to work before Out::bufferStart is set
Summary:
So far it seems like the only test affected by this change is the one I
recently added for R_MIPS_JALR relocations since the other test cases that
use this function early (unknown-relocation-*) do not have a valid input
section for the relocation offset.

Reviewers: ruiu, grimar, MaskRay, espindola

Reviewed By: ruiu, MaskRay

Subscribers: emaste, sdardis, jrtc27, atanasyan, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70659
2019-12-13 12:19:55 +00:00
Fangrui Song bf535ac4a2 [ELF][AArch64] Support R_AARCH64_{CALL26,JUMP26} range extension thunks with addends
Fixes AArch64 part of PR40438

The current range extension thunk framework does not handle a relocation
relative to a STT_SECTION symbol with a non-zero addend, which may be
used by jumps/calls to local functions on some RELA targets (AArch64,
powerpc ELFv1, powerpc64 ELFv2, etc).  See PR40438 and the following
code for examples:

  // clang -target $target a.cc
  // .text.cold may be placed in a separate output section.
  // The distance between bar in .text.cold and foo in .text may be larger than 128MiB.
  static void foo() {}
  __attribute__((section(".text.cold"))) static int bar() { foo(); return
  0; }
  __attribute__((used)) static int dummy = bar();

This patch makes such thunks with addends work for AArch64. The target
independent part can be reused by PPC in the future.

On REL targets (ARM, MIPS), jumps/calls are not represented as
STT_SECTION + non-zero addend (see
MCELFObjectTargetWriter::needsRelocateWithSymbol), so they don't need
this feature, but we need to make sure this patch does not affect them.

Reviewed By: peter.smith

Differential Revision: https://reviews.llvm.org/D70637
2019-12-02 10:07:24 -08:00
Rui Ueyama 9adea6e4fa Make nullptr check more robust
The only condition that isecLoc becomes null is

  Out::bufferStart == nullptr,
  isec->getParent()->offset == 0, and
  isec->outSecOff == 0.

We can check the first condition only once.

llvm-svn: 374332
2019-10-10 12:41:08 +00:00
Roman Lebedev 1508fbad79 [lld] getErrPlace(): don't perform arithmetics on maybe-null pointer
isecLoc there can be null, but at the same time isec->getSize() may
be non-null. It is UB to offset a nullptr.The most straight-forward fix
here appears to perform casts+normal integral arithmetics.

FAIL: lld :: ELF/invalid/invalid-relocation-aarch64.test (1158 of 2217)
******************** TEST 'lld :: ELF/invalid/invalid-relocation-aarch64.test' FAILED ********************
Script:
--
: 'RUN: at line 2';   /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/yaml2obj /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-aarch64.test.tmp.o
: 'RUN: at line 3';   not /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/ld.lld /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-aarch64.test.tmp.o -o /dev/null 2>&1 | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test
--
Exit Code: 1

Command Output (stderr):
--
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test:4:10: error: CHECK: expected string not found in input
# CHECK: error: unknown relocation (1024) against symbol foo
         ^
<stdin>:1:1: note: scanning from here
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp💯41: runtime error: applying non-zero offset 24 to null pointer
^
<stdin>:1:118: note: possible intended match here
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp💯41: runtime error: applying non-zero offset 24 to null pointer
                                                                                                                     ^

--

********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.
FAIL: lld :: ELF/invalid/invalid-relocation-x64.test (1270 of 2217)
******************** TEST 'lld :: ELF/invalid/invalid-relocation-x64.test' FAILED ********************
Script:
--
: 'RUN: at line 2';   /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/yaml2obj /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp1.o
: 'RUN: at line 3';   echo ".global foo; foo:" > /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.s
: 'RUN: at line 4';   /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/llvm-mc /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.s -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.o -filetype=obj -triple x86_64-pc-linux
: 'RUN: at line 5';   not /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/ld.lld /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp1.o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.o -o /dev/null 2>&1 | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test
--
Exit Code: 1

Command Output (stderr):
--
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test:6:10: error: CHECK: expected string not found in input
# CHECK: error: unknown relocation (152) against symbol foo
         ^
<stdin>:1:1: note: scanning from here
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp💯41: runtime error: applying non-zero offset 24 to null pointer
^
<stdin>:1:118: note: possible intended match here
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp💯41: runtime error: applying non-zero offset 24 to null pointer
                                                                                                                     ^

--

********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 20.73s
********************
Failing Tests (2):
    lld :: ELF/invalid/invalid-relocation-aarch64.test
    lld :: ELF/invalid/invalid-relocation-x64.test

llvm-svn: 374329
2019-10-10 12:22:55 +00:00
Fangrui Song bd8cfe65f5 [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
2019-10-07 08:31:18 +00:00
Rui Ueyama 3837f4273f [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
2019-07-10 05:00:37 +00:00
Fangrui Song 912251e82f [PPC64] toc-indirect to toc-relative relaxation
This is based on D54720 by Sean Fertile.

When accessing a global symbol which is not defined in the translation unit,
compilers will generate instructions that load the address from the toc entry.

If the symbol is defined, non-preemptable, and addressable with a 32-bit
signed offset from the toc pointer, the address can be computed
directly. e.g.

    addis 3, 2, .LC0@toc@ha  # R_PPC64_TOC16_HA
    ld    3, .LC0@toc@l(3)   # R_PPC64_TOC16_LO_DS, load the address from a .toc entry
    ld/lwa 3, 0(3)           # load the value from the address

    .section .toc,"aw",@progbits
    .LC0: .tc var[TC],var

can be relaxed to

    addis 3,2,var@toc@ha     # this may be relaxed to a nop,
    addi  3,3,var@toc@l      # then this becomes addi 3,2,var@toc
    ld/lwa 3, 0(3)           # load the value from the address

We can delete the test ppc64-got-indirect.s as its purpose is covered by
newly added ppc64-toc-relax.s and ppc64-toc-relax-constants.s

Reviewed By: ruiu, sfertile

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

llvm-svn: 360112
2019-05-07 04:26:05 +00:00
Rui Ueyama 676d25ab94 De-template X86_64TargetInfo. NFC.
llvm-svn: 357191
2019-03-28 17:31:12 +00:00
Rui Ueyama c694633a12 Make TargetInfo const. NFC.
We do not mutate a TargetInfo instance after creating it. This change
makes it explicit.

llvm-svn: 357185
2019-03-28 17:05:09 +00:00
Peter Collingbourne 7fb9eabda5 ELF: Write .eh_frame_hdr explicitly after writing .eh_frame.
This lets us remove the special case from Writer::writeSections(), and also
fixes a bug where .eh_frame_hdr isn't necessarily written in the correct
order if a linker script moves .eh_frame and .eh_frame_hdr into the same
output section.

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

llvm-svn: 355153
2019-02-28 23:11:35 +00:00
Chandler Carruth 2946cd7010 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
2019-01-19 08:50:56 +00:00
George Rimar 73af3d4060 [LLD][ELF] - Support MSP430.
Patch by Michael Skvortsov!

This change adds a basic support for linking static MSP430 ELF code.
Implemented relocation types are intended to correspond to the BFD.

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

llvm-svn: 350819
2019-01-10 13:43:06 +00:00
Rui Ueyama cace50c628 Use llvm_unreachable for unreachable code.
llvm-svn: 345885
2018-11-01 20:08:29 +00:00
Sean Fertile 4b5ec7fb80 Reland "[PPC64] Add split - stack support."
Recommitting https://reviews.llvm.org/rL344544 after fixing undefined behavior
from left-shifting a negative value. Original commit message:

This support is slightly different then the X86_64 implementation in that calls
to __morestack don't need to get rewritten to calls to __moresatck_non_split
when a split-stack caller calls a non-split-stack callee. Instead the size of
the stack frame requested by the caller is adjusted prior to the call to
__morestack. The size the stack-frame will be adjusted by is tune-able through a
new --split-stack-adjust-size option.

llvm-svn: 344622
2018-10-16 17:13:01 +00:00
Sean Fertile 831a1336ff Revert "[PPC64] Add split - stack support."
This reverts commit https://reviews.llvm.org/rL344544, which causes failures on
a undefined behaviour sanitizer bot -->
lld/ELF/Arch/PPC64.cpp:849:35: runtime error: left shift of negative value -1

llvm-svn: 344551
2018-10-15 20:20:28 +00:00
Sean Fertile 795cc9332b [PPC64] Add split - stack support.
This support is slightly different then the X86_64 implementation in that calls
to __morestack don't need to get rewritten to calls to __moresatck_non_split
when a split-stack caller calls a non-split-stack callee. Instead the size of
the stack frame requested by the caller is adjusted prior to the call to
__morestack. The size the stack-frame will be adjusted by is tune-able through a
new --split-stack-adjust-size option.

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

llvm-svn: 344544
2018-10-15 19:05:57 +00:00
Rui Ueyama 5cd9c6bcd8 Support RISC-V
Patch by PkmX.

This patch makes lld recognize RISC-V target and implements basic
relocation for RV32/RV64 (and RVC). This should be necessary for static
linking ELF applications.

The ABI documentation for RISC-V can be found at:
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md.
Note that the documentation is far from complete so we had to figure out
some details from bfd.

The patch should be pretty straightforward. Some highlights:

 - A new relocation Expr R_RISCV_PC_INDIRECT is added. This is needed as
   the low part of a PC-relative relocation is linked to the corresponding
   high part (auipc), see:
   https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#pc-relative-symbol-addresses

 - LLVM's MC support for RISC-V is very incomplete (we are working on
   this), so tests are given in objectyaml format with the original
   assembly included in the comments. Once we have complete support for
   RISC-V in MC, we can switch to llvm-as/llvm-objdump.

 - We don't support linker relaxation for now as it requires greater
   changes to lld that is beyond the scope of this patch. Once this is
   accepted we can start to work on adding relaxation to lld.

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

llvm-svn: 339364
2018-08-09 17:59:56 +00:00
Sterling Augustine 4fd84c18df Implement framework for linking split-stack object files, and x86_64 support.
llvm-svn: 337332
2018-07-17 23:16:02 +00:00
George Rimar 03b0a4856f [ELF] - Cleanup error reporting code and cover with the test. NFC.
We have the following code that is uncovered with the test:
https://github.com/llvm-mirror/lld/blob/master/ELF/Target.cpp#L95

This patch:
1) Removes "!IS" check. Because at that point of execution
(we are reolving the relocations during writing output)
we should only have InputSection type of the sections in the vector.
(because we already converted MergeInputSection in mergeSections()
and combined EhInputSections in combineEhFrameSections()).

2) Covers the "!IS->getParent()" with the test.

llvm-svn: 336106
2018-07-02 14:13:11 +00:00
Sid Manning 95b0c2e1e3 Add Hexagon Support
Differential Revision: https://reviews.llvm.org/D47791

llvm-svn: 334637
2018-06-13 18:45:25 +00:00
George Rimar 89481f363a [ELF] - Teach LLD to hint about -fdebug-types-section.
Patch teaches LLD to hint user about -fdebug-types-section flag
if relocation overflow happens in debug section.

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

llvm-svn: 328081
2018-03-21 09:19:34 +00:00
Rafael Espindola bb3198949f Use dyn_cast instead of dyn_cast_or_null.
There should be no null sections in InputSections.

llvm-svn: 321219
2017-12-20 20:46:08 +00:00
Rui Ueyama f52496e1e0 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
2017-11-03 21:21:47 +00:00
Peter Smith 75030b6d56 [ELF] Introduce range extension thunks for ARM
This change adds initial support for range extension thunks. All thunks must
be created within the first pass so some corner cases are not supported. A
follow up patch will add support for multiple passes.

With this change the existing tests arm-branch-error.s and
arm-thumb-branch-error.s now no longer fail with an out of range branch.
These have been renamed and tests added for the range extension thunk.

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

llvm-svn: 316752
2017-10-27 09:04:11 +00:00
Bob Haarman b8a59c8aa5 [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
2017-10-25 22:28:38 +00:00
Rui Ueyama 67533a2cb3 Define RelType to represent relocation types.
We were using uint32_t as the type of relocation kind. It has a
readability issue because what Type really means in `uint32_t Type`
is not obvious. It could be a section type, a symbol type or a
relocation type.

Since we do not do any arithemetic operations on relocation types
(e.g. adding one to R_X86_64_PC32 doesn't make sense), it would be
more natural if they are represented as enums. Unfortunately, that
is not doable because relocation type definitions are spread into
multiple header files.

So I decided to use typedef. This still should be better than the
plain uint32_t because the intended type is now obvious.

llvm-svn: 315525
2017-10-11 22:49:24 +00:00
James Henderson b5ca92ef73 [ELF] Set Dot initially to --image-base value when using linker scripts
When parsing linker scripts, LLD previously started with a '.' value of 0,
regardless of the internal default image base for the target, and regardless of
switches such as --image-base. It seems reasonable to use a different image base
value when using linker scripts and --image-base is specified, since otherwise the
switch has no effect. This change does this, as well as removing unnecessary
initialisation of Dot where it is not used.

The default image base should not be used when processing linker
scripts, because this will change the behaviour for existing linker script users,
and potentially result in invalid output being produced, as a subsequent assignment
to Dot could move the location counter backwards. Instead, we maintain the existing
behaviour of starting from 0 if --image-base is not specified.

Reviewers: ruiu

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

llvm-svn: 315293
2017-10-10 10:09:35 +00:00
Peter Smith a49442f323 [ELF] Introduce target specific inBranchRange() function
In preparation for range extension thunks introduce a function that will
check whether a branch identified by a relocation type at a source address
can reach a destination.

For targets where range extension thunks are not supported the function will
return true as it is not expected that branches are out of range. An
implementation has been provided for ARM.

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

llvm-svn: 308188
2017-07-17 16:54:29 +00:00
Rui Ueyama 0cc1483562 Add basic 64-bit SPARC support
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
2017-06-28 17:05:39 +00:00
Rui Ueyama e145bc22fd Do not use make<> to allocate TargetInfo. NFC.
llvm-svn: 305577
2017-06-16 20:15:03 +00:00
Rui Ueyama 21c0a9ceeb Split Target.cpp into small files.
Target.cpp contains code for all the targets that LLD supports. It was
simple and easy, but as the number of supported targets increased,
it got messy.

This patch splits the file into per-target files under ELF/arch directory.

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

llvm-svn: 305565
2017-06-16 17:32:43 +00:00
Leslie Zhai 49ba795d15 [ELF] Initial migration of AVR target
Reviewers: ruiu, rafael, grimar, atanasyan, psmith, dylanmckay

Reviewed By: ruiu, rafael, grimar, dylanmckay

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

llvm-svn: 305444
2017-06-15 02:27:50 +00:00
Rafael Espindola 07c8741644 Relax the overflow checking of R_386_PC16.
Currently the freebsd early boot code fails to link. The issue reduces
to 16 bit code at position 0x7000 wanting to jump to position
0x9000. That is represented in the .o file as a relocation with no
symbol and an addend of 0x9000 - 2 (The -2 is because i386 uses the ip
after the current instruction for jumps).

If the addend is interpreted as signed (it should), it is -28674. In a
32 bit architecture, that is the address 0xffff8ffe. To get there from
0x7000 we have to add 4294909950 (too big) or subtract 57346 (too
small). We then produce an error.

What lld is missing is the fact that at runtime this will actually be
a 16 bit architecture and adding 0x1ffe produces 0x8ffe which is the
correct result in 16 bits (-28674).

Since we have a 16 bit addend and a 16 bit PC, the relocation can move
the PC to any 16 bit address and that is the only thing we really need
to check: if the address we are pointing to fits in 16 bits. This is
unfortunately hard to do since we have to delay subtracting the PC and
if we want to do that outside of Target.cpp, we have to move the
overflow check out too.  An incomplete patch that tries to do that is
at https://reviews.llvm.org/D34070

This patch instead just relaxes the check. Since the value we have is
the destination minus the PC and the PC is 16 bits, it should fit in
17 bits if the destination fits in 16 too.

bfd had a similar issue for some time and got a similar fix:
https://sourceware.org/ml/binutils/2005-08/msg00001.html

llvm-svn: 305135
2017-06-10 01:56:58 +00:00
Rui Ueyama 38a2841665 Use LLVM_FALLTHROUGH.
llvm-svn: 305010
2017-06-08 20:16:21 +00:00
Zachary Turner 264b5d9e88 Move Object format code to lib/BinaryFormat.
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.

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

llvm-svn: 304864
2017-06-07 03:48:56 +00:00
Rafael Espindola db5e56f7b2 Store a single Parent pointer for InputSectionBase.
Before InputSectionBase had an OutputSection pointer, but that was not
always valid. For example, if it was a merge section one actually had
to look at MergeSec->OutSec.

This was brittle and caused bugs like the one fixed by r304260.

We now have a single Parent pointer that points to an OutputSection
for InputSection, but to a SyntheticSection for merge sections and
.eh_frame. This makes it impossible to accidentally access an invalid
OutSec.

llvm-svn: 304338
2017-05-31 20:17:44 +00:00
Peter Smith d54f368e6a [ELF] Support R_ARM_SBREL32 Relocation
This change adds support for the R_ARM_SBREL32 relocation. The relocation
is a base relative relocation that is produced by clang/llvm when -frwpi
is used. The use case for the -frwpi option is position independent data
for embedded systems that do not have a GOT. With -frwpi all data is
accessed via an offset from a base register (usually r9), where r9 is set
at run time to where the data has been loaded. The base of the data is
known as the static base.

The ARM ABI defines the static base as:
B(S) is the addressing origin of the output segment defining the symbol S.
The origin is not required to be the base address of the segment. For
simplicity we choose to use the base address of the segment.

The ARM procedure call standard only defines a read write variant using
R_ARM_SBREL32 relocations. The read-only data is accessed via pc-relative
offsets from the code, this is implemented in clang as -fropi.

Fixes PR32924

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

llvm-svn: 303337
2017-05-18 09:12:21 +00:00
George Rimar 390242d0e9 [ELF] - Detemplate elf::addSyntheticLocal(). NFC.
llvm-svn: 303155
2017-05-16 10:11:36 +00:00
George Rimar b4081bb0ab [ELF] - Stop support of DF_STATIC_TLS flag.
This reverts changes introduced in r302414 "[ELF] - Set DF_STATIC_TLS flag for i386 target."

Because DF_STATIC_TLS does not look to be used by glibc or anything else.

llvm-svn: 302884
2017-05-12 08:04:58 +00:00
George Rimar 6f586731c5 [ELF] - Don't allow R_X86_64_TPOFF32 dynamic relocation when linking PIC
Both gold and bfd restrict that one:

ld.bfd: test.o: relocation R_X86_64_TPOFF32 against `var' can not be 
used when making a shared object; recompile with -fPIC
ld.gold: error: test.o: unsupported reloc 23 against global symbol var

What looks reasonable because it is 32 bit one. Patch do the same.

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

llvm-svn: 302881
2017-05-12 07:19:11 +00:00
Rafael Espindola 88ab9fb163 Detemplate the got.
This is a bit hackish, but allows for a lot of followup cleanups.

llvm-svn: 302845
2017-05-11 23:26:03 +00:00