maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/arm-thumb-interwork-notfunc.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

142 lines
7.0 KiB
ArmAsm
Raw Normal View History

[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
// REQUIRES: arm
[LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols. Recommit of 0b4a047bfbd11fe1f5abda8da0e2391c1918162a (reverted in c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) to incorporate subsequent fix and add a warning when LLD's interworking behavior has changed. D73474 disabled the generation of interworking thunks for branch relocations to non STT_FUNC symbols. This patch handles the case of BL and BLX instructions to non STT_FUNC symbols. LLD would normally look at the state of the caller and the callee and write a BL if the states are the same and a BLX if the states are different. This patch disables BL/BLX substitution when the destination symbol does not have type STT_FUNC. This brings our behavior in line with GNU ld which may prevent difficult to diagnose runtime errors when switching to lld. This change does change how LLD handles interworking of symbols that do not have type STT_FUNC from previous versions including the 10.0 release. This brings LLD in line with ld.bfd but there may be programs that have not been linked with ld.bfd that depend on LLD's previous behavior. We emit a warning when the behavior changes. A summary of the difference between 10.0 and 11.0 is that for symbols that do not have a type of STT_FUNC LLD will not change a BL to a BLX or vice versa. The table below enumerates the changes | relocation | STT_FUNC | bit(0) | in | 10.0- out | 11.0+ out | | R_ARM_CALL | no | 1 | BL | BLX | BL | | R_ARM_CALL | no | 0 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 1 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 0 | BL | BLX | BL | Differential Revision: https://reviews.llvm.org/D73542
2020-02-13 16:42:17 +08:00
// RUN: llvm-mc -g --triple=armv7a-linux-gnueabihf -arm-add-build-attributes -filetype=obj -o %t.o %s
[ELF][test] Delete unneeded --no-threads
2020-03-18 03:51:21 +08:00
// RUN: ld.lld %t.o -o %t 2>&1 | FileCheck %s --check-prefix=WARN
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
// RUN: llvm-objdump --no-show-raw-insn -d %t | FileCheck %s
.syntax unified
.section .arm_target, "ax", %progbits
.balign 0x1000
.arm
arm_func_with_notype:
.type arm_func_with_explicit_notype, %notype
arm_func_with_explicit_notype:
bx lr
.section .thumb_target, "ax", %progbits
.balign 4
.thumb
thumb_func_with_notype:
.type thumb_func_with_explicit_notype, %notype
thumb_func_with_explicit_notype:
bx lr
/// All the symbols that are targets of the branch relocations do not have
/// type STT_FUNC. LLD should not insert interworking thunks as non STT_FUNC
/// symbols have no state information, the ABI assumes the user has manually
[LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols. Recommit of 0b4a047bfbd11fe1f5abda8da0e2391c1918162a (reverted in c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) to incorporate subsequent fix and add a warning when LLD's interworking behavior has changed. D73474 disabled the generation of interworking thunks for branch relocations to non STT_FUNC symbols. This patch handles the case of BL and BLX instructions to non STT_FUNC symbols. LLD would normally look at the state of the caller and the callee and write a BL if the states are the same and a BLX if the states are different. This patch disables BL/BLX substitution when the destination symbol does not have type STT_FUNC. This brings our behavior in line with GNU ld which may prevent difficult to diagnose runtime errors when switching to lld. This change does change how LLD handles interworking of symbols that do not have type STT_FUNC from previous versions including the 10.0 release. This brings LLD in line with ld.bfd but there may be programs that have not been linked with ld.bfd that depend on LLD's previous behavior. We emit a warning when the behavior changes. A summary of the difference between 10.0 and 11.0 is that for symbols that do not have a type of STT_FUNC LLD will not change a BL to a BLX or vice versa. The table below enumerates the changes | relocation | STT_FUNC | bit(0) | in | 10.0- out | 11.0+ out | | R_ARM_CALL | no | 1 | BL | BLX | BL | | R_ARM_CALL | no | 0 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 1 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 0 | BL | BLX | BL | Differential Revision: https://reviews.llvm.org/D73542
2020-02-13 16:42:17 +08:00
/// done the interworking. For the BL and BLX instructions LLD should
/// preserve the original instruction instead of writing out the correct one
/// for the assumed state at the target.
/// LLD will warn for the BL and BLX cases where the behavior has changed
/// from LLD 10.0
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
.section .arm_caller, "ax", %progbits
.balign 4
.arm
.global _start
_start:
b .arm_target
b arm_func_with_notype
b arm_func_with_explicit_notype
b .thumb_target
b thumb_func_with_notype
b thumb_func_with_explicit_notype
[LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols. Recommit of 0b4a047bfbd11fe1f5abda8da0e2391c1918162a (reverted in c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) to incorporate subsequent fix and add a warning when LLD's interworking behavior has changed. D73474 disabled the generation of interworking thunks for branch relocations to non STT_FUNC symbols. This patch handles the case of BL and BLX instructions to non STT_FUNC symbols. LLD would normally look at the state of the caller and the callee and write a BL if the states are the same and a BLX if the states are different. This patch disables BL/BLX substitution when the destination symbol does not have type STT_FUNC. This brings our behavior in line with GNU ld which may prevent difficult to diagnose runtime errors when switching to lld. This change does change how LLD handles interworking of symbols that do not have type STT_FUNC from previous versions including the 10.0 release. This brings LLD in line with ld.bfd but there may be programs that have not been linked with ld.bfd that depend on LLD's previous behavior. We emit a warning when the behavior changes. A summary of the difference between 10.0 and 11.0 is that for symbols that do not have a type of STT_FUNC LLD will not change a BL to a BLX or vice versa. The table below enumerates the changes | relocation | STT_FUNC | bit(0) | in | 10.0- out | 11.0+ out | | R_ARM_CALL | no | 1 | BL | BLX | BL | | R_ARM_CALL | no | 0 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 1 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 0 | BL | BLX | BL | Differential Revision: https://reviews.llvm.org/D73542
2020-02-13 16:42:17 +08:00
bl .arm_target
bl arm_func_with_notype
bl arm_func_with_explicit_notype
bl .thumb_target
bl thumb_func_with_notype
bl thumb_func_with_explicit_notype
// WARN: {{.*}}.s:[[# @LINE+1]]:(.arm_caller+0x30): branch and link relocation: R_ARM_CALL to STT_SECTION symbol .arm_target ; interworking not performed
blx .arm_target
// WARN: {{.*}}.s:[[# @LINE+1]]:(.arm_caller+0x34): branch and link relocation: R_ARM_CALL to non STT_FUNC symbol: arm_func_with_notype interworking not performed; consider using directive '.type arm_func_with_notype, %function' to give symbol type STT_FUNC if interworking between ARM and Thumb is required
blx arm_func_with_notype
// WARN: {{.*}}.s:[[# @LINE+1]]:(.arm_caller+0x38): branch and link relocation: R_ARM_CALL to non STT_FUNC symbol: arm_func_with_explicit_notype interworking not performed; consider using directive '.type arm_func_with_explicit_notype, %function' to give symbol type STT_FUNC if interworking between ARM and Thumb is required
blx arm_func_with_explicit_notype
// WARN: {{.*}}.s:[[# @LINE+1]]:(.arm_caller+0x3C): branch and link relocation: R_ARM_CALL to STT_SECTION symbol .thumb_target ; interworking not performed
blx .thumb_target
// WARN: {{.*}}.s:[[# @LINE+1]]:(.arm_caller+0x40): branch and link relocation: R_ARM_CALL to non STT_FUNC symbol: thumb_func_with_notype interworking not performed; consider using directive '.type thumb_func_with_notype, %function' to give symbol type STT_FUNC if interworking between ARM and Thumb is required
blx thumb_func_with_notype
// WARN: {{.*}}.s:[[# @LINE+1]]:(.arm_caller+0x44): branch and link relocation: R_ARM_CALL to non STT_FUNC symbol: thumb_func_with_explicit_notype interworking not performed; consider using directive '.type thumb_func_with_explicit_notype, %function' to give symbol type STT_FUNC if interworking between ARM and Thumb is required
blx thumb_func_with_explicit_notype
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
.section .thumb_caller, "ax", %progbits
.thumb
.balign 4
[LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols. Recommit of 0b4a047bfbd11fe1f5abda8da0e2391c1918162a (reverted in c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) to incorporate subsequent fix and add a warning when LLD's interworking behavior has changed. D73474 disabled the generation of interworking thunks for branch relocations to non STT_FUNC symbols. This patch handles the case of BL and BLX instructions to non STT_FUNC symbols. LLD would normally look at the state of the caller and the callee and write a BL if the states are the same and a BLX if the states are different. This patch disables BL/BLX substitution when the destination symbol does not have type STT_FUNC. This brings our behavior in line with GNU ld which may prevent difficult to diagnose runtime errors when switching to lld. This change does change how LLD handles interworking of symbols that do not have type STT_FUNC from previous versions including the 10.0 release. This brings LLD in line with ld.bfd but there may be programs that have not been linked with ld.bfd that depend on LLD's previous behavior. We emit a warning when the behavior changes. A summary of the difference between 10.0 and 11.0 is that for symbols that do not have a type of STT_FUNC LLD will not change a BL to a BLX or vice versa. The table below enumerates the changes | relocation | STT_FUNC | bit(0) | in | 10.0- out | 11.0+ out | | R_ARM_CALL | no | 1 | BL | BLX | BL | | R_ARM_CALL | no | 0 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 1 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 0 | BL | BLX | BL | Differential Revision: https://reviews.llvm.org/D73542
2020-02-13 16:42:17 +08:00
.global thumb_caller
thumb_caller:
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
b.w .arm_target
b.w arm_func_with_notype
b.w arm_func_with_explicit_notype
b.w .thumb_target
b.w thumb_func_with_notype
b.w thumb_func_with_explicit_notype
beq.w .arm_target
beq.w arm_func_with_notype
beq.w arm_func_with_explicit_notype
beq.w .thumb_target
beq.w thumb_func_with_notype
beq.w thumb_func_with_explicit_notype
[LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols. Recommit of 0b4a047bfbd11fe1f5abda8da0e2391c1918162a (reverted in c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) to incorporate subsequent fix and add a warning when LLD's interworking behavior has changed. D73474 disabled the generation of interworking thunks for branch relocations to non STT_FUNC symbols. This patch handles the case of BL and BLX instructions to non STT_FUNC symbols. LLD would normally look at the state of the caller and the callee and write a BL if the states are the same and a BLX if the states are different. This patch disables BL/BLX substitution when the destination symbol does not have type STT_FUNC. This brings our behavior in line with GNU ld which may prevent difficult to diagnose runtime errors when switching to lld. This change does change how LLD handles interworking of symbols that do not have type STT_FUNC from previous versions including the 10.0 release. This brings LLD in line with ld.bfd but there may be programs that have not been linked with ld.bfd that depend on LLD's previous behavior. We emit a warning when the behavior changes. A summary of the difference between 10.0 and 11.0 is that for symbols that do not have a type of STT_FUNC LLD will not change a BL to a BLX or vice versa. The table below enumerates the changes | relocation | STT_FUNC | bit(0) | in | 10.0- out | 11.0+ out | | R_ARM_CALL | no | 1 | BL | BLX | BL | | R_ARM_CALL | no | 0 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 1 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 0 | BL | BLX | BL | Differential Revision: https://reviews.llvm.org/D73542
2020-02-13 16:42:17 +08:00
// WARN: {{.*}}.s:[[# @LINE+1]]:(.thumb_caller+0x30): branch and link relocation: R_ARM_THM_CALL to STT_SECTION symbol .arm_target ; interworking not performed
bl .arm_target
// WARN: {{.*}}.s:[[# @LINE+1]]:(.thumb_caller+0x34): branch and link relocation: R_ARM_THM_CALL to non STT_FUNC symbol: arm_func_with_notype interworking not performed; consider using directive '.type arm_func_with_notype, %function' to give symbol type STT_FUNC if interworking between ARM and Thumb is required
bl arm_func_with_notype
// WARN: {{.*}}.s:[[# @LINE+1]]:(.thumb_caller+0x38): branch and link relocation: R_ARM_THM_CALL to non STT_FUNC symbol: arm_func_with_explicit_notype interworking not performed; consider using directive '.type arm_func_with_explicit_notype, %function' to give symbol type STT_FUNC if interworking between ARM and Thumb is required
bl arm_func_with_explicit_notype
// WARN: {{.*}}.s:[[# @LINE+1]]:(.thumb_caller+0x3C): branch and link relocation: R_ARM_THM_CALL to STT_SECTION symbol .thumb_target ; interworking not performed
bl .thumb_target
// WARN: {{.*}}.s:[[# @LINE+1]]:(.thumb_caller+0x40): branch and link relocation: R_ARM_THM_CALL to non STT_FUNC symbol: thumb_func_with_notype interworking not performed; consider using directive '.type thumb_func_with_notype, %function' to give symbol type STT_FUNC if interworking between ARM and Thumb is required
bl thumb_func_with_notype
// {{.*}}.s:[[# @LINE+1]]:(.thumb_caller+0x44): branch and link relocation: R_ARM_THM_CALL to non STT_FUNC symbol: thumb_func_with_explicit_notype interworking not performed; consider using directive '.type thumb_func_with_explicit_notype, %function' to give symbol type STT_FUNC if interworking between ARM and Thumb is required
bl thumb_func_with_explicit_notype
blx .arm_target
blx arm_func_with_notype
blx arm_func_with_explicit_notype
blx .thumb_target
blx thumb_func_with_notype
blx thumb_func_with_explicit_notype
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK: 00021008 <_start>:
// CHECK-NEXT: 21008: b #-16
// CHECK-NEXT: 2100c: b #-20
// CHECK-NEXT: 21010: b #-24
// CHECK-NEXT: 21014: b #-24
// CHECK-NEXT: 21018: b #-28
// CHECK-NEXT: 2101c: b #-32
// CHECK-NEXT: 21020: bl #-40
// CHECK-NEXT: 21024: bl #-44
// CHECK-NEXT: 21028: bl #-48
// CHECK-NEXT: 2102c: bl #-48
// CHECK-NEXT: 21030: bl #-52
// CHECK-NEXT: 21034: bl #-56
// CHECK-NEXT: 21038: blx #-64
// CHECK-NEXT: 2103c: blx #-68
// CHECK-NEXT: 21040: blx #-72
// CHECK-NEXT: 21044: blx #-72
// CHECK-NEXT: 21048: blx #-76
// CHECK-NEXT: 2104c: blx #-80
[LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols. Recommit of 0b4a047bfbd11fe1f5abda8da0e2391c1918162a (reverted in c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) to incorporate subsequent fix and add a warning when LLD's interworking behavior has changed. D73474 disabled the generation of interworking thunks for branch relocations to non STT_FUNC symbols. This patch handles the case of BL and BLX instructions to non STT_FUNC symbols. LLD would normally look at the state of the caller and the callee and write a BL if the states are the same and a BLX if the states are different. This patch disables BL/BLX substitution when the destination symbol does not have type STT_FUNC. This brings our behavior in line with GNU ld which may prevent difficult to diagnose runtime errors when switching to lld. This change does change how LLD handles interworking of symbols that do not have type STT_FUNC from previous versions including the 10.0 release. This brings LLD in line with ld.bfd but there may be programs that have not been linked with ld.bfd that depend on LLD's previous behavior. We emit a warning when the behavior changes. A summary of the difference between 10.0 and 11.0 is that for symbols that do not have a type of STT_FUNC LLD will not change a BL to a BLX or vice versa. The table below enumerates the changes | relocation | STT_FUNC | bit(0) | in | 10.0- out | 11.0+ out | | R_ARM_CALL | no | 1 | BL | BLX | BL | | R_ARM_CALL | no | 0 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 1 | BLX | BL | BLX | | R_ARM_THM_CALL | no | 0 | BL | BLX | BL | Differential Revision: https://reviews.llvm.org/D73542
2020-02-13 16:42:17 +08:00
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK: 00021050 <thumb_caller>:
// CHECK-NEXT: 21050: b.w #-84
// CHECK-NEXT: 21054: b.w #-88
// CHECK-NEXT: 21058: b.w #-92
// CHECK-NEXT: 2105c: b.w #-92
// CHECK-NEXT: 21060: b.w #-96
// CHECK-NEXT: 21064: b.w #-100
// CHECK-NEXT: 21068: beq.w #-108
// CHECK-NEXT: 2106c: beq.w #-112
// CHECK-NEXT: 21070: beq.w #-116
// CHECK-NEXT: 21074: beq.w #-116
// CHECK-NEXT: 21078: beq.w #-120
// CHECK-NEXT: 2107c: beq.w #-124
// CHECK-NEXT: 21080: bl #-132
// CHECK-NEXT: 21084: bl #-136
// CHECK-NEXT: 21088: bl #-140
// CHECK-NEXT: 2108c: bl #-140
// CHECK-NEXT: 21090: bl #-144
// CHECK-NEXT: 21094: bl #-148
// CHECK-NEXT: 21098: blx #-156
// CHECK-NEXT: 2109c: blx #-160
// CHECK-NEXT: 210a0: blx #-164
// CHECK-NEXT: 210a4: blx #-164
// CHECK-NEXT: 210a8: blx #-168
// CHECK-NEXT: 210ac: blx #-172