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/x86-64-gotpc-relax.s

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

100 lines
2.5 KiB
ArmAsm
Raw Normal View History

[ELF] - Implemented optimization for R_X86_64_GOTPCREL relocation. System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, B.2 "B.2 Optimize GOTPCRELX Relocations") introduces possible relaxations for R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX. That patch implements the next relaxation: mov foo@GOTPCREL(%rip), %reg => lea foo(%rip), %reg and also opens door for implementing all other ones. Implementation was suggested by Rafael Ávila de Espíndola with few additions and testcases by myself. Differential revision: http://reviews.llvm.org/D15779 llvm-svn: 270705
2016-05-25 22:31:37 +08:00
# REQUIRES: x86
# RUN: llvm-mc -filetype=obj -relax-relocations -triple=x86_64-unknown-linux %s -o %t.o
# RUN: ld.lld %t.o -o %t1
# RUN: llvm-readobj -r %t1 | FileCheck --check-prefix=RELOC %s
# RUN: llvm-objdump -d %t1 | FileCheck --check-prefix=DISASM %s
## There is no relocations.
# RELOC: Relocations [
# RELOC: ]
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64 Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
2019-09-16 15:05:34 +08:00
# 0x201173 + 7 - 10 = 0x201170
# 0x20117a + 7 - 17 = 0x201170
# 0x201181 + 7 - 23 = 0x201171
# 0x201188 + 7 - 30 = 0x201171
[ELF] - Implemented optimization for R_X86_64_GOTPCREL relocation. System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, B.2 "B.2 Optimize GOTPCRELX Relocations") introduces possible relaxations for R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX. That patch implements the next relaxation: mov foo@GOTPCREL(%rip), %reg => lea foo(%rip), %reg and also opens door for implementing all other ones. Implementation was suggested by Rafael Ávila de Espíndola with few additions and testcases by myself. Differential revision: http://reviews.llvm.org/D15779 llvm-svn: 270705
2016-05-25 22:31:37 +08:00
# DISASM: Disassembly of section .text:
[llvm-objdump] Print newlines before and after "Disassembly of section ...:" This improves readability and the behavior is consistent with GNU objdump. The new test test/tools/llvm-objdump/X86/disassemble-section-name.s checks we print newlines before and after "Disassembly of section ...:" Differential Revision: https://reviews.llvm.org/D61127 llvm-svn: 359668
2019-05-01 18:40:48 +08:00
# DISASM-EMPTY:
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
# DISASM-NEXT: <foo>:
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64 Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
2019-09-16 15:05:34 +08:00
# DISASM-NEXT: 201170: 90 nop
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
# DISASM: <hid>:
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64 Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
2019-09-16 15:05:34 +08:00
# DISASM-NEXT: 201171: 90 nop
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
# DISASM: <ifunc>:
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64 Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
2019-09-16 15:05:34 +08:00
# DISASM-NEXT: 201172: c3 retq
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
# DISASM: <_start>:
Make test more realistic. It doesn't make mach sense to fetch less than 64 bits from a got entry. llvm-svn: 271116
2016-05-28 23:38:13 +08:00
# DISASM-NEXT: leaq -10(%rip), %rax
# DISASM-NEXT: leaq -17(%rip), %rax
# DISASM-NEXT: leaq -23(%rip), %rax
# DISASM-NEXT: leaq -30(%rip), %rax
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64 Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
2019-09-16 15:05:34 +08:00
# DISASM-NEXT: movq 4234(%rip), %rax
# DISASM-NEXT: movq 4227(%rip), %rax
Make test more realistic. It doesn't make mach sense to fetch less than 64 bits from a got entry. llvm-svn: 271116
2016-05-28 23:38:13 +08:00
# DISASM-NEXT: leaq -52(%rip), %rax
# DISASM-NEXT: leaq -59(%rip), %rax
# DISASM-NEXT: leaq -65(%rip), %rax
# DISASM-NEXT: leaq -72(%rip), %rax
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64 Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
2019-09-16 15:05:34 +08:00
# DISASM-NEXT: movq 4192(%rip), %rax
# DISASM-NEXT: movq 4185(%rip), %rax
[X86InstPrinter] Change printPCRelImm to print the target address in hexadecimal form ``` // llvm-objdump -d output (before) 400000: e8 0b 00 00 00 callq 11 400005: e8 0b 00 00 00 callq 11 // llvm-objdump -d output (after) 400000: e8 0b 00 00 00 callq 0x400010 400005: e8 0b 00 00 00 callq 0x400015 // GNU objdump -d. The lack of 0x is not ideal because the result cannot be re-assembled 400000: e8 0b 00 00 00 callq 400010 400005: e8 0b 00 00 00 callq 400015 ``` In llvm-objdump, we pass the address of the next MCInst. Ideally we should just thread the address of the current address, unfortunately we cannot call X86MCCodeEmitter::encodeInstruction (X86MCCodeEmitter requires MCInstrInfo and MCContext) to get the length of the MCInst. MCInstPrinter::printInst has other callers (e.g llvm-mc -filetype=asm, llvm-mca) which set Address to 0. They leave MCInstPrinter::PrintBranchImmAsAddress as false and this change is a no-op for them. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D76580
2020-03-23 06:03:10 +08:00
# DISASM-NEXT: callq 0x201170 <foo>
# DISASM-NEXT: callq 0x201170 <foo>
# DISASM-NEXT: callq 0x201171 <hid>
# DISASM-NEXT: callq 0x201171 <hid>
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64 Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
2019-09-16 15:05:34 +08:00
# DISASM-NEXT: callq *4155(%rip)
# DISASM-NEXT: callq *4149(%rip)
[X86InstPrinter] Change printPCRelImm to print the target address in hexadecimal form ``` // llvm-objdump -d output (before) 400000: e8 0b 00 00 00 callq 11 400005: e8 0b 00 00 00 callq 11 // llvm-objdump -d output (after) 400000: e8 0b 00 00 00 callq 0x400010 400005: e8 0b 00 00 00 callq 0x400015 // GNU objdump -d. The lack of 0x is not ideal because the result cannot be re-assembled 400000: e8 0b 00 00 00 callq 400010 400005: e8 0b 00 00 00 callq 400015 ``` In llvm-objdump, we pass the address of the next MCInst. Ideally we should just thread the address of the current address, unfortunately we cannot call X86MCCodeEmitter::encodeInstruction (X86MCCodeEmitter requires MCInstrInfo and MCContext) to get the length of the MCInst. MCInstPrinter::printInst has other callers (e.g llvm-mc -filetype=asm, llvm-mca) which set Address to 0. They leave MCInstPrinter::PrintBranchImmAsAddress as false and this change is a no-op for them. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D76580
2020-03-23 06:03:10 +08:00
# DISASM-NEXT: jmp 0x201170 <foo>
Make test more realistic. It doesn't make mach sense to fetch less than 64 bits from a got entry. llvm-svn: 271116
2016-05-28 23:38:13 +08:00
# DISASM-NEXT: nop
[X86InstPrinter] Change printPCRelImm to print the target address in hexadecimal form ``` // llvm-objdump -d output (before) 400000: e8 0b 00 00 00 callq 11 400005: e8 0b 00 00 00 callq 11 // llvm-objdump -d output (after) 400000: e8 0b 00 00 00 callq 0x400010 400005: e8 0b 00 00 00 callq 0x400015 // GNU objdump -d. The lack of 0x is not ideal because the result cannot be re-assembled 400000: e8 0b 00 00 00 callq 400010 400005: e8 0b 00 00 00 callq 400015 ``` In llvm-objdump, we pass the address of the next MCInst. Ideally we should just thread the address of the current address, unfortunately we cannot call X86MCCodeEmitter::encodeInstruction (X86MCCodeEmitter requires MCInstrInfo and MCContext) to get the length of the MCInst. MCInstPrinter::printInst has other callers (e.g llvm-mc -filetype=asm, llvm-mca) which set Address to 0. They leave MCInstPrinter::PrintBranchImmAsAddress as false and this change is a no-op for them. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D76580
2020-03-23 06:03:10 +08:00
# DISASM-NEXT: jmp 0x201170 <foo>
Make test more realistic. It doesn't make mach sense to fetch less than 64 bits from a got entry. llvm-svn: 271116
2016-05-28 23:38:13 +08:00
# DISASM-NEXT: nop
[X86InstPrinter] Change printPCRelImm to print the target address in hexadecimal form ``` // llvm-objdump -d output (before) 400000: e8 0b 00 00 00 callq 11 400005: e8 0b 00 00 00 callq 11 // llvm-objdump -d output (after) 400000: e8 0b 00 00 00 callq 0x400010 400005: e8 0b 00 00 00 callq 0x400015 // GNU objdump -d. The lack of 0x is not ideal because the result cannot be re-assembled 400000: e8 0b 00 00 00 callq 400010 400005: e8 0b 00 00 00 callq 400015 ``` In llvm-objdump, we pass the address of the next MCInst. Ideally we should just thread the address of the current address, unfortunately we cannot call X86MCCodeEmitter::encodeInstruction (X86MCCodeEmitter requires MCInstrInfo and MCContext) to get the length of the MCInst. MCInstPrinter::printInst has other callers (e.g llvm-mc -filetype=asm, llvm-mca) which set Address to 0. They leave MCInstPrinter::PrintBranchImmAsAddress as false and this change is a no-op for them. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D76580
2020-03-23 06:03:10 +08:00
# DISASM-NEXT: jmp 0x201171 <hid>
Make test more realistic. It doesn't make mach sense to fetch less than 64 bits from a got entry. llvm-svn: 271116
2016-05-28 23:38:13 +08:00
# DISASM-NEXT: nop
[X86InstPrinter] Change printPCRelImm to print the target address in hexadecimal form ``` // llvm-objdump -d output (before) 400000: e8 0b 00 00 00 callq 11 400005: e8 0b 00 00 00 callq 11 // llvm-objdump -d output (after) 400000: e8 0b 00 00 00 callq 0x400010 400005: e8 0b 00 00 00 callq 0x400015 // GNU objdump -d. The lack of 0x is not ideal because the result cannot be re-assembled 400000: e8 0b 00 00 00 callq 400010 400005: e8 0b 00 00 00 callq 400015 ``` In llvm-objdump, we pass the address of the next MCInst. Ideally we should just thread the address of the current address, unfortunately we cannot call X86MCCodeEmitter::encodeInstruction (X86MCCodeEmitter requires MCInstrInfo and MCContext) to get the length of the MCInst. MCInstPrinter::printInst has other callers (e.g llvm-mc -filetype=asm, llvm-mca) which set Address to 0. They leave MCInstPrinter::PrintBranchImmAsAddress as false and this change is a no-op for them. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D76580
2020-03-23 06:03:10 +08:00
# DISASM-NEXT: jmp 0x201171 <hid>
Make test more realistic. It doesn't make mach sense to fetch less than 64 bits from a got entry. llvm-svn: 271116
2016-05-28 23:38:13 +08:00
# DISASM-NEXT: nop
[ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64 Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
2019-09-16 15:05:34 +08:00
# DISASM-NEXT: jmpq *4119(%rip)
# DISASM-NEXT: jmpq *4113(%rip)
[ELF] - Implemented optimization for R_X86_64_GOTPCREL relocation. System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, B.2 "B.2 Optimize GOTPCRELX Relocations") introduces possible relaxations for R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX. That patch implements the next relaxation: mov foo@GOTPCREL(%rip), %reg => lea foo(%rip), %reg and also opens door for implementing all other ones. Implementation was suggested by Rafael Ávila de Espíndola with few additions and testcases by myself. Differential revision: http://reviews.llvm.org/D15779 llvm-svn: 270705
2016-05-25 22:31:37 +08:00
.text
.globl foo
.type foo, @function
foo:
nop
.globl hid
.hidden hid
.type hid, @function
hid:
nop
.text
.type ifunc STT_GNU_IFUNC
.globl ifunc
.type ifunc, @function
ifunc:
ret
.globl _start
.type _start, @function
_start:
movq foo@GOTPCREL(%rip), %rax
movq foo@GOTPCREL(%rip), %rax
movq hid@GOTPCREL(%rip), %rax
movq hid@GOTPCREL(%rip), %rax
movq ifunc@GOTPCREL(%rip), %rax
movq ifunc@GOTPCREL(%rip), %rax
Make test more realistic. It doesn't make mach sense to fetch less than 64 bits from a got entry. llvm-svn: 271116
2016-05-28 23:38:13 +08:00
movq foo@GOTPCREL(%rip), %rax
movq foo@GOTPCREL(%rip), %rax
movq hid@GOTPCREL(%rip), %rax
movq hid@GOTPCREL(%rip), %rax
movq ifunc@GOTPCREL(%rip), %rax
movq ifunc@GOTPCREL(%rip), %rax
[ELF] - Implemented optimization for R_X86_64_GOTPCREL relocation. System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, B.2 "B.2 Optimize GOTPCRELX Relocations") introduces possible relaxations for R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX. That patch implements the next relaxation: mov foo@GOTPCREL(%rip), %reg => lea foo(%rip), %reg and also opens door for implementing all other ones. Implementation was suggested by Rafael Ávila de Espíndola with few additions and testcases by myself. Differential revision: http://reviews.llvm.org/D15779 llvm-svn: 270705
2016-05-25 22:31:37 +08:00
call *foo@GOTPCREL(%rip)
[ELF] - Added support for jmp/call relaxations when R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX are used. D15779 introduced basic approach to support new relaxations. This patch implements relaxations for jmp and call instructions, described in System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, B.2 "B.2 Optimize GOTPCRELX Relocations") Differential revision: http://reviews.llvm.org/D20622 llvm-svn: 270721
2016-05-26 00:51:08 +08:00
call *foo@GOTPCREL(%rip)
call *hid@GOTPCREL(%rip)
call *hid@GOTPCREL(%rip)
call *ifunc@GOTPCREL(%rip)
call *ifunc@GOTPCREL(%rip)
jmp *foo@GOTPCREL(%rip)
jmp *foo@GOTPCREL(%rip)
jmp *hid@GOTPCREL(%rip)
jmp *hid@GOTPCREL(%rip)
jmp *ifunc@GOTPCREL(%rip)
[ELF] - Implemented optimization for R_X86_64_GOTPCREL relocation. System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, B.2 "B.2 Optimize GOTPCRELX Relocations") introduces possible relaxations for R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX. That patch implements the next relaxation: mov foo@GOTPCREL(%rip), %reg => lea foo(%rip), %reg and also opens door for implementing all other ones. Implementation was suggested by Rafael Ávila de Espíndola with few additions and testcases by myself. Differential revision: http://reviews.llvm.org/D15779 llvm-svn: 270705
2016-05-25 22:31:37 +08:00
jmp *ifunc@GOTPCREL(%rip)