On 16/06/2021 07:38, Jan Beulich wrote: > On 15.06.2021 18:19, Andrew Cooper wrote: >> Jan/Roger: x86_emulator and vpci use $(HOSTCC) not $(CC). While they are >> unit >> tests, we still potentially want to run them in dom0 rather than the build >> environment - particularly for x86_emulator which is heavily CPUID based and >> wants to run on a wide set of hardware. Any issues moving them off >> $(HOSTCC)? > Well, yes, I'm afraid: If anything, we may need to build two binaries, > or build the one binary two different ways: The "run" (and "run32" for > the emulator harness) target wants a binary built with HOSTCC. The > install target (which prior to your series does nothing) indeed wants > building with CC. So maybe we want something like > > install: HOSTCC:=$(CC) > > plus suitable detection of whether the opposite set of objects are > presently in the build area, requiring a full rebuild? (Of course this > will work only as long as HOSTCC isn't used for any build time helper > binaries. See "x86emul: test AMX insns" for when this starts not to be > the case anymore for the emulator harness. So we'd need yet another > variable to express this detail.)
Having slept on the problem overnight, I'm going to argue that HOSTCC is conceptually wrong to use here in the first place. In an arm64 environment, cross-compiling x86_64, this will explode everywhere, and the fault is with using HOSTCC rather than CC. HOSTCC is specifically for compiling utilities executed as part of the build. Tests, and particularly arch-specific ones like x86_emulate, are not in this category. Whether you happen to be able to run test_x86_emulator in the build environment is a property of whether you're cross-compiling. For a non-cross-compiled builds, HOSTCC and CC are largely interchangeable, and won't impact the ability to run the binary in the build environment. ~Andrew
