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-icf-exidx.s

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

35 lines
862 B
ArmAsm
Raw Normal View History

[ELF] Mark ARM Exceptions that refer to folded code as not live ARM Exception Index Table sections .ARM.exidx have an implicit dependency on code sections via SHF_LINK_ORDER. When code sections are folded by ICF we must mark the unique .ARM.exidx table that describes it as not live to prevent an illegal entry in the exception table. Note that we do not try and follow the relocations from the .ARM.exidx section to the .ARM.extab sections to mark these as not live. Leaving these sections is not a correctness problem. In theory these could be removed via an application of garbage collection. Fixes https://bugs.llvm.org/show_bug.cgi?id=32614 Differential Revision: https://reviews.llvm.org/D31932 llvm-svn: 300182
2017-04-13 16:52:58 +08:00
// REQUIRES: arm
// RUN: llvm-mc -filetype=obj -triple=armv7a-none-linux-gnueabi %s -o %t
// RUN: ld.lld %t -o %t2 --icf=all
[test] lld/test/: change llvm-objdump single-dash long options to double-dash options
2020-03-16 08:47:44 +08:00
// RUN: llvm-objdump -s -d --triple=armv7a-none-linux-gnueabi %t2 | FileCheck %s
[ELF] Mark ARM Exceptions that refer to folded code as not live ARM Exception Index Table sections .ARM.exidx have an implicit dependency on code sections via SHF_LINK_ORDER. When code sections are folded by ICF we must mark the unique .ARM.exidx table that describes it as not live to prevent an illegal entry in the exception table. Note that we do not try and follow the relocations from the .ARM.exidx section to the .ARM.extab sections to mark these as not live. Leaving these sections is not a correctness problem. In theory these could be removed via an application of garbage collection. Fixes https://bugs.llvm.org/show_bug.cgi?id=32614 Differential Revision: https://reviews.llvm.org/D31932 llvm-svn: 300182
2017-04-13 16:52:58 +08:00
.syntax unified
.section .text.f,"axG",%progbits,f,comdat
f:
.fnstart
bx lr
.fnend
.section .text.g,"axG",%progbits,g,comdat
g:
.fnstart
bx lr
.fnend
.section .text.h
.global __aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr0:
[ICF] Ignore SHF_GROUP flag when comparing two sections. SHF_GROUP bit doesn't make sense in executables or DSOs, so linkers are expected to remove that bit from section flags. We did that when we create output sections. This patch is to do that earlier than before. Now the flag is dropped when we instantiate input section objects. This change improves ICF. Previously, two sections that differ only in SHF_GROUP flag were not merged, because when the control reached ICF, the flag was still there. Now the flag is dropped before reaching to ICF, so the difference is ignored naturally. This issue was found by pcc. Differential Revision: https://reviews.llvm.org/D34074 llvm-svn: 305134
2017-06-10 08:38:55 +08:00
nop
[ELF] Mark ARM Exceptions that refer to folded code as not live ARM Exception Index Table sections .ARM.exidx have an implicit dependency on code sections via SHF_LINK_ORDER. When code sections are folded by ICF we must mark the unique .ARM.exidx table that describes it as not live to prevent an illegal entry in the exception table. Note that we do not try and follow the relocations from the .ARM.exidx section to the .ARM.extab sections to mark these as not live. Leaving these sections is not a correctness problem. In theory these could be removed via an application of garbage collection. Fixes https://bugs.llvm.org/show_bug.cgi?id=32614 Differential Revision: https://reviews.llvm.org/D31932 llvm-svn: 300182
2017-04-13 16:52:58 +08:00
bx lr
[llvm-objdump] Further rearrange llvm-objdump sections for compatability Summary: rL371826 rearranged some output from llvm-objdump for GNU objdump compatability, but there still seem to be some more. I think this rearrangement is a little closer. Overview of the ordering which matches GNU objdump: * Archive headers * File headers * Section headers * Symbol table * Dwarf debugging * Relocations (if `--disassemble` is not used) * Section contents * Disassembly Reviewers: jhenderson, justice_adams, grimar, ychen, espindola Reviewed By: jhenderson Subscribers: aprantl, emaste, arichardson, jrtc27, atanasyan, seiya, llvm-commits, MaskRay Tags: #llvm Differential Revision: https://reviews.llvm.org/D68066 llvm-svn: 373671
2019-10-04 06:01:08 +08:00
// CHECK: Contents of section .ARM.exidx:
[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-NEXT: 100d4 18000100 b0b0b080 14000100 01000000
[llvm-objdump] Further rearrange llvm-objdump sections for compatability Summary: rL371826 rearranged some output from llvm-objdump for GNU objdump compatability, but there still seem to be some more. I think this rearrangement is a little closer. Overview of the ordering which matches GNU objdump: * Archive headers * File headers * Section headers * Symbol table * Dwarf debugging * Relocations (if `--disassemble` is not used) * Section contents * Disassembly Reviewers: jhenderson, justice_adams, grimar, ychen, espindola Reviewed By: jhenderson Subscribers: aprantl, emaste, arichardson, jrtc27, atanasyan, seiya, llvm-commits, MaskRay Tags: #llvm Differential Revision: https://reviews.llvm.org/D68066 llvm-svn: 373671
2019-10-04 06:01:08 +08:00
[ELF] Mark ARM Exceptions that refer to folded code as not live ARM Exception Index Table sections .ARM.exidx have an implicit dependency on code sections via SHF_LINK_ORDER. When code sections are folded by ICF we must mark the unique .ARM.exidx table that describes it as not live to prevent an illegal entry in the exception table. Note that we do not try and follow the relocations from the .ARM.exidx section to the .ARM.extab sections to mark these as not live. Leaving these sections is not a correctness problem. In theory these could be removed via an application of garbage collection. Fixes https://bugs.llvm.org/show_bug.cgi?id=32614 Differential Revision: https://reviews.llvm.org/D31932 llvm-svn: 300182
2017-04-13 16:52:58 +08:00
// CHECK: 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
// 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: <g>:
[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-NEXT: 200ec: 1e ff 2f e1 bx lr
[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: <__aeabi_unwind_cpp_pr0>:
[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-NEXT: 200f0: 00 f0 20 e3 nop
// CHECK-NEXT: 200f4: 1e ff 2f e1 bx lr