`FatArch64`

[woodruffw]

It looks like Apple decided to introduce a new fat_arch without telling anybody:

/*
 * The support for the 64-bit fat file format described here is a work in
 * progress and not yet fully supported in all the Apple Developer Tools.
 *
 * When a slice is greater than 4mb or an offset to a slice is greater than 4mb
 * then the 64-bit fat file format is used.
 */
#define FAT_MAGIC_64	0xcafebabf
#define FAT_CIGAM_64	0xbfbafeca	/* NXSwapLong(FAT_MAGIC_64) */

struct fat_arch_64 {
	cpu_type_t	cputype;	/* cpu specifier (int) */
	cpu_subtype_t	cpusubtype;	/* machine specifier (int) */
	uint64_t	offset;		/* file offset to this object file */
	uint64_t	size;		/* size of this object file */
	uint32_t	align;		/* alignment as a power of 2 */
	uint32_t	reserved;	/* reserved */
};

Based on the comment, we'll probably need to support it soon.

Source: https://opensource.apple.com/source/cctools/cctools-895/include/mach-o/fat.h.auto.html

[UniqMartin]

The second paragraph of the comment is most likely bogus, as it would make more sense to switch from 32 to 64 bit when crossing the 4 GiB size limit. (While it's difficult to find fat binaries on modern macOS, it's no problem to find non-fat binaries easily crossing the 4 MiB limit mentioned in the comment and I suspect some of them, e.g. iTunes, were bigger than 4 MiB per slice already a few years ago.) A quick peek at the lipo source confirms the size checks are actually against UINT32_MAX.

[woodruffw]

A quick peek at the lipo source confirms the size checks are actually against UINT32_MAX.

Thanks for the check! I have to admit that I totally glazed over that part comment and just assumed that it was UINT32_MAX 😉

I'll probably fill this in this weekend.