| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LD -> LE optimization for Thread-Local Storage without PLT requires
an additional "66" prefix, otherwise the next instruction will be
corrupted, causing runtime misbehavior (crashes) of the linked object.
The other (GD -> IE/LD) optimizations are the same with or without PLT,
but add tests for completeness. The instructions are copied from
https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x86-64-psABI-1.0.pdf#subsection.11.1.2
This does not try to address ILP32 (x32) support.
Fixes https://bugs.llvm.org/show_bug.cgi?id=37303
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D56779
llvm-svn: 351396
|
|
|
|
| |
llvm-svn: 350853
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the range between the source and target of a V7PILongThunk exceeded an
int32 we would trigger a relocation out of range error for the
R_ARM_MOVT_PREL or R_ARM_THM_MOVT_PREL relocation. This case can happen when
linking the linux kernel as it is loaded above 0xf0000000.
There are two parts to the fix.
- Remove the overflow check for R_ARM_MOVT_PREL or R_ARM_THM_MOVT_PREL. The
ELF for the ARM Architecture document defines these relocations as having no
overflow checking so the check was spurious.
- Use int64_t for the offset calculation, in line with similar thunks so
that PC + (S - P) < 32-bits. This results in less surprising disassembly.
Differential Revision: https://reviews.llvm.org/D56396
llvm-svn: 350836
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the PPC64 target we map toc-relative relocations, dynamic thread pointer
relative relocations, and got relocations into a corresponding ADDR16 relocation
type for handling in relocateOne. This patch saves the orignal RelType before
mapping to an ADDR16 relocation so that any diagnostic messages will not
mistakenly use the mapped type.
Differential Revision: https://reviews.llvm.org/D56448
llvm-svn: 350827
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D54907
llvm-svn: 349772
|
|
|
|
|
|
| |
Differential Revison: https://reviews.llvm.org/D54859
llvm-svn: 349511
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we considered R_ARM_V4BX to be an absolute relocation,
which meant that we rejected it in read-only sections in PIC output
files. Instead, treat it as a hint relocation so that relocation
processing ignores it entirely.
Also fix a problem with the test case where it was never being run
because it has a .yaml extension and we don't run tests with that
extension.
Differential Revision: https://reviews.llvm.org/D55728
llvm-svn: 349216
|
|
|
|
| |
llvm-svn: 348294
|
|
|
|
|
|
|
|
|
|
| |
When linking the linux kernel on ppc64 and ppc
ld.lld: error: unrecognized reloc 11
11 is PPC_REL14 and PPC64_REL14
Differential revision: https://reviews.llvm.org/D54868
llvm-svn: 348255
|
|
|
|
|
|
|
|
|
|
|
| |
This patch also makes getPltEntryOffset a non-member function because
it doesn't depend on any private members of the TargetInfo class.
I tried a few different ideas, and it seems this change fits in best to me.
Differential Revision: https://reviews.llvm.org/D54981
llvm-svn: 347781
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch implementation the handler for ARM_V4BX. This relocation is used by GNU runtime files and other armv4 applications.
Patch by Yin Ma
Reviewers: espindola, MaskRay, ruiu, peter.smith, pcc
Reviewed By: ruiu
Subscribers: yinma, pcc, peter.smith, MaskRay, rovka, efriedma, emaste, javed.absar, arichardson, kristof.beyls, chrib, llvm-commits
Differential Revision: https://reviews.llvm.org/D53444
llvm-svn: 347077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current value using as a trap instruction (0xefefefef) is not a good choice
for MIPS because it's a valid MIPS instruction `swc3 $15,-4113(ra)`. This
patch replaces 0xefefefef by 0x04170001. For all MIPS ISA revisions before
R6, this value is just invalid instruction. Starting from MIPS R6 it's
a valid instruction `sigrie 1` which signals a Reserved Instruction exception.
mips-traps.s test case is added to test trap encoding. Other test cases
are modified to remove redundant checking.
Differential revision: https://reviews.llvm.org/D54154
llvm-svn: 347029
|
|
|
|
|
|
| |
They are AArch64 only, so have to have AARCH64_* prefix.
llvm-svn: 346963
|
|
|
|
|
|
|
|
|
|
|
|
| |
The uint32_t type does not clearly convey that these fields are interpreted
in the target endianness. Converting them to byte arrays should make this
more obvious and less error-prone.
Patch by James Clarke
Differential Revision: http://reviews.llvm.org/D54207
llvm-svn: 346893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On PowerPC64, when a function call offset is too large to encode in a call
instruction the address is stored in a table in the data segment. A thunk is
used to load the branch target address from the table relative to the
TOC-pointer and indirectly branch to the callee. When linking position-dependent
code the addresses are stored directly in the table, for position-independent
code the table is allocated and filled in at load time by the dynamic linker.
For position-independent code the branch targets could have gone in the .got.plt
but using the .branch_lt section for both position dependent and position
independent binaries keeps it consitent and helps keep this PPC64 specific logic
seperated from the target-independent code handling the .got.plt.
Differential Revision: https://reviews.llvm.org/D53408
llvm-svn: 346877
|
|
|
|
|
|
| |
They did not have AArch64 prefix. Now they do.
llvm-svn: 346749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
D53821 fixed the bogus MSVC (at least 2017) C4146 warning (unary minus applied on unsigned type)
by using std::numeric_limits<int32_t>::min().
The warning was because -2147483648 is incorrectly treated as unsigned long instead of long long)
Let's use INT32_MIN which is arguably more readable.
Note, on GCC or clang, -0x80000000 works fine (ILP64: long, LP64: long long).
Reviewers: ruiu, jhenderson, sfertile, espindola
Reviewed By: sfertile
Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D54200
llvm-svn: 346356
|
|
|
|
| |
llvm-svn: 345886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are really three different kinds of TLS layouts:
* A fixed TLS-to-TP offset. On architectures like PowerPC, MIPS, and
RISC-V, the thread pointer points to a fixed offset from the start
of the executable's TLS segment. The offset is 0x7000 for PowerPC
and MIPS, which allows a signed 16-bit offset to reach 0x1000 of
per-thread implementation data and 0xf000 of the application's TLS
segment. The size and layout of the TCB isn't relevant to the static
linker and might not be known.
* A fixed TCB size. This is the format documented as "variant 1" in
Ulrich Drepper's TLS spec. The thread pointer points to a 2-word TCB
followed by the executable's TLS segment. The first word is always
the DTV pointer. Used on ARM. The thread pointer must be aligned to
the TLS segment's alignment, possibly creating alignment padding.
* Variant 2. This format predates variant 1 and is also documented in
Drepper's TLS spec. It allocates the executable's TLS segment before
the thread pointer, apparently for backwards-compatibility. It's
used on x86 and SPARC.
Factor out an lld::elf::getTlsTpOffset() function for use in a
follow-up patch for Android. The TcbSize/TlsTpOffset fields are only used
in getTlsTpOffset, so replace them with a switch on Config->EMachine.
Reviewers: espindola, ruiu, PkmX, jrtc27
Reviewed By: ruiu, PkmX, jrtc27
Subscribers: jyknight, emaste, sdardis, nemanjai, javed.absar, arichardson, kristof.beyls, kbarton, fedor.sergeev, atanasyan, PkmX, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D53905
llvm-svn: 345775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Visual Studio has a bug where it converts the integer literal 2147483648
into an unsigned int instead of a long long (i.e. it follows C89 rules).
The bug has been reported as:
https://developercommunity.visualstudio.com/content/problem/141813/-2147483648-c4146-error.html.
Because of this bug, we were getting a signed/unsigned comparison
warning in VS2015 from the old code (the subsequent unary negation had
no effect on the type).
Reviewed by: sfertile
Differential Revision: https://reviews.llvm.org/D53821
llvm-svn: 345579
|
|
|
|
|
|
| |
The blt- instruction (predicted not to be taken) uses cr7, not the default cr0.
llvm-svn: 344948
|
|
|
|
|
|
| |
Mainly two mis-indented places. The changes are local so should not interfere with in-review revisions
llvm-svn: 344932
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adjusted the range check on a call instruction from 24 bits signed to
26 bits signed. While the instruction only encodes 24 bits, the target is
assumed to be 4 byte aligned, and the value that is encoded in the instruction
gets shifted left by 2 to form the offset. Also added a check that the offset is
indeed at least 4 byte aligned.
Differential Revision: https://reviews.llvm.org/D53401
llvm-svn: 344747
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D53204
llvm-svn: 344518
|
|
|
|
| |
llvm-svn: 344302
|
|
|
|
| |
llvm-svn: 344076
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D52909
llvm-svn: 343972
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GOT is referenced through the symbol _GLOBAL_OFFSET_TABLE_ .
The relocation added calculates the offset into the global offset table for
the entry of a symbol. In order to get the correct TargetVA I needed to
create an new relocation expression, HEXAGON_GOT. It does
Sym.getGotVA() - In.GotPlt->getVA().
Differential Revision: https://reviews.llvm.org/D52744
llvm-svn: 343784
|
|
|
|
|
|
|
|
| |
Update testcase.
Differential Revision: https://reviews.llvm.org/D52734
llvm-svn: 343515
|
|
|
|
|
|
|
|
|
| |
Write out the PLT header and stub.
Hexagon uses RELA relocations.
Differential Revision: https://reviews.llvm.org/D52317
llvm-svn: 343320
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
An AArch64 LE relocation is a positive ("variant 1") offset. This
relocation is used to write the upper 12 bits of a 24-bit offset into an
add instruction:
add x0, x0, :tprel_hi12:v1
The comment in the ARM docs for R_AARCH64_TLSLE_ADD_TPREL_HI12 is:
"Set an ADD immediate field to bits [23:12] of X; check 0 <= X < 2^24."
Reviewers: javed.absar, espindola, ruiu, peter.smith, zatrazz
Reviewed By: ruiu
Subscribers: emaste, arichardson, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D52525
llvm-svn: 343144
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Previously, if you invoke lld's `main` more than once in the same process,
the second invocation could fail or produce a wrong result due to a stale
pointer values of the previous run.
Differential Revision: https://reviews.llvm.org/D52506
llvm-svn: 343009
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As for x86_64, the default image base for AArch64 and i386 should be
aligned to a superpage appropriate for the architecture.
On AArch64, this is 2 MiB, on i386 it is 4 MiB.
Reviewers: emaste, grimar, javed.absar, espindola, ruiu, peter.smith, srhines, rprichard
Reviewed By: ruiu, peter.smith
Subscribers: jfb, markj, arichardson, krytarowski, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D50297
llvm-svn: 342746
|
|
|
|
|
|
| |
Update testcase to reflect the change.
llvm-svn: 342662
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PPC64 elf V2 abi defines 2 entry points for a function. There are a few
places we need to calculate the offset from the global entry to the local entry
and how this is done is not straight forward. This patch adds a helper function
mostly for documentation purposes, explaining how the 2 entry points differ and
why we choose one over the other, as well as documenting how the offsets are
encoded into a functions st_other field.
Differential Revision: https://reviews.llvm.org/D52231
llvm-svn: 342603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The access sequence for global variables in the medium and large code models use
2 instructions to add an offset to the toc-pointer. If the offset fits whithin
16-bits then the instruction that sets the high 16 bits is redundant.
This patch adds the --toc-optimize option, (on by default) and enables rewriting
of 2 instruction global variable accesses into 1 when the offset from the
TOC-pointer to the variable (or .got entry) fits in 16 signed bits. eg
addis %r3, %r2, 0 --> nop
addi %r3, %r3, -0x8000 --> addi %r3, %r2, -0x8000
This rewriting can be disabled with the --no-toc-optimize flag
Differential Revision: https://reviews.llvm.org/D49237
llvm-svn: 342602
|
|
|
|
|
|
|
|
|
|
| |
A General-dynamic tls access can be written using a R_PPC64_TLSGD16 relocation
if the target got entry is within 16 bits of the TOC-base. This patch adds
support for R_PPC64_TLSGD16 by relaxing it the same as a R_PPC64_GOT_TLSGD16_LO.
Differential Revision: https://reviews.llvm.org/D52055
llvm-svn: 342411
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are a growing number of places when we either want to read or write an
instruction when handling a half16 relocation type. On big-endian the buffer
pointer is pointing into the middle of the word we want and on little-endian it
is pointing to the start of the word. These 2 helpers are to simplify reading
and writing in these contexts.
Differential Revision: https://reviews.llvm.org/D52115
llvm-svn: 342410
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Relanding r340564, original commit message:
Fixes the handling of *_DS relocations used on DQ-form instructions where we
were overwriting some of the extended opcode bits. Also adds an alignment check
so that the user will receive a diagnostic error if the value we are writing
is not properly aligned.
Differential Revision: https://reviews.llvm.org/D51124
llvm-svn: 340832
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D51225
llvm-svn: 340739
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D51166
llvm-svn: 340693
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D51045
llvm-svn: 340692
|
|
|
|
|
|
|
|
| |
This reverts commit 5125b44dbb5d06b715213e4bec75c7346bfcc7d3.
ppc64-dq.s and ppc64-error-missaligned-dq.s fail on several of the build-bots.
Reverting to investigate.
llvm-svn: 340568
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the handling of *_DS relocations used on DQ-form instructions where we
were overwriting some of the extended opcode bits. Also adds an alignment check
so that the user will receive a diagnostic error if the value we are writing
is not properly aligned.
Differential Revision: https://reviews.llvm.org/D51124
llvm-svn: 340564
|