A New Direction for the Mac Arm64 Code Generator

Brian Callahan bcallah at openbsd.org
Sat Jul 11 16:16:57 UTC 2026


On Saturday, 11 July 2026 at 04:15:16 UTC, Walter Bright wrote:
> I had carefully crafted the Mach object file generation 
> according to how the default Mac compilers worked. I'd compile 
> bits of code with clang, and dump out the object files. 
> Fortunately, there was also a specification for it, and I could 
> compare the specification with what was generated.
>
> Enter the arm64 clang. Well, it throws this out the window, and 
> has their own undocumented variant of the file format. I've 
> spent a lot of time with AI trying to figure out how to make my 
> work still work with the new ld linker.
>
> The AI would give me mostly correct information, but would 
> never quite give me the details of how it was supposed to work. 
> (This is the likely result of a lack of documentation.) Many of 
> its recommendations just resulted in internal linker assert 
> failures. Yes, my object files would crash ld. This is not 
> helpful because I don't know why they crashed it. AI finally 
> recommended to me reading the LLVM linker source code (it's 
> open source).
>
> Well, looking at that undocumented uncommented hellish snarl of 
> C++ code was a moment of unhappy frustration for me.
>
> So I am forced to abandon the documented way to generate object 
> files, and reverse engineer the new way. At least one point in 
> my favor is I can use g++ to generate sample .o files, and then 
> try to conform to what g++ emits.
>
> It's going to be slow going, though.
>
> Given the frequent erroneous assertions AI has made about the 
> object code format, I won't bother trying to use AI to generate 
> the code.

FWIW, there is also a complete Mach-O linker written in Zig, 
which is what the Zig project itself uses as the linker on macOS: 
https://codeberg.org/kubkon/bold

~Brian


More information about the Digitalmars-d mailing list