addObjCopy() producing zero padding at start of binary

Sze · December 5, 2025, 11:00pm

zig objcopy -O binary creates binary file with some zero padding at the start

opened 08:08PM - 21 Oct 25 UTC

bug

### Zig Version 0.15.1 ### Steps to Reproduce and Observed Behavior I used th…e blinky.elf file from the project [stm32-baremetal-zig](https://github.com/haydenridd/stm32-baremetal-zig), but other elf files should also show the same behavior. I run the command ```bash zig objcopy -O binary blinky.elf blinky.bin ``` with zig 0.14.1 I get the correct output: ```txt 1 │ 00000000 00 00 05 20 99 20 00 08 49 22 00 08 49 22 00 08 |... . ..I"..I"..| 2 │ 00000010 49 22 00 08 49 22 00 08 49 22 00 08 00 00 00 00 |I"..I"..I"......| 3 │ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 49 22 00 08 |............I"..| 4 │ 00000030 49 22 00 08 00 00 00 00 49 22 00 08 51 22 00 08 |I"......I"..Q"..| ``` with zig 0.15.1 there is some zero padding at the start, which is wrong: ```txt 1 │ 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 2 │ * 3 │ 000001c0 00 00 00 00 00 00 00 00 00 00 05 20 99 20 00 08 |........... . ..| 4 │ 000001d0 49 22 00 08 49 22 00 08 49 22 00 08 49 22 00 08 |I"..I"..I"..I"..| 5 │ 000001e0 49 22 00 08 00 00 00 00 00 00 00 00 00 00 00 00 |I"..............| 6 │ 000001f0 00 00 00 00 49 22 00 08 49 22 00 08 00 00 00 00 |....I"..I"......| ``` ### Expected Behavior produce a correct bin file

tigerbeetle uses llvm-objcopy as their workaround:

github.com/tigerbeetle/tigerbeetle

build: vendor llvm-objcopy

main ← matklad/vendor-llvm-objcopy

opened 11:37AM - 30 Aug 24 UTC

matklad

+117 -22

We now depend on llvm-objcopy to make our multiversion binaries. Long term, we s…hould probably upstream the capabilities we need to `zig objcopy` but for now "vendor" a specific copy of llvm-objcopy we use. Vendoring is useful primarily because there isn't an easy way to install the tool in a cross-platform way! As we want to make multiversion a normal build, it is important that the build remains seemless and that the user doesn't have to manually install anything. The solution is to upload specific versions of llvm-objectopy as a release on <https://github.com/tigerbeetle/dependencies> and use that. Sadly, you have to trust me that the binaries I uploaded there are good, but the mac and windows versions are straight from LLVM upstream release, and the build of statically-linked linux version seems to be reproduciable. Assuming the specific binaries are fine, any further risks are locked down by veryfying the checksum upon the download.

So I think for now using a non-zig objcopy is the easiest solution, until the Zig version has been improved.