Are there any plans to support the following binary format?
If this was supported then it will be possible to compress 64-bit iOS apps, which in my case will really help me. I have a 30M executable which (when I build it on x86_64) compresses down to 5M with UPX. Fantastic!
At the moment I get a "upx: test: UnknownExecutableFormatException".
Here is how you can help:
Make a "trivial" Xcode project that clears the screen, displays "Hello world!" for 3 seconds, then exits. The project must generate actual AArch64 executable code (not x86_64 code), and the Xcode project debugger running on MacOS must emulate it AArch64 instruction by Aarch instruction (not depend on execution of x86_64code as a "faithful" representation of the "just re-compile and run on AArch64" code), and the utility program "/usr/bin/otool" must work on the "executable file" of AArch64 code. Upload the project as an attachment here, with instructions on how I can "import" it into Xcode running on my Mac, so I can run the debugger AA4ch64 instruction by AArch64 instruction. I will run otool, find the entry address, overwrite the instruction at the entry point to be a breakpoint instruction (or a TrapAlways, etc.), then run the debugger to find out the actual state of memory at the first instruction. When the UPX code is ready, I will debug it similarly.
Find the code for "bless this block of Just-In-TIme-generated AArch64 instructions as executable code so that it may run natively". From the hardware point of view, this involves flushing the data cache (forcing RAM to contain a faithful copy of what is in the data cache), invalidating any entries in the instruction cache for the corresponding range of addresses (discarding any cached old contents), and turning on Execute permission for the block of instructions. It is essential that the "blessing" involve only user-mode AArch64 instructions and/or "system call instructions". Relying on a call to a named external subroutine is exactly what we DO NOT want.
Then I can concentrate on getting the UPX code to run on AArch64, and not spend five times as long figuring out the inanities of Apple's palace-in-the-sky software.
Last edit: John Reiser 2015-08-03