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