This patch implements -Ibinary for MachO (64bit only for now).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 36988 Build 36987: arc lint + arc unit
Event Timeline
llvm/test/tools/llvm-objcopy/MachO/binary-input.test | ||
---|---|---|
1 | If I'm not mistaken, it should be Mach-O here rather than MachO. | |
2 | contains the input... | |
llvm/tools/llvm-objcopy/MachO/MachOReader.h | ||
9 | You shouldn't need the relative path. You should just be able to do "CopyConfig.h". If that doesn't work, then there's something wrong with the include directories, I think. This might point to a bigger flaw in llvm-objcopy's include paths. |
Okay, no more comments from me. Somebody with more Mach-O experience should look at the rest.
llvm/test/tools/llvm-objcopy/MachO/binary-input.test | ||
---|---|---|
20 | Note that GNU objcopy sets MH_MAGIC instead of MH_MAGIC64 for aarch64: $ gobjcopy -I binary -B aarch64 -O mach-o-arm64 foo.txt binary.arm64.o $ llvm-readobj binary.arm64.o File: binary.arm64.o Format: Mach-O 32-bit unknown <- should be "Mach-O arm64"! Arch: aarch64 AddressSize: 32bit $ otool -h binary.arm64.o Mach header magic cputype cpusubtype caps filetype ncmds ... 0xfeedface 16777228 0 0x00 1 3 ... I have no experience with aarch64 MachO objects, but AFAIK the magic should be MH_MAGIC64 (example). I believe it's a bug in GNU objcopy... |
If I'm not mistaken, it should be Mach-O here rather than MachO.