History log of /llvm-project-15.0.7/lld/ELF/Thunks.cpp (Results 1 – 25 of 105)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


12345