Direct x64 machine code generation - considerations for implementation for macOS and Windows

[ylluminate]

As we all know, x64 code generation is currently only available for Linux. The purpose of this issue is to track, discuss and collaborate on efforts to get this also implemented for macOS and Windows (or to branch out into other issues to get more specific for each).

[sheerun]

Here are some resources for MacOS Mach-O format and assembler:

• Writing 64-bit assembly on MacOS
• MacOS Assembler Reference
• Mach-O file format reference

Something about statically compiled binaries:

https://developer.apple.com/library/archive/qa/qa1118/_index.html

Apple does not support statically linked binaries on Mac OS X. A statically linked binary assumes binary compatibility at the kernel system call interface, and we do not make any guarantees on that front. Rather, we strive to ensure binary compatibility in each dynamically linked system library and framework.

If your project absolutely must create a statically linked binary, you can get the Csu (C startup) module from Darwin and try building crt0.o for yourself. Obviously, we won't support such an endeavor.

Probably it also means that fully statically compiled binary won't be accepted to App Store (you cannot use direct syscalls), and is not backward or forward-compatible, so these are huge downsides. Also statically compiled crt0.o is not enough, you also need statically compiled libSystem which simply isn't currently available. So probably it means we need to live with it and figure out how to link system libraries (at least System) with V compiler.

So the proper way to compile assembly that uses libc calls (libSystem) to binary on MacOS is:

as main.s -o main.o && ld main.o -lc -o main

There are some interesting facts when it comes to linking when you read source of go-lang linker: https://golang.org/src/cmd/link/internal/ld/macho.go For example some offsets need to be maintained for code signing to be working

[ylluminate]

Due to Apple's stance on static bins, could parts of Darling (GitHub & other associated repos) be used to help accomplish this?

[bjorn3]

Linux is one of the few systems that has a stable syscall interface. On all other systems you must use the system libraries to interface with the kernel. For macOS cross compilation there seems to be https://github.com/tpoechtrager/osxcross. For Windows cross compilation you can use mingw.

[medvednikov]

Exactly. V is going to be able to generate dynamically linked binaries.

For now it's Linux/static only.

[ylluminate]

For Windows @nord501 noted that it should be pe.v and asks whether or not we should use kernel32 or ntdll.lib...

[ylluminate]

@nord501 is putting forth a valiant and successful effort with Windows implementation and noted this last night that he now has a working hello world and is digging into V's x64 gen for integration. Source:
https://github.com/nord501/pe.v/blob/master/pe.v

[ylluminate]

macOS 11 (Big Sur) updates: https://gist.github.com/FiloSottile/7125822#gistcomment-3578065