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/load-command-sequence.s

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

74 lines
1.8 KiB
ArmAsm
Raw Normal View History

[lld-macho] Fix alignment & layout to match ld64 and satisfy kernel & codesign The Mach kernel & codesign on arm64 macOS has strict requirements for alignment and sequence of segments and sections. Dyld probably is just as picky, though kernel & codesign reject malformed Mach-O files before dyld ever has a chance. I developed this diff by incrementally changing alignments & sequences to match the output of ld64. I stopped when my hello-world test program started working: `codesign --verify` succeded, and `execve(2)` didn't immediately fail with `errno == EBADMACHO` = `"Malformed Mach-O file"`. Differential Revision: https://reviews.llvm.org/D94935
2021-01-03 02:31:55 +08:00
# REQUIRES: x86
# RUN: rm -rf %t && mkdir -p %t
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %s -o %t/test.o
# RUN: %lld -execute -o %t/exec %t/test.o -lSystem
# RUN: %lld -dylib -o %t/dylib %t/test.o -lSystem
# RUN: %lld -bundle -o %t/bundle %t/test.o -lSystem
# RUN: llvm-objdump --macho --all-headers %t/exec | \
# RUN: FileCheck %s --check-prefixes=EXEC,COMMON
# RUN: llvm-objdump --macho --all-headers %t/dylib | \
# RUN: FileCheck %s --check-prefixes=DYLIB,COMMON
# RUN: llvm-objdump --macho --all-headers %t/bundle | \
[test] Fix unused check prefixes
2021-02-09 05:44:29 +08:00
# RUN: FileCheck %s --check-prefix=COMMON
[lld-macho] Fix alignment & layout to match ld64 and satisfy kernel & codesign The Mach kernel & codesign on arm64 macOS has strict requirements for alignment and sequence of segments and sections. Dyld probably is just as picky, though kernel & codesign reject malformed Mach-O files before dyld ever has a chance. I developed this diff by incrementally changing alignments & sequences to match the output of ld64. I stopped when my hello-world test program started working: `codesign --verify` succeded, and `execve(2)` didn't immediately fail with `errno == EBADMACHO` = `"Malformed Mach-O file"`. Differential Revision: https://reviews.llvm.org/D94935
2021-01-03 02:31:55 +08:00
## Check that load commands and sections within segments occur in the proper
## sequence. On ARM64 kernel is especially picky about layout, and will
## barf with errno=EBADMACHO when the sequence is wrong.
# EXEC: cmd LC_SEGMENT_64
# EXEC: segname __PAGEZERO
# COMMON: cmd LC_SEGMENT_64
# COMMON: segname __TEXT
# COMMON: sectname __text
# COMMON: segname __TEXT
# COMMON: sectname __cstring
# COMMON: segname __TEXT
# COMMON: cmd LC_SEGMENT_64
# COMMON: segname __DATA_CONST
# COMMON: sectname __got
# COMMON: segname __DATA_CONST
[lld-macho][nfc] Sort OutputSections based on explicit order of command-line inputs This diff paves the way for {D102964} which adds a new kind of InputSection. We previously maintained section ordering implicitly: we created InputSections as we parsed each file in command-line order, and passed on this ordering when we created OutputSections and OutputSegments by iterating over these InputSections. The implicitness of the ordering made it difficult to refactor the code to e.g. handle a new type of InputSection. As such, I've codified the ordering explicitly via `inputOrder` fields. This also allows us to use `sort` instead of `stable_sort`. Benchmarking chromium_framework on my 3.2 GHz 16-Core Intel Xeon W: N Min Max Median Avg Stddev x 20 4.23 4.35 4.27 4.274 0.030157481 + 20 4.24 4.38 4.27 4.2815 0.033759989 No difference proven at 95.0% confidence Reviewed By: #lld-macho, alexshap Differential Revision: https://reviews.llvm.org/D102972
2021-05-26 02:57:17 +08:00
# COMMON: sectname __const
# COMMON: segname __DATA_CONST
[lld-macho] Fix alignment & layout to match ld64 and satisfy kernel & codesign The Mach kernel & codesign on arm64 macOS has strict requirements for alignment and sequence of segments and sections. Dyld probably is just as picky, though kernel & codesign reject malformed Mach-O files before dyld ever has a chance. I developed this diff by incrementally changing alignments & sequences to match the output of ld64. I stopped when my hello-world test program started working: `codesign --verify` succeded, and `execve(2)` didn't immediately fail with `errno == EBADMACHO` = `"Malformed Mach-O file"`. Differential Revision: https://reviews.llvm.org/D94935
2021-01-03 02:31:55 +08:00
# COMMON: cmd LC_SEGMENT_64
# COMMON: segname __DATA
# COMMON: sectname __data
# COMMON: segname __DATA
# COMMON: cmd LC_SEGMENT_64
# COMMON: segname __LINKEDIT
# COMMON: cmd LC_DYLD_INFO_ONLY
# COMMON: cmd LC_SYMTAB
# COMMON: cmd LC_DYSYMTAB
# EXEC: cmd LC_LOAD_DYLINKER
# DYLIB: cmd LC_ID_DYLIB
# COMMON: cmd LC_UUID
[lld-macho] Have tests default to targeting macos 10.15 D101114 enforced proper version checks, which exposed a variety of version mismatch issues in our tests. We previously changed the test inputs to target 10.0, which was the simpler thing to do, but we should really just have our lit.local.cfg default to targeting 10.15, which is what is done here. We're not likely to ever have proper support for the older versions anyway, as that would require more work for unclear benefit; for instance, llvm-mc seems to generate a different compact unwind format for older macOS versions, which would cause our compact-unwind.s test to fail. Targeting 10.15 by default causes the following behavioral changes: * `__mh_execute_header` is now a section symbol instead of an absolute symbol * LC_BUILD_VERSION gets emitted instead of LC_VERSION_MIN_MACOSX. The former is 32 bytes in size whereas the latter is 16 bytes, so a bunch of hardcoded address offsets in our tests had to be updated. * >= 10.6 executables are PIE by default Note that this diff was stacked atop of a local revert of most of the test changes in rG8c17a875150f8e736e8f9061ddf084397f45f4c5, to make review easier. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D101119
2021-04-23 07:37:47 +08:00
# COMMON: cmd LC_BUILD_VERSION
[lld/mac] Change load command order to be more like ld64 No meaningful behavior change. Makes diffing `otool -l` output a bit easier. Differential Revision: https://reviews.llvm.org/D106219
2021-07-17 23:18:48 +08:00
# EXEC: cmd LC_MAIN
[lld-macho] Fix alignment & layout to match ld64 and satisfy kernel & codesign The Mach kernel & codesign on arm64 macOS has strict requirements for alignment and sequence of segments and sections. Dyld probably is just as picky, though kernel & codesign reject malformed Mach-O files before dyld ever has a chance. I developed this diff by incrementally changing alignments & sequences to match the output of ld64. I stopped when my hello-world test program started working: `codesign --verify` succeded, and `execve(2)` didn't immediately fail with `errno == EBADMACHO` = `"Malformed Mach-O file"`. Differential Revision: https://reviews.llvm.org/D94935
2021-01-03 02:31:55 +08:00
# COMMON: cmd LC_LOAD_DYLIB
.section __TEXT,__cstring
_str:
.asciz "Help me! I'm trapped in a test!\n"
.globl _mutable
.section __DATA,__data
mutable:
.long 0x1234
.globl _constant
.section __DATA,__const
constant:
.long 0x4567
.text
.global _main
_main:
mov ___nan@GOTPCREL(%rip), %rax
ret