Re: [PATCH v3] xen: Add Darwin.mk for GNU toolchains

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Roger,

> On 6 Feb 2026, at 15:16, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> 
> On Fri, Feb 06, 2026 at 01:34:23PM +0000, Bertrand Marquis wrote:
>> 
>> 
>>> On 6 Feb 2026, at 14:29, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>>> 
>>> On Fri, Feb 06, 2026 at 11:38:02AM +0100, Jan Beulich wrote:
>>>> On 06.02.2026 09:17, Bertrand Marquis wrote:
>>>>> Xen does not provide a Darwin build configuration for selecting
>>>>> GNU tool definitions. On macOS, the tools we use are either GNU
>>>>> compatible or we only rely on features supported by Mac OS, so
>>>>> using the GNU tool definitions is appropriate.
>>>>> 
>>>>> Add config/Darwin.mk to include StdGNU.mk and force
>>>>> XEN_COMPILE_ARCH=Darwin, ensuring Darwin builds always follow
>>>>> the cross-compile path as we depend on the Linux ABI so compiling
>>>>> on Mac OS is always a cross compilation case.
>>>>> 
>>>>> An example of how to build the hypervisor for arm64 on Mac OS
>>>>> (tools cannot be build for now) using a compiler from brew:
>>>>> - brew install aarch64-elf-gcc
>>>>> - cd xen
>>>>> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=gcc
> 
> I've just noticed: it's a bit misleading to use HOSTCC=gcc here, as
> (under a normal OSX system) gcc is a plain wrapped around clang:
> 
> % gcc -v
> Apple clang version 17.0.0 (clang-1700.6.3.2)
> Target: arm64-apple-darwin24.6.0
> Thread model: posix
> 
> You might as well use HOSTCC=clang and make it explicit the host
> compiler is clang and not gcc.

true

> 
>>>>> 
>>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
>>>>> ---
>>>>> Changes since v2:
>>>>> - Subject was "xen: Add macOS hypervisor build configuration"
>>>>> - Update Darwin.mk comments to more accurate versions (Jan)
>>>>> - Remove the build-on-macos help as we have no dependency on anything
>>>>> coming from brew anymore and the toolchain can be retrieved by lots of
>>>>> other solutions than brew on mac os. Switch to a simple doc in the
>>>>> commit message instead
>>>> 
>>>> Did you see Roger's notice on Matrix about objcopy?
>>> 
>>> I think Bertrand considers objcopy to be part of the toolchain, hence
>>> "retrieving a toolchain" is meant to include objcopy (either the GNU,
>>> LLVM or elftoolchain one)
>> 
>> Sorry i only saw your message in matrix.
>> 
>> I checked and i installed both gcc and binutils in homebrew.
>> 
>> So i think the commit message needs modifying to stay:
>> 
>> brew install aarch64-elf-gcc aarch64-elf-binutils
>> 
>> to be fully complete.
> 
> Yes, I didn't notice that in the commit message you explicitly
> mentioned the brew install dependencies.  There's also bison and flex
> needed for Kconfig, but AFAICT those are part of command line tools.
> I think python is also part of the command line tools, and not sure
> it's required for arm64, as it's required for x86 to generate the
> cpuid headers (but I don't know if arm64 has anything equivalent).

python is not available on my side (python3 is).
I do not think this is needed on arm no.

> 
>>> 
>>>>> --- /dev/null
>>>>> +++ b/config/Darwin.mk
>>>>> @@ -0,0 +1,7 @@
>>>>> +# Use GNU tool definitions as the tools we are using are either GNU 
>>>>> compatible
>>>>> +# or we only use features which are supported on Mac OS.
>>>>> +include $(XEN_ROOT)/config/StdGNU.mk
>>>>> +
>>>>> +# Xen uses Linux'es ABI so we are cross compiling on Mac OS.
>>>>> +# Force COMPILE_ARCH to a fake value to make sure it is always the case.
>>>>> +XEN_COMPILE_ARCH = Darwin
>>>> 
>>>> I first wondered why you say "fake", seeing the file is named Darwin.mk. 
>>>> But
>>>> in Config.mk's cross-compile check the build host OS doesn't even matter. 
>>>> So
>>>> yes, it needs faking here for the time being.
>>> 
>>> Hm, setting it to "Darwin" seems weird to me.  I understand the
>>> purpose of this is to force the user to set XEN_TARGET_ARCH
>>> explicitly.  I however wouldn't see it as fully uncorrect to not set
>>> this.  It will then execute `uname -m` and get `arm64` back for Apple
>>> silicon macs (which is kind of OK?).  Other I suggest we use a non-OSX
>>> specific value here, so that if required we could distinguish this
>>> case where the user is expected to provide XEN_COMPILE_ARCH.
>>> 
>>> Maybe XEN_COMPILE_ARCH = { unknown | undefined }?
>> 
>> I am ok to change this with either but maybe unsupported could be
>> a third choice?
> 
> No strong opinion for either naming, as long as we don't explicitly
> use "Darwin".

ok let's use "unsupported"

I will push a v4 with the commit message and Darwin.mk fixes

Cheers
Bertrand

> 
> Thanks, Roger.