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/ppc64-rel-calls.s

43 lines
922 B
ArmAsm
Raw Normal View History

[ELF2/PPC64] Resolve local-call relocations using the correct function-descriptor values Under PPC64 ELF v1 ABI, the symbols associated with each function name don't point directly to the code in the .text section (or similar), but rather to a function descriptor structure in a special data section named .opd. The elements in the .opd structure include a pointer to the actual code, and a the relevant TOC base value. Both of these are themselves set by relocations. When we have a local call, we need the relevant relocation to refer directly to the target code, not to the function-descriptor in the .opd section. Only when we have a .plt stub do we care about the address of the .opd function descriptor itself. So we make a few changes here: 1. Always write .opd first, so that its relocated data values are available for later use when writing the text sections. Record a pointer to the .opd structure, and its corresponding buffer. 2. When processing a relative branch relocation under ppc64, if the destination points into the .opd section, read the code pointer out of the function descriptor structure and use that instead. This this, I can link, and run, a dynamically-compiled "hello world" application on big-Endian PPC64/Linux (ELF v1 ABI) using lld. llvm-svn: 250122
2015-10-13 07:16:53 +08:00
# RUN: llvm-mc -filetype=obj -triple=powerpc64-unknown-linux %s -o %t
Rename ld.lld2 to ld.lld since it is the default. llvm-svn: 253437
2015-11-18 14:11:01 +08:00
# RUN: ld.lld %t -o %t2
[ELF2/PPC64] Resolve local-call relocations using the correct function-descriptor values Under PPC64 ELF v1 ABI, the symbols associated with each function name don't point directly to the code in the .text section (or similar), but rather to a function descriptor structure in a special data section named .opd. The elements in the .opd structure include a pointer to the actual code, and a the relevant TOC base value. Both of these are themselves set by relocations. When we have a local call, we need the relevant relocation to refer directly to the target code, not to the function-descriptor in the .opd section. Only when we have a .plt stub do we care about the address of the .opd function descriptor itself. So we make a few changes here: 1. Always write .opd first, so that its relocated data values are available for later use when writing the text sections. Record a pointer to the .opd structure, and its corresponding buffer. 2. When processing a relative branch relocation under ppc64, if the destination points into the .opd section, read the code pointer out of the function descriptor structure and use that instead. This this, I can link, and run, a dynamically-compiled "hello world" application on big-Endian PPC64/Linux (ELF v1 ABI) using lld. llvm-svn: 250122
2015-10-13 07:16:53 +08:00
# RUN: llvm-objdump -d %t2 | FileCheck %s
# REQUIRES: ppc
# CHECK: Disassembly of section .text:
.section ".opd","aw"
.global _start
_start:
.quad .Lfoo,.TOC.@tocbase,0
.text
.Lfoo:
li 0,1
li 3,42
sc
[ELF2] Set a target-specific VAStart for PPC64 After some additional post-commit (post-revert) discussion and research, this reverts, in part, r250205, so the ABI-recommended starting address can be used on PPC64 (as is done by other linkers). Also, this addresses the FIXME in ELF/Writer.cpp by making VAStart a target-dependent property. llvm-svn: 250378
2015-10-15 15:49:07 +08:00
# CHECK: 10010000: 38 00 00 01 li 0, 1
# CHECK: 10010004: 38 60 00 2a li 3, 42
# CHECK: 10010008: 44 00 00 02 sc
[ELF2/PPC64] Resolve local-call relocations using the correct function-descriptor values Under PPC64 ELF v1 ABI, the symbols associated with each function name don't point directly to the code in the .text section (or similar), but rather to a function descriptor structure in a special data section named .opd. The elements in the .opd structure include a pointer to the actual code, and a the relevant TOC base value. Both of these are themselves set by relocations. When we have a local call, we need the relevant relocation to refer directly to the target code, not to the function-descriptor in the .opd section. Only when we have a .plt stub do we care about the address of the .opd function descriptor itself. So we make a few changes here: 1. Always write .opd first, so that its relocated data values are available for later use when writing the text sections. Record a pointer to the .opd structure, and its corresponding buffer. 2. When processing a relative branch relocation under ppc64, if the destination points into the .opd section, read the code pointer out of the function descriptor structure and use that instead. This this, I can link, and run, a dynamically-compiled "hello world" application on big-Endian PPC64/Linux (ELF v1 ABI) using lld. llvm-svn: 250122
2015-10-13 07:16:53 +08:00
.section ".opd","aw"
.global bar
bar:
.quad .Lbar,.TOC.@tocbase,0
.text
.Lbar:
bl _start
nop
bl .Lfoo
nop
blr
# FIXME: The printing here is misleading, the branch offset here is negative.
[ELF2] Set a target-specific VAStart for PPC64 After some additional post-commit (post-revert) discussion and research, this reverts, in part, r250205, so the ABI-recommended starting address can be used on PPC64 (as is done by other linkers). Also, this addresses the FIXME in ELF/Writer.cpp by making VAStart a target-dependent property. llvm-svn: 250378
2015-10-15 15:49:07 +08:00
# CHECK: 1001000c: 4b ff ff f5 bl .+67108852
# CHECK: 10010010: 60 00 00 00 nop
# CHECK: 10010014: 4b ff ff ed bl .+67108844
# CHECK: 10010018: 60 00 00 00 nop
# CHECK: 1001001c: 4e 80 00 20 blr
[ELF2/PPC64] Resolve local-call relocations using the correct function-descriptor values Under PPC64 ELF v1 ABI, the symbols associated with each function name don't point directly to the code in the .text section (or similar), but rather to a function descriptor structure in a special data section named .opd. The elements in the .opd structure include a pointer to the actual code, and a the relevant TOC base value. Both of these are themselves set by relocations. When we have a local call, we need the relevant relocation to refer directly to the target code, not to the function-descriptor in the .opd section. Only when we have a .plt stub do we care about the address of the .opd function descriptor itself. So we make a few changes here: 1. Always write .opd first, so that its relocated data values are available for later use when writing the text sections. Record a pointer to the .opd structure, and its corresponding buffer. 2. When processing a relative branch relocation under ppc64, if the destination points into the .opd section, read the code pointer out of the function descriptor structure and use that instead. This this, I can link, and run, a dynamically-compiled "hello world" application on big-Endian PPC64/Linux (ELF v1 ABI) using lld. llvm-svn: 250122
2015-10-13 07:16:53 +08:00