Re: Implications of QEMU binfmt transparent emulation for builds

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]


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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]