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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.02.2026 10:11, Roger Pau Monné wrote:
> On Mon, Feb 09, 2026 at 07:30:30AM +0000, Bertrand Marquis wrote:
>> Hi Roger,
>>
>>> On 6 Feb 2026, at 18:25, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>>>
>>> On Fri, Feb 06, 2026 at 05:21:44PM +0100, 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=unknown, 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 toolchain from brew:
>>>> - brew install aarch64-elf-gcc aarch64-elf-binutils
>>>> - cd xen
>>>> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=clang
>>>
>>> Instead of `cd xen` I would use `make xen ...`.
>>
>> Ack the 'cd xen' line is useless and should be removed.
>>
>>>
>>>>
>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
>>>
>>> Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>>
>>> One comment below.
>>>
>>>> ---
>>>> Changes since v3:
>>>> - set XEN_COMPILE_ARCH to unknown instead of Darwin
>>>> - list binutils as a dependency to install in brew in commit message
>>>>
>>>> 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
>>>> ---
>>>> config/Darwin.mk | 7 +++++++
>>>> 1 file changed, 7 insertions(+)
>>>> create mode 100644 config/Darwin.mk
>>>>
>>>> diff --git a/config/Darwin.mk b/config/Darwin.mk
>>>> new file mode 100644
>>>> index 000000000000..176b27eac676
>>>> --- /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.
>>>
>>> Hm, is this actually fully true?  What's the Linux ABI exactly here?
>>>
>>> FreeBSD builds Xen natively, and it's not using the Linux ABI.
>>> FreeBSD uses no specific -target to the compiler invocations, and the
>>> linker emulation is set to elf_x86_64_fbsd.
>>>
>>> I think the point here is that the toolchain must support building ELF
>>> objects / images, because that's the binary format supported by Xen.
>>> Whether it's Linux ELF or FreeBSD ELF doesn't make a difference for
>>> standalone environments like the Xen kernel.
>>
>> This file is also use while compiling the tools and for those you definitely
>> to cross compile as they depend on Linux ABI.
> 
> I'm not an expert on this at all, but IMO the tools don't depend on
> the Linux ABI at all.  Anyone can add the minimal OS-specific bindings
> required for the tools to work on environments different than Linux.
> We currently have {Net,Free}BSD and Linux.  In the past we also had
> Solaris, but that has bit rotten.
> 
>> Maybe that works on BSD
>> but i doubt this would be the case on mac os.
> 
> I doubt we would ever have any need to build an OSX native toolchain,
> as it's unlikely (?) that we will ever get Xen support in the Darwin
> kernel.

If Darwin has some way to load "modules" (e.g. drivers) into the kernel, it
may in principle be possible to run OSX as a HVM-Dom0, with a Xen driver
loaded separately. That's far fetched, I know.

>> Maybe we could simplify the sentence to not say anything we are unsure:
>>
>> # Cross compile on Mac OS
>>
>> Tell me if that works for you and i can submit a v5 or this might be 
>> possible to
>> fix on commit.
> 
> I'm fine with it, I would like to hear Jan's opinion.

As long as it's clear that all of this is only about building the hypervisor
(which doesn't look to be the case right now beyond the example given in the
commit message, which may be taken as really only an example), that's okay
[1]. I'd still prefer to mention the SVR4 ABI here, though, to at least
somewhat explain the "always cross" aspect.

I can make edits while committing, but I'm unsure whether that's wanted in
this case.

Jan

[1] Yet better might be if we refused to build other than the hypervisor.
I'm unsure though how easy it would be to achieve that in an at least
halfway tidy manner.