[ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for absolute relocation types in writable sections
Summary:
Our rule to create R_*_RELATIVE for absolute relocation types were
loose. D63121 made it stricter but it failed to create R_*_RELATIVE for
R_ARM_TARGET1 and R_PPC64_TOC. rLLD363236 worked around that by
reinstating the original behavior for ARM and PPC64.
This patch is an attempt to simplify the logic.
Note, in ld.bfd, R_ARM_TARGET2 --target2=abs also creates
R_ARM_RELATIVE. This seems a very uncommon scenario (moreover,
--target2=got-rel is the default), so I do not implement any logic
related to it.
Also, delete R_AARCH64_ABS32 from AArch64::getDynRel. We don't have
working ILP32 support yet. Allowing it would create an incorrect
R_AARCH64_RELATIVE.
For MIPS, the (if SymbolRel, then RelativeRel) code is to keep its
behavior unchanged.
Note, in ppc64-abs64-dyn.s, R_PPC64_TOC gets an incorrect addend because
computeAddend() doesn't compute the correct address. We seem to have the
wrong behavior for a long time. The important thing seems that a dynamic
relocation R_PPC64_TOC should not be created as the dynamic loader will
error R_PPC64_TOC is not supported.
Reviewers: atanasyan, grimar, peter.smith, ruiu, sfertile, espindola
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63383
llvm-svn: 363928
2019-06-20 22:00:08 +08:00
|
|
|
# REQUIRES: ppc
|
|
|
|
|
# RUN: llvm-mc -filetype=obj -triple=powerpc64le-unknown-linux %s -o %t.o
|
|
|
|
|
# RUN: ld.lld -shared %t.o -o %t.so
|
|
|
|
|
# RUN: llvm-readobj -r %t.so | FileCheck %s
|
|
|
|
|
|
|
|
|
|
# RUN: llvm-mc -filetype=obj -triple=powerpc64-unknown-linux %s -o %t.o
|
|
|
|
|
# RUN: ld.lld -shared %t.o -o %t.so
|
|
|
|
|
# RUN: llvm-readobj -r %t.so | FileCheck %s
|
|
|
|
|
|
|
|
|
|
## Test that we create R_PPC64_RELATIVE for R_PPC64_ADDR64 to non-preemptable
|
|
|
|
|
## symbols and R_PPC64_TOC in writable sections.
|
|
|
|
|
|
|
|
|
|
## FIXME the addend for offset 0x20000 should be TOC base+0x8000+1, not 0x80001.
|
|
|
|
|
# CHECK: .rela.dyn {
|
2019-09-29 23:26:12 +08:00
|
|
|
# CHECK-NEXT: 0x303B8 R_PPC64_RELATIVE - 0x8001
|
|
|
|
|
# CHECK-NEXT: 0x303C0 R_PPC64_RELATIVE - 0x303B9
|
|
|
|
|
# CHECK-NEXT: 0x303C8 R_PPC64_ADDR64 external 0x1
|
|
|
|
|
# CHECK-NEXT: 0x303D0 R_PPC64_ADDR64 global 0x1
|
[ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for absolute relocation types in writable sections
Summary:
Our rule to create R_*_RELATIVE for absolute relocation types were
loose. D63121 made it stricter but it failed to create R_*_RELATIVE for
R_ARM_TARGET1 and R_PPC64_TOC. rLLD363236 worked around that by
reinstating the original behavior for ARM and PPC64.
This patch is an attempt to simplify the logic.
Note, in ld.bfd, R_ARM_TARGET2 --target2=abs also creates
R_ARM_RELATIVE. This seems a very uncommon scenario (moreover,
--target2=got-rel is the default), so I do not implement any logic
related to it.
Also, delete R_AARCH64_ABS32 from AArch64::getDynRel. We don't have
working ILP32 support yet. Allowing it would create an incorrect
R_AARCH64_RELATIVE.
For MIPS, the (if SymbolRel, then RelativeRel) code is to keep its
behavior unchanged.
Note, in ppc64-abs64-dyn.s, R_PPC64_TOC gets an incorrect addend because
computeAddend() doesn't compute the correct address. We seem to have the
wrong behavior for a long time. The important thing seems that a dynamic
relocation R_PPC64_TOC should not be created as the dynamic loader will
error R_PPC64_TOC is not supported.
Reviewers: atanasyan, grimar, peter.smith, ruiu, sfertile, espindola
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63383
llvm-svn: 363928
2019-06-20 22:00:08 +08:00
|
|
|
# CHECK-NEXT: }
|
|
|
|
|
|
|
|
|
|
.data
|
|
|
|
|
.globl global
|
|
|
|
|
global:
|
|
|
|
|
local:
|
|
|
|
|
|
|
|
|
|
.quad .TOC.@tocbase + 1
|
|
|
|
|
.quad local + 1
|
|
|
|
|
.quad external + 1
|
|
|
|
|
.quad global + 1
|