Looking for help crunching a MacOS ARM 64kb bin
category: code [glöplog]
Hey all! Long time demoscene admirer, first time poster.
TLDR; noob looking for advice to make a 69kb macos arm binary smaller
I literally only have this triangle. Its just triangle.
I've been developing a hobby microengine and I currently have a Vulkan 1.4 Triangle weighing in at 51kb when signed locally, and 69kb when codesigned with my Apple development cert. This triangle is being rendered with basic spir-v compiled via slang. I'm super proud of this triangle but until I can get audio and sizing issues resolved, I'm hesitant to move on to more complex scenes.
I have a build here, not that I'm saying you should run unknown foreign code. In this archive is the same bin with symbols and locally signed as well as stripped and signed against my apple dev profile. https://drive.google.com/file/d/1rroIxNGpprSzwGUYZPFMynHSJgySRHtA/view?usp=sharing
My biggest problem is I'm losing 16kb due to dynamic linking requirements and having the first __DATA __got section bloat out to 16kb. The next biggest is codesigning data is appended to the program not within it, so being unable to cut down on this section or the second __DATA const section is doubly painful. I'm hoping someone has a magical golden bullet dyld replacement that will let me not need this section altogether.
I've been working on my own jank disassembler and analyzer so I can visualize my program. I don't know if this helps any but this is its current memory layout, badly labeled
I've tried all sorts of modifications and resigning, all types of changing the program header and program section offsets, and I'm unable to produce a binary that isn't aligned to these 16kb chunks and is this wasteful.
I know I can reduce code if I implement Metal instead of Vulkan, but my challenge to myself is to keep vulkan so I can target Windows/Linux/Mac easier, but reducing code in this binary won't reduce the final binary size in its current state due to these 16kb chunks.
Am at my wits end with this, so I feel like I've gone as far as I can go by myself. I'd greatly appreciate any insight and help on this matter.
TLDR; noob looking for advice to make a 69kb macos arm binary smaller
I literally only have this triangle. Its just triangle.
I've been developing a hobby microengine and I currently have a Vulkan 1.4 Triangle weighing in at 51kb when signed locally, and 69kb when codesigned with my Apple development cert. This triangle is being rendered with basic spir-v compiled via slang. I'm super proud of this triangle but until I can get audio and sizing issues resolved, I'm hesitant to move on to more complex scenes.
I have a build here, not that I'm saying you should run unknown foreign code. In this archive is the same bin with symbols and locally signed as well as stripped and signed against my apple dev profile. https://drive.google.com/file/d/1rroIxNGpprSzwGUYZPFMynHSJgySRHtA/view?usp=sharing
My biggest problem is I'm losing 16kb due to dynamic linking requirements and having the first __DATA __got section bloat out to 16kb. The next biggest is codesigning data is appended to the program not within it, so being unable to cut down on this section or the second __DATA const section is doubly painful. I'm hoping someone has a magical golden bullet dyld replacement that will let me not need this section altogether.
I've been working on my own jank disassembler and analyzer so I can visualize my program. I don't know if this helps any but this is its current memory layout, badly labeled
I've tried all sorts of modifications and resigning, all types of changing the program header and program section offsets, and I'm unable to produce a binary that isn't aligned to these 16kb chunks and is this wasteful.
I know I can reduce code if I implement Metal instead of Vulkan, but my challenge to myself is to keep vulkan so I can target Windows/Linux/Mac easier, but reducing code in this binary won't reduce the final binary size in its current state due to these 16kb chunks.
Am at my wits end with this, so I feel like I've gone as far as I can go by myself. I'd greatly appreciate any insight and help on this matter.
