[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implications of QEMU binfmt transparent emulation for builds

From: Christopher Baines
Subject: Re: Implications of QEMU binfmt transparent emulation for builds
Date: Sun, 07 Mar 2021 12:00:03 +0000
User-agent: mu4e 1.4.15; emacs 27.1

Mark H Weaver <> writes:

> Hi Christopher,
> Christopher Baines <> writes:
>> I'm starting to play with mixing native and emulated builds with the
>> Guix Build Coordinator again. I did do this many months ago, but at that
>> time, there wasn't support for targeting retries across a range of
>> machines, to help avoid blockages due to QEMU issues.
>> Anyway, something that's been on my mind regarding QEMU and builds is
>> how well this matches up with building natively.
> Here's one significant problem with emulated builds, although perhaps
> not the kind of problem you were asking about:
> Due to differences in the memory models of Intel and other systems such
> as ARM, it is easy to write multithreaded code that works robustly on
> Intel systems but sporadically fails on other architectures such as ARM.
> However, an ARM emulator running on an Intel system will effectively use
> an Intel memory model, because it would be prohibitively expensive to
> faithfully simulate the ARM memory model on Intel hardware, and the only
> benefit would be to demonstrate bugs that can't happen on Intel systems.
> Therefore, test suites run under an emulator will almost certainly fail
> to find architecture-specific thread safety problems, which I expect are
> among the most important tests to be done, and among the most likely to
> otherwise go unnoticed.
> For this reason, I suggest that we should avoid emulated builds in our
> build farm.

This is exactly the kind of problem I'm interested in, so thanks for the

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]