Re: Implications of QEMU binfmt transparent emulation for builds

[Maxim Cournoyer]

Hello Mark,

Mark H Weaver <mhw@netris.org> writes:

> Hi Christopher,
>
> Christopher Baines <mail@cbaines.net> 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.

Very interesting; thanks for sharing this great piece of information!  I
had no idea about this simplification/shortcut used by QEMU.

Maxim