summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Relocations.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [ELF] Pre-create ThunkSections at Target specific intervalsPeter Smith2017-10-271-15/+49
| | | | | | | | | | | | | | 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
* [ELF] Record created ThunkSections in InputSectionDescription [NFC].Peter Smith2017-10-271-92/+83
| | | | | | | | | Instead of maintaining a map of the std::vector to ThunkSections, record the ThunkSections directly in InputSectionDescription. Differential Revision: https://reviews.llvm.org/D37743 llvm-svn: 316750
* De-template elf::getObjMsg. NFC.Rui Ueyama2017-10-271-2/+2
| | | | llvm-svn: 316732
* [lld] unified COFF and ELF error handling on new Common/ErrorHandlerBob Haarman2017-10-251-1/+1
| | | | | | | | | | | | | | | | | | | 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
* [mips] Provide more detailed comment. NFCSimon Atanasyan2017-10-171-2/+8
| | | | llvm-svn: 316003
* Make it explicit that we are writing addends to target sections if REL.Rui Ueyama2017-10-131-6/+14
| | | | | | | | | | | | | | Relocations.cpp is still head-scratching. Even though relocations are processed by multiple functions, the functions are effectively one gigantic function with lots of local and global shared states, because they are really tightly coupled. It is really hard to predict whether a change to a function will or will not affect other functions behaviors. What I'm trying to do is to rewrite the code without breaking the existing tests so that the code can tolerate a more aggressive refactoring (i.e. splitting it to logically separated steps). llvm-svn: 315673
* Destructure a boolean expression and add comment.Rui Ueyama2017-10-131-2/+13
| | | | | | | "IsWrite" variable didn't make sense and was misleading because it became true even if a section is not writable. llvm-svn: 315669
* Simplify. NFCI.Rui Ueyama2017-10-131-26/+23
| | | | llvm-svn: 315659
* Slightly simplify code and add comment.Rui Ueyama2017-10-131-4/+22
| | | | | | | | | | | | This is not a mechanical transformation. Even though I believe this patch is correct, I'm not 100% sure if lld with this patch behaves exactly the same way as before on all edge cases. At least all tests still pass. I'm submitting this patch because it took almost a day to understand this function, and I don't want to lose it. llvm-svn: 315658
* Simplify a boolean expression by the De Morgan's laws.Rui Ueyama2017-10-131-1/+1
| | | | | | | I don't really understand what exactly this expression means, but at least I can mechanically transform it. llvm-svn: 315653
* Handle MIPS-specific addend rules in computeAddend().Rui Ueyama2017-10-121-36/+41
| | | | | | | | | | | | | | | | This patch merges computeAddend and computeMipsAddend. Getting an addend for a relocation is usually pretty easy: it is either in the r_addend field (if RELA) or in a target section (if REL). However, MIPS has many special rules that are different from other ELF ABIs. I don't think there were technical reasons to be different, but the reality is that they are different. It is unfortunate that we had to pass many parameters to computeAddend, but it seems unavoidable because of MIPS. llvm-svn: 315617
* Early-continue for a MIPS-specific rule.Rui Ueyama2017-10-121-26/+34
| | | | | | | | | This is an attempt to make lld's relocation handler code understandable. Since I don't fully understand what exactly this function does for all possible cases (I believe no one can), I'm not really sure if this patch is NFC, but at least no functionality change intended. All tests still pass. llvm-svn: 315612
* Remove Symbol::isPreemptible().Rui Ueyama2017-10-121-6/+6
| | | | | | Because it was a redundant accessor to Symbol's public member. llvm-svn: 315609
* Start destructuring adjustExpr function.Rui Ueyama2017-10-121-13/+22
| | | | | | | adjustExpr became a mysterious function as it does too many things. This patch is an attempt to destructure that function. llvm-svn: 315560
* Fix comment.Rui Ueyama2017-10-121-1/+1
| | | | llvm-svn: 315559
* Move more code out of scanRelocs().Rui Ueyama2017-10-121-20/+21
| | | | llvm-svn: 315558
* Make a function shorter.Rui Ueyama2017-10-121-20/+16
| | | | llvm-svn: 315555
* Remove one parameter from Target::getRelExpr.Rui Ueyama2017-10-121-2/+2
| | | | | | | | 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
* Rename P -> Pieces.Rui Ueyama2017-10-121-14/+11
| | | | | | | Conventionally, an array of SectionPieces is named Pieces. It is better to follow the convention. llvm-svn: 315543
* Define RelType to represent relocation types.Rui Ueyama2017-10-111-15/+15
| | | | | | | | | | | | | | | | | | 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
* [ELF] Try to not emit weird diagnostics on undefined symbols.Davide Italiano2017-10-111-1/+6
| | | | | | | | Fixes PR34872. Differential Revision: https://reviews.llvm.org/D38712 llvm-svn: 315487
* Rename Commands -> SectionCommands.Rui Ueyama2017-10-111-3/+3
| | | | | | | | | | "Commands" was ambiguous because in the linker script, everything is a command. We used to handle only SECTIONS commands, and at the time, it might make sense to call them the commands, but it is no longer the case. We handle not only SECTIONS but also MEMORY, PHDRS, VERSION, etc., and they are all commands. llvm-svn: 315409
* Remove BssSection::reserveSpace().Rui Ueyama2017-10-041-2/+2
| | | | | | | We no longer call reserveSpace more than once, so it can be merged with its constructor. llvm-svn: 314867
* Remove useless accessor.Rui Ueyama2017-09-181-1/+1
| | | | llvm-svn: 313586
* Keep some relocations with undefined weak symbols.Rafael Espindola2017-09-151-2/+11
| | | | | | | | | | | | | | | | | | | This fixes pr34301. As the bug points out, we want to keep some relocations with undefined weak symbols. This means that we cannot always claim that these symbols are not preemptible as we do now. Unfortunately, we cannot also just always claim that they are preemptible. Doing so would, for example, cause us to try to create a plt entry when we don't even have a dynamic symbol table. What almost works is to say that weak undefined symbols are preemptible if and only if we have a dynamic symbol table. Almost because we don't want to fail the build trying to create a copy relocation to a weak undefined. llvm-svn: 313372
* Add a helper for checking for weak undef. NFC.Rafael Espindola2017-09-131-3/+3
| | | | llvm-svn: 313188
* Remove CopyRelSecOff from SharedSymbol.Rafael Espindola2017-09-131-4/+7
| | | | | | | This reduces the size of SharedSymbol which in turn reduces the size of Symbol from 88 to 80 bytes. llvm-svn: 313154
* [MIPS] Initial support of microMIPS code linkingSimon Atanasyan2017-09-121-2/+8
| | | | | | | | | | | | | | | | 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
* [ELF] Rename variables and add comments to getISThunkSec [NFC]Peter Smith2017-09-121-13/+16
| | | | | | | | | | Replace OutputSection *Cmd to OutputSection *OS. The Commands vector was moved to OutputSection but the names of the variables were not. This patch changes the names to match. Differential Revision: https://reviews.llvm.org/D37627 llvm-svn: 313015
* [ELF] - Mention -fPIC in some error messages.George Rimar2017-08-291-1/+2
| | | | | | | | | | | This is PR32429. We did not mention -fPIC in error about producing dynamic relocation in readonly segment before. Patch changes that. Differential revision: https://reviews.llvm.org/D36874 llvm-svn: 312003
* [MIPS] Keep all code read addends in the `getImplicitAddend` functionSimon Atanasyan2017-08-241-4/+1
| | | | | | | | | | 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
* Compute isPreemtible only once.Rafael Espindola2017-08-101-1/+3
| | | | | | | | This is probably a small optimization, but the main motivation is having a way of fixing pr34053 that doesn't require a hash lookup in isPreempitible. llvm-svn: 310602
* Move File from SymbolBody to Symbol.Rafael Espindola2017-08-041-4/+4
| | | | | | | | | | | | | With this Symbol has the same size as before, but DefinedRegular goes from 72 to 64 bytes. I also find this a bit easier to read. There are fewer places initializing File for example. This has a small but measurable speed improvement on all tests (1% max). llvm-svn: 310142
* Fix which file is in an error message.Rafael Espindola2017-08-041-2/+2
| | | | | | | When reporting an invalid relocation we were blaming the destination file instead of the file with the relocation. llvm-svn: 310084
* Remove redundant flag.Rafael Espindola2017-08-041-2/+1
| | | | llvm-svn: 310079
* Use more consistent namesRafael Espindola2017-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | Reviewing another change I noticed that we use "getSymbols" to mean different things in different files. Depending on the file it can return ArrayRef<StringRef> ArrayRef<SymbolBody*> ArrayRef<Symbol*> ArrayRef<Elf_Sym> With this change it always returns an ArrayRef<SymbolBody*>. The other functions are renamed getELFsyms() and getSymbolNames(). Note that we cannot return ArrayRef<Symbol*> instead of ArreyRef<SymbolBody*> because local symbols have a SymbolBody but not a Symbol. llvm-svn: 309840
* Merge OutputSectionCommand and OutputSection.Rafael Espindola2017-07-271-18/+15
| | | | | | | | | | | | | This is a bit of a hack, but it is *so* convenient. Now that we create synthetic linker scripts when none is provided, we always have to handle paired OutputSection and OutputsectionCommand and keep a mapping from one to the other. This patch simplifies things by merging them and creating what used to be OutputSectionCommands really early. llvm-svn: 309311
* Detemplate SymbolTable.Rafael Espindola2017-07-261-1/+1
| | | | | | NFC, just makes it easier to access from non templated code. llvm-svn: 309152
* [ELF] - Change way how we handle --noinhibit-execGeorge Rimar2017-07-261-10/+16
| | | | | | | | | | | | | Previously we handled this option implicitly, only for infering unresolved symbols handling policy. ld man says: "--noinhibit-exec Retain the executable output file whenever it is still usable", and we may want to handle other cases too. Differential revision: https://reviews.llvm.org/D35793 llvm-svn: 309091
* [ELF] - Apply clang-format. NFC.George Rimar2017-07-181-29/+28
| | | | llvm-svn: 308297
* Avoid using OutputSections::Sections.Rafael Espindola2017-07-141-6/+10
| | | | | | This code runs after clearOutputSections. llvm-svn: 308066
* Pass OutputSectionCommand to getOSThunkSec. NFC.Rafael Espindola2017-07-141-4/+4
| | | | llvm-svn: 308057
* Pass OutputSectionCommand to forEachExecInputSection's callback.Rafael Espindola2017-07-141-6/+6
| | | | | | NFC, just makes the OutputSectionCommand available. llvm-svn: 308056
* Using existing variable. NFC.Rafael Espindola2017-07-051-7/+6
| | | | llvm-svn: 307211
* [ELF] Fix Windows build errorPeter Smith2017-07-051-2/+2
| | | | | | | Attempt to fix Windows buildbots From 307131 Replaced return {ET, false}; with return std::make_pair(ET, false); llvm-svn: 307137
* [ELF] Allow multiple thunks to be added for a symbol.Peter Smith2017-07-051-4/+11
| | | | | | | | | | 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
* [ELF] Introduce Thunk reuse compatibilityPeter Smith2017-07-051-1/+1
| | | | | | | | | | | | | | | | 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
* Improve error message.Rafael Espindola2017-07-041-2/+2
| | | | | | | Before we would sometimes not mention that the relocation was in a ro area before. llvm-svn: 307089
* [ELF] Define _GLOBAL_OFFSET_TABLE_ symbol relative to .gotPeter Smith2017-06-261-1/+1
| | | | | | | | | | | | | | | | | | On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - . and produce a relocation that can be processed without needing to know the value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM gcc produces R_ARM_BASE_PREL but clang produces the more general R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of the GOT or end of the GOT dependent on architecture.. If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this change will not be necessary for new objects. However there may still be old objects and versions of clang. Differential Revision: https://reviews.llvm.org/D34355 llvm-svn: 306282
* [ELF] Enable createThunks to be called more than once.Peter Smith2017-06-161-7/+19
| | | | | | | | | | | | In preparation for supporting range extension thunks we now continually call createThunks() until no more thunks are added. This requires us to record the thunks we add on each pass and only merge the new ones into the OutputSection. We also need to check if a Relocation is targeting a thunk to prevent us from infinitely creating more thunks. Differential Revision: https://reviews.llvm.org/D34034 llvm-svn: 305555
OpenPOWER on IntegriCloud