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-retpoline-linkerscri...

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

69 lines
2.8 KiB
ArmAsm
Raw Normal View History

[ELF] Fix X86 & X86_64 PLT retpoline padding The PLT retpoline support for X86 and X86_64 did not include the padding when writing the header and entries. This issue was revealed when linker scripts were used, as this disables the built-in behaviour of filling the last page of executable segments with trap instructions. This particular behaviour was hiding the missing padding. Added retpoline tests with linker scripts. Differential Revision: https://reviews.llvm.org/D44682 llvm-svn: 328777
2018-03-29 22:03:01 +08:00
// REQUIRES: x86
// RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t1.o
// RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %p/Inputs/shared.s -o %t2.o
// RUN: ld.lld -shared %t2.o -o %t2.so
// RUN: echo "SECTIONS { \
// RUN: .text : { *(.text) } \
// RUN: .plt : { *(.plt) } \
// RUN: .got.plt : { *(.got.plt) } \
// RUN: .dynstr : { *(.dynstr) } \
// RUN: }" > %t.script
// RUN: ld.lld -shared %t1.o %t2.so -o %t.exe -z retpolineplt --script %t.script
// RUN: llvm-objdump -d -s %t.exe | FileCheck %s
// CHECK: Disassembly of section .plt:
[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
// CHECK-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
// CHECK-NEXT: <.plt>:
[ELF] Simplify RelRo, TLS, NOBITS section ranks and make RW PT_LOAD start with RelRo Old: PT_LOAD(.data | PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .bss) New: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .data .bss) The placement of | indicates page alignment caused by PT_GNU_RELRO. The new layout has simpler rules and saves space for many cases. Old size: roundup(.data) + roundup(.data.rel.ro) New size: roundup(.data.rel.ro + .bss.rel.ro) + .data Other advantages: * At runtime the 3 memory mappings decrease to 2. * start(PT_TLS) = start(PT_GNU_RELRO) = start(RW PT_LOAD). This simplifies binary manipulation tools. GNU strip before 2.31 discards PT_GNU_RELRO if its address is not equal to the start of its associated PT_LOAD. This has been fixed by https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f2731e0c374e5323ce4cdae2bcc7b7fe22da1a6f But with this change, we will be compatible with GNU strip before 2.31 * Before, .got.plt (non-relro by default) was placed before .got (relro by default), which made it impossible to have _GLOBAL_OFFSET_TABLE_ (start of .got.plt on x86-64) equal to the end of .got (R_GOT*_FROM_END) (https://bugs.llvm.org/show_bug.cgi?id=36555). With the new ordering, we can improve on this regard if we'd like to. Reviewers: ruiu, espindola, pcc Subscribers: emaste, arichardson, llvm-commits, joerg, jdoerfert Differential Revision: https://reviews.llvm.org/D56828 llvm-svn: 356117
2019-03-14 11:47:45 +08:00
// CHECK-NEXT: 10: ff 35 32 01 00 00 pushq 306(%rip)
// CHECK-NEXT: 16: 4c 8b 1d 33 01 00 00 movq 307(%rip), %r11
[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
// CHECK-NEXT: 1d: e8 0e 00 00 00 callq 0x30 <.plt+0x20>
[ELF] Fix X86 & X86_64 PLT retpoline padding The PLT retpoline support for X86 and X86_64 did not include the padding when writing the header and entries. This issue was revealed when linker scripts were used, as this disables the built-in behaviour of filling the last page of executable segments with trap instructions. This particular behaviour was hiding the missing padding. Added retpoline tests with linker scripts. Differential Revision: https://reviews.llvm.org/D44682 llvm-svn: 328777
2018-03-29 22:03:01 +08:00
// CHECK-NEXT: 22: f3 90 pause
// CHECK-NEXT: 24: 0f ae e8 lfence
[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
// CHECK-NEXT: 27: eb f9 jmp 0x22 <.plt+0x12>
[ELF] Fix X86 & X86_64 PLT retpoline padding The PLT retpoline support for X86 and X86_64 did not include the padding when writing the header and entries. This issue was revealed when linker scripts were used, as this disables the built-in behaviour of filling the last page of executable segments with trap instructions. This particular behaviour was hiding the missing padding. Added retpoline tests with linker scripts. Differential Revision: https://reviews.llvm.org/D44682 llvm-svn: 328777
2018-03-29 22:03:01 +08:00
// CHECK-NEXT: 29: cc int3
// CHECK-NEXT: 2a: cc int3
// CHECK-NEXT: 2b: cc int3
// CHECK-NEXT: 2c: cc int3
// CHECK-NEXT: 2d: cc int3
// CHECK-NEXT: 2e: cc int3
// CHECK-NEXT: 2f: cc int3
// CHECK-NEXT: 30: 4c 89 1c 24 movq %r11, (%rsp)
// CHECK-NEXT: 34: c3 retq
// CHECK-NEXT: 35: cc int3
// CHECK-NEXT: 36: cc int3
// CHECK-NEXT: 37: cc int3
// CHECK-NEXT: 38: cc int3
// CHECK-NEXT: 39: cc int3
// CHECK-NEXT: 3a: cc int3
// CHECK-NEXT: 3b: cc int3
// CHECK-NEXT: 3c: cc int3
// CHECK-NEXT: 3d: cc int3
// CHECK-NEXT: 3e: cc int3
// CHECK-NEXT: 3f: cc int3
[ELF] Simplify RelRo, TLS, NOBITS section ranks and make RW PT_LOAD start with RelRo Old: PT_LOAD(.data | PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .bss) New: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .data .bss) The placement of | indicates page alignment caused by PT_GNU_RELRO. The new layout has simpler rules and saves space for many cases. Old size: roundup(.data) + roundup(.data.rel.ro) New size: roundup(.data.rel.ro + .bss.rel.ro) + .data Other advantages: * At runtime the 3 memory mappings decrease to 2. * start(PT_TLS) = start(PT_GNU_RELRO) = start(RW PT_LOAD). This simplifies binary manipulation tools. GNU strip before 2.31 discards PT_GNU_RELRO if its address is not equal to the start of its associated PT_LOAD. This has been fixed by https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f2731e0c374e5323ce4cdae2bcc7b7fe22da1a6f But with this change, we will be compatible with GNU strip before 2.31 * Before, .got.plt (non-relro by default) was placed before .got (relro by default), which made it impossible to have _GLOBAL_OFFSET_TABLE_ (start of .got.plt on x86-64) equal to the end of .got (R_GOT*_FROM_END) (https://bugs.llvm.org/show_bug.cgi?id=36555). With the new ordering, we can improve on this regard if we'd like to. Reviewers: ruiu, espindola, pcc Subscribers: emaste, arichardson, llvm-commits, joerg, jdoerfert Differential Revision: https://reviews.llvm.org/D56828 llvm-svn: 356117
2019-03-14 11:47:45 +08:00
// CHECK-NEXT: 40: 4c 8b 1d 11 01 00 00 movq 273(%rip), %r11
[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
// CHECK-NEXT: 47: e8 e4 ff ff ff callq 0x30 <.plt+0x20>
// CHECK-NEXT: 4c: e9 d1 ff ff ff jmp 0x22 <.plt+0x12>
[ELF] Fix X86 & X86_64 PLT retpoline padding The PLT retpoline support for X86 and X86_64 did not include the padding when writing the header and entries. This issue was revealed when linker scripts were used, as this disables the built-in behaviour of filling the last page of executable segments with trap instructions. This particular behaviour was hiding the missing padding. Added retpoline tests with linker scripts. Differential Revision: https://reviews.llvm.org/D44682 llvm-svn: 328777
2018-03-29 22:03:01 +08:00
// CHECK-NEXT: 51: 68 00 00 00 00 pushq $0
[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
// CHECK-NEXT: 56: e9 b5 ff ff ff jmp 0x10 <.plt>
[ELF] Fix X86 & X86_64 PLT retpoline padding The PLT retpoline support for X86 and X86_64 did not include the padding when writing the header and entries. This issue was revealed when linker scripts were used, as this disables the built-in behaviour of filling the last page of executable segments with trap instructions. This particular behaviour was hiding the missing padding. Added retpoline tests with linker scripts. Differential Revision: https://reviews.llvm.org/D44682 llvm-svn: 328777
2018-03-29 22:03:01 +08:00
// CHECK-NEXT: 5b: cc int3
// CHECK-NEXT: 5c: cc int3
// CHECK-NEXT: 5d: cc int3
// CHECK-NEXT: 5e: cc int3
// CHECK-NEXT: 5f: cc int3
[ELF] Simplify RelRo, TLS, NOBITS section ranks and make RW PT_LOAD start with RelRo Old: PT_LOAD(.data | PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .bss) New: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .data .bss) The placement of | indicates page alignment caused by PT_GNU_RELRO. The new layout has simpler rules and saves space for many cases. Old size: roundup(.data) + roundup(.data.rel.ro) New size: roundup(.data.rel.ro + .bss.rel.ro) + .data Other advantages: * At runtime the 3 memory mappings decrease to 2. * start(PT_TLS) = start(PT_GNU_RELRO) = start(RW PT_LOAD). This simplifies binary manipulation tools. GNU strip before 2.31 discards PT_GNU_RELRO if its address is not equal to the start of its associated PT_LOAD. This has been fixed by https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f2731e0c374e5323ce4cdae2bcc7b7fe22da1a6f But with this change, we will be compatible with GNU strip before 2.31 * Before, .got.plt (non-relro by default) was placed before .got (relro by default), which made it impossible to have _GLOBAL_OFFSET_TABLE_ (start of .got.plt on x86-64) equal to the end of .got (R_GOT*_FROM_END) (https://bugs.llvm.org/show_bug.cgi?id=36555). With the new ordering, we can improve on this regard if we'd like to. Reviewers: ruiu, espindola, pcc Subscribers: emaste, arichardson, llvm-commits, joerg, jdoerfert Differential Revision: https://reviews.llvm.org/D56828 llvm-svn: 356117
2019-03-14 11:47:45 +08:00
// CHECK-NEXT: 60: 4c 8b 1d f9 00 00 00 movq 249(%rip), %r11
[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
// CHECK-NEXT: 67: e8 c4 ff ff ff callq 0x30 <.plt+0x20>
// CHECK-NEXT: 6c: e9 b1 ff ff ff jmp 0x22 <.plt+0x12>
[ELF] Fix X86 & X86_64 PLT retpoline padding The PLT retpoline support for X86 and X86_64 did not include the padding when writing the header and entries. This issue was revealed when linker scripts were used, as this disables the built-in behaviour of filling the last page of executable segments with trap instructions. This particular behaviour was hiding the missing padding. Added retpoline tests with linker scripts. Differential Revision: https://reviews.llvm.org/D44682 llvm-svn: 328777
2018-03-29 22:03:01 +08:00
// CHECK-NEXT: 71: 68 01 00 00 00 pushq $1
[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
// CHECK-NEXT: 76: e9 95 ff ff ff jmp 0x10 <.plt>
[ELF] Fix X86 & X86_64 PLT retpoline padding The PLT retpoline support for X86 and X86_64 did not include the padding when writing the header and entries. This issue was revealed when linker scripts were used, as this disables the built-in behaviour of filling the last page of executable segments with trap instructions. This particular behaviour was hiding the missing padding. Added retpoline tests with linker scripts. Differential Revision: https://reviews.llvm.org/D44682 llvm-svn: 328777
2018-03-29 22:03:01 +08:00
// CHECK-NEXT: 7b: cc int3
// CHECK-NEXT: 7c: cc int3
// CHECK-NEXT: 7d: cc int3
// CHECK-NEXT: 7e: cc int3
// CHECK-NEXT: 7f: cc int3
.global _start
_start:
jmp bar@PLT
jmp zed@PLT