2016-06-07 17:31:52 +08:00
|
|
|
// REQUIRES: arm
|
|
|
|
// RUN: llvm-mc -filetype=obj -triple=armv7a-none-linux %s -o %t.o
|
|
|
|
|
2020-04-18 23:06:37 +08:00
|
|
|
/// Creates a R_ARM_ABS32 relocation against foo and bar, bar has hidden
|
|
|
|
/// visibility so we expect a R_ARM_RELATIVE
|
2016-06-07 17:31:52 +08:00
|
|
|
.syntax unified
|
|
|
|
.globl foo
|
|
|
|
foo:
|
|
|
|
.globl bar
|
|
|
|
.hidden bar
|
|
|
|
bar:
|
|
|
|
|
|
|
|
.data
|
|
|
|
.word foo
|
|
|
|
.word bar
|
|
|
|
|
2020-04-18 23:06:37 +08:00
|
|
|
/// In PIC mode, if R_ARM_TARGET1 represents R_ARM_ABS32 (the default), an
|
|
|
|
/// R_ARM_TARGET1 to a non-preemptable symbol also creates an R_ARM_RELATIVE in
|
|
|
|
/// a writable section.
|
[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
|
|
|
.word bar(target1)
|
|
|
|
|
2016-06-07 17:31:52 +08:00
|
|
|
// RUN: ld.lld -shared -o %t.so %t.o
|
2019-05-01 13:49:01 +08:00
|
|
|
// RUN: llvm-readobj --symbols --dyn-relocations %t.so | FileCheck %s
|
[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
|
|
|
// RUN: llvm-readelf -x .data %t.so | FileCheck --check-prefix=HEX %s
|
2016-06-07 17:31:52 +08:00
|
|
|
|
|
|
|
// CHECK: Dynamic Relocations {
|
2020-04-18 23:06:37 +08:00
|
|
|
// CHECK-NEXT: 0x30204 R_ARM_RELATIVE
|
|
|
|
// CHECK-NEXT: 0x30208 R_ARM_RELATIVE
|
|
|
|
// CHECK-NEXT: 0x30200 R_ARM_ABS32 foo 0x0
|
2016-06-07 17:31:52 +08:00
|
|
|
// CHECK-NEXT: }
|
|
|
|
|
|
|
|
// CHECK: Symbols [
|
|
|
|
// CHECK: Symbol {
|
|
|
|
// CHECK: Name: bar
|
2020-04-18 23:06:37 +08:00
|
|
|
// CHECK-NEXT: Value: 0x101A8
|
2016-06-07 17:31:52 +08:00
|
|
|
|
|
|
|
// CHECK: Symbol {
|
|
|
|
// CHECK: Name: foo
|
2020-04-18 23:06:37 +08:00
|
|
|
// CHECK-NEXT: Value: 0x101A8
|
[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
|
|
|
|
2020-04-18 23:06:37 +08:00
|
|
|
// HEX: 0x00030200 00000000 a8010100 a8010100
|