|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
c1f3cffe |
| 13-Jul-2022 |
Stefan Pintilie <[email protected]> |
[PowerPC][LLD] Change PPC64R2SaveStub to only use non-PC-relative code
Currently the PPC64R2SaveStub thunk will produce Power 10 code by default. This produced an issue when linking older code that
[PowerPC][LLD] Change PPC64R2SaveStub to only use non-PC-relative code
Currently the PPC64R2SaveStub thunk will produce Power 10 code by default. This produced an issue when linking older code that made use of the st_other=1 bit but was never meant to be linked or run on Power 10.
This patch makes it so that only the R_PPC64_REL24_NOTOC relocation can produce Power 10 code.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D129580
show more ...
|
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
| #
38fbedab |
| 24-Feb-2022 |
Fangrui Song <[email protected]> |
[ELF] Don't rely on Symbols.h's transitive inclusion of InputFiles.h. NFC
|
|
Revision tags: llvmorg-14.0.0-rc1 |
|
| #
27bb7990 |
| 08-Feb-2022 |
Fangrui Song <[email protected]> |
[ELF] Clean up headers. NFC
|
|
Revision tags: llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3 |
|
| #
83d59e05 |
| 20-Jan-2022 |
Alexandre Ganea <[email protected]> |
Re-land [LLD] Remove global state in lldCommon
Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers wi
Re-land [LLD] Remove global state in lldCommon
Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inherit from this structure and add their own global state, in the same way as for the existing COFFLinkerContext.
See discussion in https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html
The previous land f860fe362282ed69b9d4503a20e5d20b9a041189 caused issues in https://lab.llvm.org/buildbot/#/builders/123/builds/8383, fixed by 22ee510dac9440a74b2e5b3fe3ff13ccdbf55af3.
Differential Revision: https://reviews.llvm.org/D108850
show more ...
|
| #
e6b15394 |
| 16-Jan-2022 |
Alexandre Ganea <[email protected]> |
Revert [LLD] Remove global state in lldCommon
It seems to be causing issues on https://lab.llvm.org/buildbot/#/builders/123/builds/8383
|
| #
f860fe36 |
| 16-Jan-2022 |
Alexandre Ganea <[email protected]> |
[LLD] Remove global state in lldCommon
Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inher
[LLD] Remove global state in lldCommon
Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inherit from this structure and add their own global state, in the same way as for the existing COFFLinkerContext.
See discussion in https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html
Differential Revision: https://reviews.llvm.org/D108850
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc2 |
|
| #
bf45624b |
| 23-Dec-2021 |
Fangrui Song <[email protected]> |
[ELF][PPC32] Support .got2 in an output section description
I added `PPC32Got2Section` D62464 to support .got2 but did not implement .got2 in another output section.
PR52799 has a linker script pla
[ELF][PPC32] Support .got2 in an output section description
I added `PPC32Got2Section` D62464 to support .got2 but did not implement .got2 in another output section.
PR52799 has a linker script placing .got2 in .rodata, which causes a null pointer dereference because a MergeSyntheticSection's file is nullptr. Add the support.
show more ...
|
| #
baa3eb0d |
| 23-Dec-2021 |
Fangrui Song <[email protected]> |
[ELF] Change some non-null pointer parameters to references. NFC
|
| #
ad45df91 |
| 30-Nov-2021 |
Fangrui Song <[email protected]> |
[ELF][PPC64] Remove unneeded PPC64PCRelLongBranchThunk
This reverts the PPC64PCRelLongBranchThunk part from D86706. PPC64PCRelLongBranchThunk is the same as PPC64R12SetupStub.
Use `__gep_setup_` in
[ELF][PPC64] Remove unneeded PPC64PCRelLongBranchThunk
This reverts the PPC64PCRelLongBranchThunk part from D86706. PPC64PCRelLongBranchThunk is the same as PPC64R12SetupStub.
Use `__gep_setup_` instead of `__long_branch_pcrel_` for the stub symbol name as it more closely indicates the operation. (Note: GNU ld uses `*.long_branch.*` and `*.plt_branch.*`).
Reviewed By: NeHuang, nemanjai
Differential Revision: https://reviews.llvm.org/D114656
show more ...
|
| #
3b4dd68d |
| 26-Nov-2021 |
Fangrui Song <[email protected]> |
[ELF][PPC64] Make --power10-stubs/--no-power10-stubs proper aliases for --power10-stubs={auto,no}
This allows --power10-stubs= and --[no-]power10-stubs to override each other (they are position depe
[ELF][PPC64] Make --power10-stubs/--no-power10-stubs proper aliases for --power10-stubs={auto,no}
This allows --power10-stubs= and --[no-]power10-stubs to override each other (they are position dependent in GNU ld).
Also improve --help messages and the manpage.
Note: GNU ld's default "auto" mode uses heuristics to decide whether Power10 instructions are used. Arguably it is a design mistake of R_PPC64_REL24_NOTOC (acked by the relevant folks on a libc-alpha discussion). We don't implement "auto", so the default --power10-stubs is the same as "yes".
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
| #
6d87ca08 |
| 09-Jul-2021 |
Alex Richardson <[email protected]> |
[ELF] Refactor DynamicReloc to fix incorrect relocation addends
This patch changes the DynamicReloc class to store an enum instead of the overloaded useSymVA member to make it easier to understand a
[ELF] Refactor DynamicReloc to fix incorrect relocation addends
This patch changes the DynamicReloc class to store an enum instead of the overloaded useSymVA member to make it easier to understand and fix incorrect addends being written in some corner cases. The change is motivated by a follow-up review that checks the value of implicit Elf_Rel addends written to the output file.
This patch fixes an incorrect output when using `-z rela` for i386 files with R_386_GOT32 relocations (not that this really matters since it's an unsupported configuration). Storing the relocation expression kind also addresses an incorrect addend FIXME in ppc64-abs64-dyn.s introduced in D63383.
DynamicReloc now also has a special case for the MIPS TLS relocations (DynamicReloc::AgainstSymbolWithTargetVA) since the R_MIPS_TLS_TPREL{32/64} the symbol VA to the GOT for preemptible symbols. I'm not sure if the symbol value actually should be written for R_MIPS_TLS_TPREL32, but this patch does not attempt to change that behaviour.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D100490
show more ...
|
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
| #
f0adf3a2 |
| 04-May-2021 |
Stefan Pintilie <[email protected]> |
[PowerPC][LLD] Make sure that the correct Thunks are used.
This fixes an issue where mixed TOC / NOTOC calls can call the incorrect thunks if a previous thunk already exists. The issue appears when
[PowerPC][LLD] Make sure that the correct Thunks are used.
This fixes an issue where mixed TOC / NOTOC calls can call the incorrect thunks if a previous thunk already exists. The issue appears when a TOC funciton calls a NOTOC callee and then a different NOTOC function calls the same NOTOC callee. In this case the linker would sometimes incorrectly call the same thunk for both cases.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D101837
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3 |
|
| #
36192790 |
| 04-Mar-2021 |
Albion Fung <[email protected]> |
[PowerPC][PC Rel] Implement option to omit Power10 instructions from stubs
Implemented the option to omit Power10 instructions from save stubs via the option --no-power10-stubs or --power10-stubs=no
[PowerPC][PC Rel] Implement option to omit Power10 instructions from stubs
Implemented the option to omit Power10 instructions from save stubs via the option --no-power10-stubs or --power10-stubs=no on lld. --power10-stubs= will override the other option. --power10-stubs=auto also exists to use the default behaviour (ie allow Power10 instructions in stubs).
Differential Revision: https://reviews.llvm.org/D94627
show more ...
|
| #
e35929e0 |
| 26-Feb-2021 |
Peter Smith <[email protected]> |
[LLD][ELF][ARM] Refactor inBranchRange to use addend for PC Bias
In AArch32 ARM, the PC reads two instructions ahead of the currently executiing instruction. This evaluates to 8 in ARM state and 4 i
[LLD][ELF][ARM] Refactor inBranchRange to use addend for PC Bias
In AArch32 ARM, the PC reads two instructions ahead of the currently executiing instruction. This evaluates to 8 in ARM state and 4 in Thumb state. Branch instructions on AArch32 compensate for this by subtracting the PC bias from the addend. For a branch to symbol this will result in an addend of -8 in ARM state and -4 in Thumb state.
The existing ARM Target::inBranchRange function accounted for this implict addend within the function meaning that if the addend were to be taken into account by the caller then it would be double counted. This complicates the interface for all Targets as callers wanting to account for addends had to account for the ARM PC-bias.
In certain situations such as: https://github.com/ClangBuiltLinux/linux/issues/1305 the PC-bias compensation code didn't match up. In particular normalizeExistingThunk() didn't put the PC-bias back in as Arm thunks did not store the addend.
The simplest fix for the problem is to add the PC bias in normalizeExistingThunk when restoring the addend. However I think it is worth refactoring the Arm inBranchRange implementation so that fewer calls to getPCBias are needed for other Targets. I wasn't able to remove getPCBias completely but hopefully the Relocations.cpp code is simpler now.
In principle a test could be written to replicate the linux kernel build failure but I wasn't able to reproduce with a small example that I could build up from scratch.
Fixes https://github.com/ClangBuiltLinux/linux/issues/1305
Differential Revision: https://reviews.llvm.org/D97550
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4 |
|
| #
d2241752 |
| 22-Sep-2020 |
Stefan Pintilie <[email protected]> |
[PowerPC][LLD] Extend R2 save stub to support offsets of more than 26 bits
The R2 save stub will now support offsets up to 64 bits.
There are three cases that will be used. 1) The offset fits in 26
[PowerPC][LLD] Extend R2 save stub to support offsets of more than 26 bits
The R2 save stub will now support offsets up to 64 bits.
There are three cases that will be used. 1) The offset fits in 26 bits. ``` b <26 bit offset> ``` 2) The offset does not fit in 26 bits but fits in 34 bits. ``` paddi r12, 0, <34 bit offset>, 1 mtctr r12 bctr ``` 3) The offset does not fit in 34 bits. Since this is an R2 save stub we can use the TOC in R2. We are not loading the offset but the actual address we want to branch to. ``` addis r12, r2, <address in TOC lo> ld r12 <address in TOC hi>(r12) mtctr r12 bctr ```
In case 1) the stub is only 8 bytes while in cases 2) and 3) the stub will be 20 bytes.
Reviewed By: MaskRay, sfertile, NeHuang
Differential Revision: https://reviews.llvm.org/D87916
show more ...
|
| #
967e29ff |
| 22-Sep-2020 |
Victor Huang <[email protected]> |
[LLD][PowerPC][test] Update thunk range error report for PPC64PCRelLongBranchThunk
Update the thunk range error report for PPC64PCRelLongBranchThunk and add a range error test case for PPC64R12Setup
[LLD][PowerPC][test] Update thunk range error report for PPC64PCRelLongBranchThunk
Update the thunk range error report for PPC64PCRelLongBranchThunk and add a range error test case for PPC64R12SetupStub.
Differential Revision: https://reviews.llvm.org/D87381
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc3 |
|
| #
94921e9f |
| 11-Sep-2020 |
Fangrui Song <[email protected]> |
[ELF] Define a reportRangeError() overload for thunks and tidy up recent PPC64 thunk range errors
Prefer `errorOrWarn` to `fatal` for recoverable errors and graceful degradation when --noinhibit-exe
[ELF] Define a reportRangeError() overload for thunks and tidy up recent PPC64 thunk range errors
Prefer `errorOrWarn` to `fatal` for recoverable errors and graceful degradation when --noinhibit-exec is specified.
Mention the destination symbol, otherwise the diagnostic is not really actionable. Two errors are not tested but the patch does not intend to add the coverage.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D87486
show more ...
|
| #
bfc76366 |
| 28-Aug-2020 |
Victor Huang <[email protected]> |
[LLD][PowerPC] Add a pc-rel based long branch thunk
In this patch, a pc-rel based long branch thunk is added for the local call protocol that caller and callee does not use TOC.
Reviewed By: sferti
[LLD][PowerPC] Add a pc-rel based long branch thunk
In this patch, a pc-rel based long branch thunk is added for the local call protocol that caller and callee does not use TOC.
Reviewed By: sfertile, nemanjai
Differential Revision: https://reviews.llvm.org/D86706
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc2 |
|
| #
7b391245 |
| 17-Aug-2020 |
Victor Huang <[email protected]> |
[PowerPC] Fix thunk alignment issue when using pc-rel instruction
Thunk alignment is added in thie patch when using pc-rel instructions to avoid crossing the 64 byte boundary.
Patched by: nemanjai,
[PowerPC] Fix thunk alignment issue when using pc-rel instruction
Thunk alignment is added in thie patch when using pc-rel instructions to avoid crossing the 64 byte boundary.
Patched by: nemanjai, NeHuang Reviewed By: sfertile, MaskRay
Differential Revision: https://reviews.llvm.org/D85973
show more ...
|
| #
6c64f05b |
| 07-Aug-2020 |
Victor Huang <[email protected]> |
[PowerPC] Add compatibility check for PPC PLT stubs
Compatibility checks for PPC64PltCallStub and PPC64PCRelPLTStub are added in this patch to prevent the usage of incompatible thunk/stub.
Reviewed
[PowerPC] Add compatibility check for PPC PLT stubs
Compatibility checks for PPC64PltCallStub and PPC64PCRelPLTStub are added in this patch to prevent the usage of incompatible thunk/stub.
Reviewed By: sfertile, nemanjai, stefanp
Differential Revision: https://reviews.llvm.org/D85459
show more ...
|
| #
8dbea478 |
| 29-Jul-2020 |
Victor Huang <[email protected]> |
[PowerPC] Support for R_PPC64_REL24_NOTOC calls where the caller has no TOC and the callee is not DSO local
This patch supports the situation where caller does not have a valid TOC and calls using t
[PowerPC] Support for R_PPC64_REL24_NOTOC calls where the caller has no TOC and the callee is not DSO local
This patch supports the situation where caller does not have a valid TOC and calls using the R_PPC64_REL24_NOTOC relocation and the callee is not DSO local. In this case the call cannot be made directly since the callee may or may not require a valid TOC pointer. As a result this situation require a PC-relative plt stub to set up r12.
Reviewed By: sfertile, MaskRay, stefanp
Differential Revision: https://reviews.llvm.org/D83669
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc1 |
|
| #
91cce1a2 |
| 20-Jul-2020 |
Victor Huang <[email protected]> |
[PowerPC] Implement R_PPC64_REL24_NOTOC local calls, callee requires a TOC
The PC Relative code now allows for calls that are marked with the relocation R_PPC64_REL24_NOTOC. This indicates that the
[PowerPC] Implement R_PPC64_REL24_NOTOC local calls, callee requires a TOC
The PC Relative code now allows for calls that are marked with the relocation R_PPC64_REL24_NOTOC. This indicates that the caller does not have a valid TOC pointer in R2 and does not require R2 to be restored after the call.
This patch is added to support local calls to callees that require a TOC
Reviewed By: sfertile, MaskRay, nemanjai, stefanp
Differential Revision: https://reviews.llvm.org/D83504
show more ...
|
|
Revision tags: llvmorg-12-init |
|
| #
beb52b12 |
| 09-Jul-2020 |
Stefan Pintilie <[email protected]> |
[PowerPC] Support PCRelative Callees for R_PPC64_REL24 Relocation
The R_PPC64_REL24 is used in function calls when the caller requires a valid TOC pointer. If the callee shares the same TOC or does
[PowerPC] Support PCRelative Callees for R_PPC64_REL24 Relocation
The R_PPC64_REL24 is used in function calls when the caller requires a valid TOC pointer. If the callee shares the same TOC or does not clobber the TOC pointer then a direct call can be made. If the callee does not share the TOC a thunk must be added to save the TOC pointer for the caller.
Up until PC Relative was introduced all local calls on medium and large code models were assumed to share a TOC. This is no longer the case because if the caller requires a TOC and the callee is PC Relative then the callee can clobber the TOC even if it is in the same DSO.
This patch is to add support for a TOC caller calling a PC Relative callee that clobbers the TOC.
Reviewed By: sfertile, MaskRay
Differential Revision: https://reviews.llvm.org/D82950
show more ...
|
|
Revision tags: llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
| #
723b5a17 |
| 23-Jun-2020 |
Leonard Chan <[email protected]> |
[lld][ELF][AArch64] Handle R_AARCH64_PLT32 relocation
This is the followup to D77647 which implements handling for the new R_AARCH64_PLT32 relocation type in lld. This relocation would benefit the P
[lld][ELF][AArch64] Handle R_AARCH64_PLT32 relocation
This is the followup to D77647 which implements handling for the new R_AARCH64_PLT32 relocation type in lld. This relocation would benefit the PIC-friendly vtables feature described in D72959.
Differential Revision: https://reviews.llvm.org/D81184
show more ...
|
|
Revision tags: llvmorg-10.0.1-rc1 |
|
| #
07837b8f |
| 15-May-2020 |
Fangrui Song <[email protected]> |
[ELF] Use namespace qualifiers (lld:: or elf::) instead of `namespace lld { namespace elf {`
Similar to D74882. This reverts much code from commit bd8cfe65f5fee4ad573adc2172359c9552e8cdc0 (D68323) a
[ELF] Use namespace qualifiers (lld:: or elf::) instead of `namespace lld { namespace elf {`
Similar to D74882. This reverts much code from commit bd8cfe65f5fee4ad573adc2172359c9552e8cdc0 (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
show more ...
|