- Dec 07, 2017
-
-
Alexander Richardson authored
Summary: I also changed the message to print both the ISA and the the architecture name for incompatible files. Previously it would be quite hard to find the actual path of the incompatible object files in projects that have many object files with the same name in different directories. Reviewers: atanasyan, ruiu Reviewed By: atanasyan Subscribers: emaste, sdardis, llvm-commits Differential Revision: https://reviews.llvm.org/D40958 llvm-svn: 320056
-
- Nov 29, 2017
-
-
Peter Smith authored
The AArch64 unconditional branch and branch and link instructions have a maximum range of 128 Mib. This is usually enough for most programs but there are cases when it isn't enough. This change adds support for range extension thunks to AArch64. For pc-relative thunks we follow the small code model and use ADRP, ADD, BR. This has a limit of 4 gigabytes. Differential Revision: https://reviews.llvm.org/D39744 llvm-svn: 319307
-
- Nov 27, 2017
-
-
Peter Smith authored
When an undefined weak reference has a PLT entry we must generate a range extension thunk for any B or BL that can't reach the PLT entry. This change explicitly looks for whether a PLT entry exists rather than assuming that weak references never need PLT entries unless Config->Shared is in operation. This covers the case where we are linking an executable with dynamic linking, hence a PLT entry will be needed for undefined weak references. This case comes up in real programs over 32 Mb in size as there is a B to a weak reference __gmon__start__ in the Arm crti.o for glibc. Differential Revision: https://reviews.llvm.org/D40248 llvm-svn: 319020
-
- Nov 22, 2017
-
-
Simon Atanasyan authored
llvm-svn: 318831
-
- Nov 13, 2017
-
-
Simon Atanasyan authored
microMIPS symbols including microMIPS PLT records created for regular symbols needs to be marked by STO_MIPS_MICROMIPS flag in a symbol table. Additionally microMIPS entries in a dynamic symbol table should have configured less-significant bit. That allows to escape teaching a dynamic linker about microMIPS symbols. llvm-svn: 318097
-
- Nov 09, 2017
-
-
Simon Atanasyan authored
The less-significant bit signals about microMIPS code for jump/branch instructions. llvm-svn: 317741
-
- Nov 07, 2017
-
-
Rui Ueyama authored
We have a lot of "if (MIPS)" conditions in lld because the MIPS' ABI is different at various places than other arch's ABIs at where it don't have to be different, but we at least want to reduce MIPS-ness from the regular classes. llvm-svn: 317525
-
- Nov 06, 2017
-
-
Peter Collingbourne authored
Now that DefinedRegular is the only remaining derived class of Defined, we can merge the two classes. Differential Revision: https://reviews.llvm.org/D39667 llvm-svn: 317448
-
- Nov 03, 2017
-
-
Rui Ueyama authored
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
-
- Oct 27, 2017
-
-
Peter Smith authored
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
-
Peter Smith authored
When an OutputSection is larger than the branch range for a Target we need to place thunks such that they are always in range of their caller, and sufficiently spaced to maximise the number of callers that can use the thunk. We use the simple heuristic of placing the ThunkSection at intervals corresponding to a target specific branch range. If the OutputSection is small we put the thunks at the end of the executable sections. Differential Revision: https://reviews.llvm.org/D34689 llvm-svn: 316751
-
Rui Ueyama authored
llvm-svn: 316716
-
- Oct 26, 2017
-
-
Bob Haarman authored
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
-
- Oct 24, 2017
-
-
Rui Ueyama authored
llvm-svn: 316491
-
Rui Ueyama authored
llvm-svn: 316486
-
Konstantin Zhuravlyov authored
Differential Revision: https://reviews.llvm.org/D39140 llvm-svn: 316483
-
Konstantin Zhuravlyov authored
Differential Revision: https://reviews.llvm.org/D39139 llvm-svn: 316460
-
- Oct 23, 2017
-
-
Rui Ueyama authored
The support of R_PPC_ADDR16_HI improves ld compatibility and makes things on par with RuntimeDyldELF that already implements this relocation. Patch by vit9696. llvm-svn: 316306
-
- Oct 16, 2017
-
-
Tony Tye authored
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
-
- Oct 13, 2017
-
-
Petr Hosek authored
These are generated by the linker itself and it shouldn't treat them as unrecognized. This was introduced in r315552 and is triggering an error when building UBSan shared library for i386. Differential Revision: https://reviews.llvm.org/D38899 llvm-svn: 315737
-
- Oct 12, 2017
-
-
Rui Ueyama authored
A section was passed to getRelExpr just to create an error message. But if there's an invalid relocation, we would eventually report it in relocateOne. So we don't have to pass a section to getRelExpr. llvm-svn: 315552
-
Rui Ueyama authored
llvm-svn: 315548
-
Rui Ueyama authored
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
-
- Oct 06, 2017
-
-
Alexander Richardson authored
Summary: These are 16 bit relocations and not part of a HI/LO pair so we need to check that they don't overflow. Reviewers: atanasyan Reviewed By: atanasyan Subscribers: ruiu, llvm-commits, emaste, sdardis Tags: #lld Differential Revision: https://reviews.llvm.org/D38614 llvm-svn: 315073
-
- Oct 03, 2017
-
-
Simon Atanasyan authored
If symbol has the STO_MIPS_MICROMIPS flag and requires a thunk to perform call PIC from non-PIC functions, we need to generate a thunk with microMIPS code. llvm-svn: 314797
-
- Oct 02, 2017
-
-
Simon Atanasyan authored
Currently LLD calls the `isMicroMips` routine to determine type of PLT entries needs to be generated: regular or microMIPS. This routine checks ELF header flags in the `FirstObj` to retrieve type of linked object files. So if the first file does not contain microMIPS code, LLD will generate PLT entries with regular (non-microMIPS) code only. Ideally, if a PLT entry is referenced by microMIPS code only this entry should contain microMIPS code, if a PLT entry is referenced by regular code this entry should contain regular code. In a "mixed" case the PLT entry can be either microMIPS or regular, but each "cross-mode-call" has additional cost. It's rather difficult to implement this ideal solution. But we can assume that if there is an input object file with microMIPS code, the most part of the code is microMIPS too. So we need to deduce type of PLT entries based on finally calculated ELF header flags and do not check only the first input object file. This change implements this. - The `getMipsEFlags` renamed to the `calcMipsEFlags`. The function called from the `LinkerDriver::link`. Result is stored in the Configuration::MipsEFlags field. - The `isMicroMips` and `isMipsR6` routines access the `MipsEFlags` field to get and check calculated ELF flags. - New types of PLT records created when necessary. Differential revision: https://reviews.llvm.org/D37747 llvm-svn: 314675
-
- Sep 21, 2017
-
-
Simon Atanasyan authored
This is change is inspired by the D28611 patch. New supported relocations have been added to the switch statement. llvm-svn: 313882
-
Davide Italiano authored
Follow-up suggested by Peter Smith. llvm-svn: 313850
-
Davide Italiano authored
Fixes PR34660. Differential Revision: https://reviews.llvm.org/D38053 llvm-svn: 313841
-
- Sep 19, 2017
-
-
George Rimar authored
This patch removes lot of static Instances arrays from different input file classes and introduces global arrays for access instead. Similar to arrays we have for InputSections/OutputSectionCommands. It allows to iterate over input files in a non-templated code. Differential revision: https://reviews.llvm.org/D35987 llvm-svn: 313619
-
- Sep 13, 2017
-
-
Rafael Espindola authored
llvm-svn: 313188
-
- Sep 12, 2017
-
-
Simon Atanasyan authored
The patch implements initial support of microMIPS code linking: - Handle microMIPS specific relocations. - Emit both R1-R5 and R6 microMIPS PLT records. For now linking mixed set of regular and microMIPS object files is not supported. Also the patch does not handle (setup and clear) the least-significant bit of an address which is utilized as the ISA mode bit and allows to make jump between regular and microMIPS code without any thunks. Differential revision: https://reviews.llvm.org/D37335 llvm-svn: 313028
-
- Sep 07, 2017
-
-
Peter Smith authored
To support errata patching on AArch64 we need to be able to overwrite an arbitrary instruction with a branch. For AArch64 it is sufficient to always write all the bits of the branch instruction and not just the immediate field. This is safe as the non-immediate bits of the branch instruction are always the same. Differential Revision: https://reviews.llvm.org/D36745 llvm-svn: 312727
-
- Sep 06, 2017
-
-
Peter Smith authored
The R_AARCH64_LDST<N>_ABS LO12_NC relocations where N is 8, 16, 32, 64 or 128 have a scaled immediate. For example R_AARCH64_LDST32_ABS_LO12_NC shifts the calculated value right by 4. If the target symbol + relocation addend is not aligned properly then bits of the answer will be lost. This change adds an alignment check to the relocations to make sure the target of the relocation is aligned properly. This matches the behavior of GNU ld. The motivation is to catch ODR violations such as a declaration of extern int foo, but a definition of bool foo as the compiler may use R_AARCH64_LDST32_ABS_LO12_NC for the former, but not align the destination. Differential Revision: https://reviews.llvm.org/D37444 llvm-svn: 312637
-
- Sep 04, 2017
-
-
Simon Atanasyan authored
Pass BSIZE and SHIFT as a function arguments to the `writeRelocation` routine. It does not make a sense to have so many `writeRelocation's` instances. llvm-svn: 312495
-
Simon Atanasyan authored
llvm-svn: 312494
-
- Aug 31, 2017
-
-
George Rimar authored
llvm-svn: 312231
-
- Aug 28, 2017
-
-
Simon Atanasyan authored
llvm-svn: 311889
-
- Aug 24, 2017
-
-
Simon Atanasyan authored
llvm-svn: 311712
-
Simon Atanasyan authored
Currently LLD reads the R_MIPS_HI16's addends in the `computeMipsAddend` function, the R_MIPS_LO16's addends in both `computeMipsAddend` and `getImplicitAddend` functions. This patch moves reading all addends to the `getImplicitAddend` function. As a side effect it fixes a "paired" HI16/LO16 addend calculation if "LO16" part of a pair is not found. llvm-svn: 311711
-