summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Target.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove isTlsLocalDynamicRel and isTlsInitialExecRel.Rafael Espindola2017-05-051-33/+0
| | | | | | | | | | | | | | This feels a bit hackish, but I think it is still an improvement. The way a tls address is computed in the various architectures is not that different. For example, for local dynamic we need the base of the tls (R_TLSLD or R_TLSLD_PC), and the offset of that particular symbol (R_ABS). Given the similarity, we can just use the expressions instead of having two additional target hooks. llvm-svn: 302279
* Remove _NC suffix from ELF relocations TLSDESC_{LD64,ADD}_LO12Joel Jones2017-05-021-14/+14
| | | | llvm-svn: 301979
* Revert "Fix misnamed #include. Remove _NC suffix from ELF relocations ↵Rafael Espindola2017-05-021-14/+14
| | | | | | | | TLSDESC_{LD64,ADD}_LO12" This reverts commit r301964. It broke the build. llvm-svn: 301969
* Fix misnamed #include. Remove _NC suffix from ELF relocations ↵Joel Jones2017-05-021-14/+14
| | | | | | TLSDESC_{LD64,ADD}_LO12 llvm-svn: 301964
* [ELF] - Remove dead TLS relocations relative code for MIPS and ARMGeorge Rimar2017-04-261-16/+0
| | | | | | | | | | This code was not used because of handleARMTlsRelocation and handleMipsTlsRelocation methods that are called for these platforms instead of regular TLS code. Differential revision: https://reviews.llvm.org/D32355 llvm-svn: 301414
* [ELF] Account for R_386_TLS_LDO_32 addendShoaib Meenai2017-04-241-0/+1
| | | | | | | | | | | | This relocation type has an implicit addend. Account for it when processing the relocation. Add an offset to an existing test to ensure it gets processed correctly. Fixes PR32634. Differential Revision: https://reviews.llvm.org/D32336 llvm-svn: 301207
* [ELF] Tidy up handleARMTlsRelocation [NFC]Peter Smith2017-04-131-0/+1
| | | | | | | | | Replace addModuleReloc with AddTlsReloc so that we can use it for both the module relocation and the offset relocation. Differential Revision: https://reviews.llvm.org/D31751 llvm-svn: 300192
* [ELF] - Stop producing broken output for R_386_GOT32[X] relocations.George Rimar2017-04-081-21/+52
| | | | | | | | | | | | | | | | | | Previously we silently produced broken output for R_386_GOT32X/R_386_GOT32 relocations if they were used to compute the address of the symbol’s global offset table entry without base register when position-independent code is disabled. Situation happened because of recent ABI changes. Released ABI mentions that R_386_GOT32X can be calculated in a two different ways (so we did not follow ABI here before this patch), but draft ABI also mentions R_386_GOT32 relocation here. We should use the same calculations for both relocations. Problem is that we always calculated them as G + A - GOT (offset from end of GOT), but for case when PIC is disabled, according to i386 ABI calculation should be G + A, what should produce just an address in GOT finally. ABI: https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-draft.pdf (p36, p60). llvm-svn: 299812
* [ELF] Recommit r299635 to pad x86 executable sections with 0xccJames Henderson2017-04-071-0/+4
| | | | | | This follows r299748 which fixed a latent bug the original commit exposed. llvm-svn: 299755
* Revert r299635 because it exposed a latent bug.James Henderson2017-04-061-4/+0
| | | | llvm-svn: 299655
* [ELF] Pad x86 executable sections with 0xcc int3 instructionsJames Henderson2017-04-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Executable sections should not be padded with zero by default. On some architectures, 0x00 is the start of a valid instruction sequence, so can confuse disassembly between InputSections (and indeed the start of the next InputSection in some situations). Further, in the case of misjumps into padding, padding may start to be executed silently. On x86, the "0xcc" byte represents the int3 trap instruction. It is a single byte long so can serve well as padding. This change switches x86 (and x86_64) to use this value for padding in executable sections, if no linker script directive overrides it. It also puts the behaviour into place making it easy to change the behaviour of other targets when desired. I do not know the relevant instruction sequences for trap instructions on other targets however, so somebody should add this separately. Because the old behaviour simply wrote padding in the whole section before overwriting most of it, this change also modifies the padding algorithm to write padding only where needed. This in turn has caused a small behaviour change with regards to what values are written via Fill commands in linker scripts, bringing it into line with ld.bfd. The fill value is now written starting from the end of the previous block, which means that it always starts from the first byte of the fill, whereas the old behaviour meant that the padding sometimes started mid-way through the fill value. See the test changes for more details. Reviewed by: ruiu Differential Revision: https://reviews.llvm.org/D30886 Bugzilla: http://bugs.llvm.org/show_bug.cgi?id=32227 llvm-svn: 299635
* Remove Target::isTlsGlobalDynamicRel()Rui Ueyama2017-04-061-24/+0
| | | | | | | | Relocations are abstracted as platform-independent R_TLS_* relocations, so we don't need to check platform-specific ones to see if a relocation is TLS GD. llvm-svn: 299614
* Fix comments.Rui Ueyama2017-04-051-14/+16
| | | | llvm-svn: 299579
* Do not use relocateOne() to just write 32-bit words.Rui Ueyama2017-04-051-13/+15
| | | | llvm-svn: 299559
* Rename GotEntryAddr -> GotPltEntryAddr.Rui Ueyama2017-04-051-20/+20
| | | | | | Because they are addresses in .got.plt and not in .got. llvm-svn: 299556
* Fix PLT and GOTPLT entries for 32-bit x86 PIC.Rui Ueyama2017-04-051-12/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the code we set to our .plt entries expected that .got and .got.plt are consecutive in the virtual address space. Since %ebx points to the last entry of .got for position-independent code, it assumed that .got is accessible with small negative displacements and .got.plt are accessible with small positive displacements. That assumption was simply wrong. We don't impose any restrictions on relative layout of .got and .got.plt. As a result, the control is transferred to a bogus address from .plt at runtime, which resulted in segfaults. This patch removes that wrong assumption. We still assume that .got.plt has a fixed relative address to .got, but we no longer assume that they are consecutive in memory. With this change, a "hello world" program compiled with -fPIC works. Fixes https://bugs.llvm.org/show_bug.cgi?id=31332. Differential Revision: https://reviews.llvm.org/D31682 llvm-svn: 299553
* Remove a redundant local variable.Rui Ueyama2017-03-261-0/+2
| | | | llvm-svn: 298796
* [ELF][MIPS] Calculate relocations agains _gp_disp / __gnu_local_gp using ↵Simon Atanasyan2017-03-201-2/+5
| | | | | | | | | | | | | | | | | | | | | | | dedicated 'expressions' The patch introduces two new relocations expressions R_MIPS_GOT_GP and R_MIPS_GOT_GP_PC. The first one represents a current value of `_gp` pointer and used to calculate relocations against the `__gnu_local_gp` symbol. The second one represents the offset between the beginning of the function and the `_gp` pointer's value. There are two motivations for introducing new expressions: - It's better to keep all non-trivial relocation calculations in the single place - `getRelocTargetVA` function. - Relocations against both `_gp_disp` and `__gnu_local_gp` symbols depend on the `_gp` value. It's a magical value points to the "middle" of GOT. Now all relocations use a common `_gp` value. But in fact, under some conditions each input file might require its own `_gp` value. I'm going to implement it in the future patches. So it's better to make `MipsGotSection` responsible for calculation of the `_gp` value. llvm-svn: 298306
* Compute Config member function return values only once.Rui Ueyama2017-03-171-4/+4
| | | | | | | | | | | We had a few Config member functions that returns configuration values. For example, we had is64() which returns true if the target is 64-bit. The return values of these functions are constant and never change. This patch is to compute them only once to make it clear that they'll never change. llvm-svn: 298168
* [ELF] - Detemplate SymbolBody::getVA and SymbolBody::getPltVA. NFC.George Rimar2017-03-171-6/+6
| | | | llvm-svn: 298071
* [ELF] Handle NONE relocations on AArch64Petr Hosek2017-03-101-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D30628 llvm-svn: 297525
* Remove unnecessary template. NFC.Rafael Espindola2017-03-081-1/+1
| | | | llvm-svn: 297287
* De-template DefinedRegular.Rui Ueyama2017-02-281-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D30348 llvm-svn: 296508
* Move SymbolTable<ELFT>::Sections out of the class.Rui Ueyama2017-02-271-1/+1
| | | | | | | | | | The list of all input sections was defined in SymbolTable class for a historical reason. The list itself is not a template. However, because SymbolTable class is a template, we needed to pass around ELFT to access the list. This patch moves the list out of the class so that it doesn't need ELFT. llvm-svn: 296309
* Merge OutputSectionBase and OutputSection. NFC.Rafael Espindola2017-02-241-1/+1
| | | | | | | Now that all special sections are SyntheticSections, we only need one OutputSection class. llvm-svn: 296127
* Make InputSection a class. NFC.Rafael Espindola2017-02-231-3/+3
| | | | | | | | | With the current design an InputSection is basically anything that goes directly in a OutputSection. That includes plain input section but also synthetic sections, so this should probably not be a template. llvm-svn: 295993
* [ELF] Ignore R_*_NONE relocs when relocating non-alloc sectionsPetr Hosek2017-02-231-3/+3
| | | | | | | | | We shouldn't report an error for R_*_NONE relocs since we're emitting them when writing relocations to discarded sections. Differential Revision: https://reviews.llvm.org/D30279 llvm-svn: 295936
* Merge InputSectionData and InputSectionBase.Rafael Espindola2017-02-231-5/+5
| | | | | | | Now that InputSectionBase is not a template there is no reason to have the two. llvm-svn: 295924
* Convert InputSectionBase to a class.Rafael Espindola2017-02-231-6/+6
| | | | | | | Removing this template is not a big win by itself, but opens the way for removing more templates. llvm-svn: 295923
* [ELF][MIPS] Fix writing updated addend for R_MIPS_GOT16 relocationSimon Atanasyan2017-02-151-1/+11
| | | | | | | | | | | | If target of R_MIPS_GOT16 relocation is a local symbol its addend is high 16 bits of complete addend. To calculate a final value, the addend of this relocation is read, shifted to the left and combined with addend of paired R_MIPS_LO16 relocation. To save updated addend when the linker produces a relocatable output, we need to store high 16 bits of the addend's value. It is different from the case of writing the relocation result when the linker saves a 16-bit GOT index as-is. llvm-svn: 295159
* Sign extend remaining implicit addends for consistency.Rafael Espindola2017-02-141-2/+2
| | | | llvm-svn: 295062
* [ELF] - Do sign extend for addends of R_386_8, R_386_16 relocationsGeorge Rimar2017-02-141-2/+0
| | | | | | | | | | | | | Patch makes addends for addends of R_386_8, R_386_16 relocations be sign extended. The same we did earlier for PC ones, currenly LLD fails to link linux kernel, reporting relocation out of range because of this. Differential revision: https://reviews.llvm.org/D29714 llvm-svn: 295052
* Do not store a computable attributes to Config.Rui Ueyama2017-02-141-4/+4
| | | | llvm-svn: 295031
* Fix checks for R_386_8 and R_386_16.Rafael Espindola2017-02-131-0/+6
| | | | | | | Results created by these relocations are expected to be zero extended at runtime. llvm-svn: 294988
* Implement R_X86_64_16.Rafael Espindola2017-02-131-0/+5
| | | | | | It is used by qemu. llvm-svn: 294965
* [ELF] - Use SignExtend when reading R_386_PC8, R_386_PC16 addends.George Rimar2017-02-071-2/+4
| | | | | | | | | | | | | Previously we did not do that. For example, for R_386_PC8, 0xFF addend was not treated as 0xFFFFFFFF(-1), but was 0x000000FF. Recently added checks for R_386_PC8/R_386_PC16 failed because of calculation overflow as a result. Differential revision: https://reviews.llvm.org/D29490 llvm-svn: 294289
* Change the return type of getImplicitAddend to signed integer.Rui Ueyama2017-02-061-11/+10
| | | | | | | | | If relocations don't have addends, addends are embedded in operands. getImplicitAddend is a function to read addends. Addends can be negative numbers, so the return type of the function should be a signed integer type. llvm-svn: 294253
* [ELF] Use SyntheticSections for ThunksPeter Smith2017-02-011-25/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Thunks are now implemented by redirecting the relocation to the symbol S, to a symbol TS in a Thunk. The Thunk will transfer control to S. This has the following implications: - All the side-effects of Thunks happen within createThunks() - Thunks are no longer stored in InputSections and Symbols no longer need to hold a pointer to a Thunk - The synthetic Thunk sections need to be merged into OutputSections This implementation is almost a direct conversion of the existing Thunks with the following exceptions: - Mips LA25 Thunks are placed before the InputSection that defines the symbol that needs a Thunk. - All ARM Thunks are placed at the end of the OutputSection of the first caller to the Thunk. Range extension Thunks are not supported yet so it is optimistically assumed that all Thunks can be reused. This is a recommit of r293283 with a fixed comparison predicate as std::merge requires a strict weak ordering. Differential revision: https://reviews.llvm.org/D29327 llvm-svn: 293757
* Check R_386_{PC,}{8,16} for overflow.Rui Ueyama2017-01-311-5/+12
| | | | | | | | | It is not clear what we should do when overflow occurs for these relocations because the relocations are not an official part of the i386 psABI. But checking for overflow is generally a good to do and is consistent with other relocations such as R_X86_64_8. llvm-svn: 293683
* [ELF] - Report filename for unknown relocation error.George Rimar2017-01-311-3/+3
| | | | | | | | | | | | Our reporting for that case was just like: ld.lld: error: do not know how to handle relocation 'R_386_PC8' (23) It did not give any information about error location. Patch adds filename to error. Differential revision: https://reviews.llvm.org/D29282 llvm-svn: 293640
* Revert "[ELF][ARM] Use SyntheticSections for Thunks"Rui Ueyama2017-01-281-22/+25
| | | | | | This reverts commit r293283 because it broke MSVC build. llvm-svn: 293352
* [ELF][ARM] Use SyntheticSections for ThunksPeter Smith2017-01-271-25/+22
| | | | | | | | | | | | | | | | | | | | | | | | Thunks are now implemented by redirecting the relocation to the symbol S, to a symbol TS in a Thunk. The Thunk will transfer control to S. This has the following implications: - All the side-effects of Thunks happen within createThunks() - Thunks are no longer stored in InputSections and Symbols no longer need to hold a pointer to a Thunk - The synthetic Thunk sections need to be merged into OutputSections This implementation is almost a direct conversion of the existing Thunks with the following exceptions: - Mips LA25 Thunks are placed before the InputSection that defines the symbol that needs a Thunk. - All ARM Thunks are placed at the end of the OutputSection of the first caller to the Thunk. Range extension Thunks are not supported yet so it is optimistically assumed that all Thunks can be reused. Differential Revision: https://reviews.llvm.org/D29129 llvm-svn: 293283
* Make error messages more consistent with other messages.Rui Ueyama2017-01-251-6/+8
| | | | llvm-svn: 293095
* Remove useless cast and update a comment.Rui Ueyama2017-01-251-10/+8
| | | | llvm-svn: 293089
* [ELF] - Implemented support for R_386_PC8/R_386_8 relocations.George Rimar2017-01-251-2/+11
| | | | | | | | These relocations are used in linux kernel. Differential revision: https://reviews.llvm.org/D28094 llvm-svn: 293054
* [ELF] Add local mapping symbols to ARM PLT entriesPeter Smith2017-01-251-0/+14
| | | | | | | | | | | | | Mapping symbols allow a mapping symbol aware disassembler to correctly disassemble the PLT when the code immediately prior to the PLT is Thumb. To implement this we add a function to add symbols with local binding to be defined in SyntheticSymbols. Differential Revision: https://reviews.llvm.org/D28956 llvm-svn: 293044
* [ELF] Move createThunks() after scanRelocations()Peter Smith2017-01-181-8/+8
| | | | | | | | | | | | | | | | | | | | A necessary first step towards range extension thunks is to delay the creation of thunks until the layout of InputSections within OutputSections has been done. The change scans the relocations directly from InputSections rather than looking in the ELF File the InputSection came from. This will allow a future change to redirect the relocations to symbols defined by Thunks rather than indirect when resolving relocations. A side-effect of moving ThunkCreation is that the OutSecOff of InputSections may change in an OutputSection that contains Thunks. In well behaved programs thunks are not in OutputSections with dynamic relocations. Differential Revision: https://reviews.llvm.org/D28811 llvm-svn: 292359
* ELF: Add support for relocation type R_X86_64_8.Peter Collingbourne2017-01-181-0/+5
| | | | | | | | | Although this relocation type is not part of the x86-64 psABI, I intend to use it internally as part of the ThinLTO implementation. Differential Revision: https://reviews.llvm.org/D28841 llvm-svn: 292330
* [ELF] - Make x86 unknown relocations messages to be consistent with x64 onesGeorge Rimar2017-01-121-1/+1
| | | | | | | Addded quotes to be consistent with x64 messages, where quotes were used for nicer reporting 'Unknown' relocations initially. llvm-svn: 291752
* [ELF] - Explicitly list supported relocations for x64 target.George Rimar2017-01-121-2/+10
| | | | | | | | | The same we did for x86 earlier: list supported relocations explicitly and error out on unknown. Differential revision: https://reviews.llvm.org/D28564 llvm-svn: 291751
OpenPOWER on IntegriCloud