maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/MachO/segments.s

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

74 lines
2.4 KiB
ArmAsm
Raw Normal View History

[lld-macho] Add support for arm64_32 From what I can tell, it's pretty similar to arm64. The two main differences are: 1. No 64-bit relocations 2. Stub code writes to 32-bit registers instead of 64-bit Plus of course the various on-disk structures like `segment_command` are using the 32-bit instead of the 64-bit variants. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99822
2021-04-16 09:14:32 +08:00
# REQUIRES: x86, aarch64
# RUN: rm -rf %t; mkdir -p %t
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %s -o %t/x86_64.o
# RUN: llvm-mc -filetype=obj -triple=arm64_32-apple-watchos %s -o %t/arm64-32.o
# RUN: %lld -o %t/x86_64 %t/x86_64.o
# RUN: %lld-watchos -o %t/arm64_32 %t/arm64-32.o
# RUN: llvm-readobj --macho-segment %t/x86_64 > %t/x86_64.out
# RUN: echo "Total file size" >> %t/x86_64.out
# RUN: wc -c %t/x86_64 >> %t/x86_64.out
# RUN: FileCheck %s -DSUFFIX=_64 -DPAGEZERO_SIZE=0x100000000 -DTEXT_ADDR=0x100000000 < %t/x86_64.out
# RUN: llvm-readobj --macho-segment %t/arm64_32 > %t/arm64-32.out
# RUN: echo "Total file size" >> %t/arm64-32.out
# RUN: wc -c %t/arm64_32 >> %t/arm64-32.out
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the `__LLVM` segment is directly before `__LINKEDIT` by checking that `fileOff + fileSize == next segment fileOff`. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for `__LLVM`, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the `__LINKEDIT` segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in `__LINKEDIT` covers the last byte of the segment, so if we rounded up `__LINKEDIT`'s size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more `__LINKEDIT` sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848
2021-04-21 04:58:07 +08:00
# RUN: FileCheck %s -DSUFFIX= -DPAGEZERO_SIZE=0x4000 -DTEXT_ADDR=0x4000 < %t/arm64-32.out
Reland D75382 "[lld] Initial commit for new Mach-O backend" With a fix for http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/3636 Also trims some unneeded dependencies.
2020-04-03 02:54:05 +08:00
[lld-macho] Extend SyntheticSections to cover all segment load commands Previously, the special segments `__PAGEZERO` and `__LINKEDIT` were implemented as special LoadCommands. This diff implements them using special sections instead which have an `isHidden()` attribute. We do not emit section headers for hidden sections, but we use their addresses and file offsets to determine that of their containing segments. In addition to allowing us to share more segment-related code, this refactor is also important for the next step of emitting dylibs: 1) dylibs don't have segments like __PAGEZERO, so we need an easy way of omitting them w/o messing up segment indices 2) Unlike the kernel, which is happy to run an executable with out-of-order segments, dyld requires dylibs to have their segment load commands arranged in increasing address order. The refactor makes it easier to implement sorting of sections and segments. Differential Revision: https://reviews.llvm.org/D76839
2020-04-28 03:50:59 +08:00
## These two segments must always be present at the start of an executable.
# CHECK-NOT: Segment {
# CHECK: Segment {
[lld-macho] Add support for arm64_32 From what I can tell, it's pretty similar to arm64. The two main differences are: 1. No 64-bit relocations 2. Stub code writes to 32-bit registers instead of 64-bit Plus of course the various on-disk structures like `segment_command` are using the 32-bit instead of the 64-bit variants. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99822
2021-04-16 09:14:32 +08:00
# CHECK-NEXT: Cmd: LC_SEGMENT[[SUFFIX]]{{$}}
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
# CHECK-NEXT: Name: __PAGEZERO
[lld-macho] Add support for arm64_32 From what I can tell, it's pretty similar to arm64. The two main differences are: 1. No 64-bit relocations 2. Stub code writes to 32-bit registers instead of 64-bit Plus of course the various on-disk structures like `segment_command` are using the 32-bit instead of the 64-bit variants. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99822
2021-04-16 09:14:32 +08:00
# CHECK-NEXT: Size:
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
# CHECK-NEXT: vmaddr: 0x0
[lld-macho] Add support for arm64_32 From what I can tell, it's pretty similar to arm64. The two main differences are: 1. No 64-bit relocations 2. Stub code writes to 32-bit registers instead of 64-bit Plus of course the various on-disk structures like `segment_command` are using the 32-bit instead of the 64-bit variants. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99822
2021-04-16 09:14:32 +08:00
# CHECK-NEXT: vmsize: [[PAGEZERO_SIZE]]
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
# CHECK-NEXT: fileoff: 0
# CHECK-NEXT: filesize: 0
[lld-macho] Extend SyntheticSections to cover all segment load commands Previously, the special segments `__PAGEZERO` and `__LINKEDIT` were implemented as special LoadCommands. This diff implements them using special sections instead which have an `isHidden()` attribute. We do not emit section headers for hidden sections, but we use their addresses and file offsets to determine that of their containing segments. In addition to allowing us to share more segment-related code, this refactor is also important for the next step of emitting dylibs: 1) dylibs don't have segments like __PAGEZERO, so we need an easy way of omitting them w/o messing up segment indices 2) Unlike the kernel, which is happy to run an executable with out-of-order segments, dyld requires dylibs to have their segment load commands arranged in increasing address order. The refactor makes it easier to implement sorting of sections and segments. Differential Revision: https://reviews.llvm.org/D76839
2020-04-28 03:50:59 +08:00
## The kernel won't execute a binary with the wrong protections for __PAGEZERO.
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
# CHECK-NEXT: maxprot: ---
# CHECK-NEXT: initprot: ---
# CHECK-NEXT: nsects: 0
# CHECK-NEXT: flags: 0x0
# CHECK-NEXT: }
# CHECK-NEXT: Segment {
[lld-macho] Add support for arm64_32 From what I can tell, it's pretty similar to arm64. The two main differences are: 1. No 64-bit relocations 2. Stub code writes to 32-bit registers instead of 64-bit Plus of course the various on-disk structures like `segment_command` are using the 32-bit instead of the 64-bit variants. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99822
2021-04-16 09:14:32 +08:00
# CHECK-NEXT: Cmd: LC_SEGMENT[[SUFFIX]]{{$}}
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
# CHECK-NEXT: Name: __TEXT
[lld-macho] Add support for arm64_32 From what I can tell, it's pretty similar to arm64. The two main differences are: 1. No 64-bit relocations 2. Stub code writes to 32-bit registers instead of 64-bit Plus of course the various on-disk structures like `segment_command` are using the 32-bit instead of the 64-bit variants. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99822
2021-04-16 09:14:32 +08:00
# CHECK-NEXT: Size:
# CHECK-NEXT: vmaddr: [[TEXT_ADDR]]
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
# CHECK-NEXT: vmsize:
[lld-macho] Extend SyntheticSections to cover all segment load commands Previously, the special segments `__PAGEZERO` and `__LINKEDIT` were implemented as special LoadCommands. This diff implements them using special sections instead which have an `isHidden()` attribute. We do not emit section headers for hidden sections, but we use their addresses and file offsets to determine that of their containing segments. In addition to allowing us to share more segment-related code, this refactor is also important for the next step of emitting dylibs: 1) dylibs don't have segments like __PAGEZERO, so we need an easy way of omitting them w/o messing up segment indices 2) Unlike the kernel, which is happy to run an executable with out-of-order segments, dyld requires dylibs to have their segment load commands arranged in increasing address order. The refactor makes it easier to implement sorting of sections and segments. Differential Revision: https://reviews.llvm.org/D76839
2020-04-28 03:50:59 +08:00
## dyld3 assumes that the __TEXT segment starts from the file header
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
# CHECK-NEXT: fileoff: 0
# CHECK-NEXT: filesize:
[lld-macho][easy] Fix segment max protection We should have maxprot == initprot for all non-i386 architectures, which is what ld64 does. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D89420
2020-10-15 03:46:49 +08:00
# CHECK-NEXT: maxprot: r-x
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
# CHECK-NEXT: initprot: r-x
# CHECK-NEXT: nsects: 1
# CHECK-NEXT: flags: 0x0
# CHECK-NEXT: }
Reland D75382 "[lld] Initial commit for new Mach-O backend" With a fix for http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/3636 Also trims some unneeded dependencies.
2020-04-03 02:54:05 +08:00
[lld-macho] Extend SyntheticSections to cover all segment load commands Previously, the special segments `__PAGEZERO` and `__LINKEDIT` were implemented as special LoadCommands. This diff implements them using special sections instead which have an `isHidden()` attribute. We do not emit section headers for hidden sections, but we use their addresses and file offsets to determine that of their containing segments. In addition to allowing us to share more segment-related code, this refactor is also important for the next step of emitting dylibs: 1) dylibs don't have segments like __PAGEZERO, so we need an easy way of omitting them w/o messing up segment indices 2) Unlike the kernel, which is happy to run an executable with out-of-order segments, dyld requires dylibs to have their segment load commands arranged in increasing address order. The refactor makes it easier to implement sorting of sections and segments. Differential Revision: https://reviews.llvm.org/D76839
2020-04-28 03:50:59 +08:00
## Check that we handle max-length names correctly.
[lld-macho] Add support for arm64_32 From what I can tell, it's pretty similar to arm64. The two main differences are: 1. No 64-bit relocations 2. Stub code writes to 32-bit registers instead of 64-bit Plus of course the various on-disk structures like `segment_command` are using the 32-bit instead of the 64-bit variants. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99822
2021-04-16 09:14:32 +08:00
# CHECK: Cmd: LC_SEGMENT[[SUFFIX]]{{$}}
[lld-macho] Extend SyntheticSections to cover all segment load commands Previously, the special segments `__PAGEZERO` and `__LINKEDIT` were implemented as special LoadCommands. This diff implements them using special sections instead which have an `isHidden()` attribute. We do not emit section headers for hidden sections, but we use their addresses and file offsets to determine that of their containing segments. In addition to allowing us to share more segment-related code, this refactor is also important for the next step of emitting dylibs: 1) dylibs don't have segments like __PAGEZERO, so we need an easy way of omitting them w/o messing up segment indices 2) Unlike the kernel, which is happy to run an executable with out-of-order segments, dyld requires dylibs to have their segment load commands arranged in increasing address order. The refactor makes it easier to implement sorting of sections and segments. Differential Revision: https://reviews.llvm.org/D76839
2020-04-28 03:50:59 +08:00
# CHECK-NEXT: Name: maxlen_16ch_name
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
## This segment must always be present at the end of an executable, and cover
## its last byte.
[lld-macho] Extend SyntheticSections to cover all segment load commands Previously, the special segments `__PAGEZERO` and `__LINKEDIT` were implemented as special LoadCommands. This diff implements them using special sections instead which have an `isHidden()` attribute. We do not emit section headers for hidden sections, but we use their addresses and file offsets to determine that of their containing segments. In addition to allowing us to share more segment-related code, this refactor is also important for the next step of emitting dylibs: 1) dylibs don't have segments like __PAGEZERO, so we need an easy way of omitting them w/o messing up segment indices 2) Unlike the kernel, which is happy to run an executable with out-of-order segments, dyld requires dylibs to have their segment load commands arranged in increasing address order. The refactor makes it easier to implement sorting of sections and segments. Differential Revision: https://reviews.llvm.org/D76839
2020-04-28 03:50:59 +08:00
# CHECK: Name: __LINKEDIT
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
# CHECK-NEXT: Size:
# CHECK-NEXT: vmaddr:
# CHECK-NEXT: vmsize:
# CHECK-NEXT: fileoff: [[#%u, LINKEDIT_OFF:]]
# CHECK-NEXT: filesize: [[#%u, LINKEDIT_SIZE:]]
[lld-macho][easy] Fix segment max protection We should have maxprot == initprot for all non-i386 architectures, which is what ld64 does. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D89420
2020-10-15 03:46:49 +08:00
# CHECK-NEXT: maxprot: r--
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
# CHECK-NEXT: initprot: r--
[lld-macho] Add support for arm64_32 From what I can tell, it's pretty similar to arm64. The two main differences are: 1. No 64-bit relocations 2. Stub code writes to 32-bit registers instead of 64-bit Plus of course the various on-disk structures like `segment_command` are using the 32-bit instead of the 64-bit variants. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99822
2021-04-16 09:14:32 +08:00
# CHECK-NOT: Cmd: LC_SEGMENT[[SUFFIX]]{{$}}
Reland D75382 "[lld] Initial commit for new Mach-O backend" With a fix for http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/3636 Also trims some unneeded dependencies.
2020-04-03 02:54:05 +08:00
[lld-macho] Fix segment filesize calculation The previous approach of adding up the file sizes of the component sections ignored the fact that the sections did not have to be contiguous in the file. As such, it was underestimating the true size. I discovered this issue because `codesign` checks whether `__LINKEDIT` extends to the end of the file. Since we were underestimating segment sizes, this check failed. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84574
2020-07-29 00:56:55 +08:00
# CHECK-LABEL: Total file size
# CHECK-NEXT: [[#%u, LINKEDIT_OFF + LINKEDIT_SIZE]]
Reland D75382 "[lld] Initial commit for new Mach-O backend" With a fix for http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/3636 Also trims some unneeded dependencies.
2020-04-03 02:54:05 +08:00
.text
.global _main
_main:
ret
.section maxlen_16ch_name,foo