Re: [PATCH 4/4] tools/tests/x86_emulator: disable xmm* tests on clang

[Edwin Torok <edwin.torok@xxxxxxxxxx>]

> On 24 Feb 2026, at 09:48, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 24.02.2026 10:34, Edwin Torok wrote:
>>> On 23 Feb 2026, at 16:10, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> On 23.02.2026 11:04, Edwin Török wrote:
>>>> clang-21 doesn't support `-ffixed-xmm0`, so `%xmm0` won't have the
>>>> expected value.
>>>> Disable these tests on clang.
>>> 
>>> I don't think that's what we want, and not only because of the clutter the
>>> various #ifdef cause. We want to be able to run as many of the tests as
>>> possible, so the first goal should be to find some alternative mechanism to
>>> achieve the same effect. A global register variable comes to mind as a
>>> possible option.
>>> 
>>> Further, how did you arrive at which tests need suppressing?
>> 
>> I used gdb to look at the 2 memory areas, and noticed that the XMM region 
>> was different between emulated and actual when built with clang.
>> Then I noticed the build failures due to the lack of fixed-xmm0.
>> Then I added the ifdefs one by one as I ran the test until the whole test 
>> program passed without failure.
>> I tried adding some ‘pxor xmm0, xmm0’ into the cpu_has_sse2 sections, but 
>> that didn’t really work either.
>> 
>> Although I may have been misled by the overlapping region, see below.
>> 
>>> I don't think
>>> we rely on an "expected value" anywhere. I don't even recall us passing
>>> -ffixed-xmm0 when compiling test_x86_emulate.c.
>> 
>> Yes, I’m surprised it works with GCC. But maybe only because the emulator 
>> overwrites the actual FXSAVE area corresponding to XMM.
>> XMM0 begins at offset 160, and 0x100 - 0x80 = 128.
>> AFAICT the actual execution stores its result at [0x80, 0x80+0x200), and the 
>> emulator stores its result into [0x100, 0x100+0x200).
>> So the emulator will overwrite some of the values from the actual run. 
>> 
>> This only works if the end of the FXSAVE area looks like its beginning (i.e. 
>> if FCW/FSW/etc. happens to match MM6/etc.)
> 
> Are you possibly overlooking the fact that res[] is an array of unsigned int 
> elements,
> i.e. the offsets used in source code all need to be multiplied by 4 to give 
> offsets in
> memory?


Thanks, now the tests start making more sense! 

Although there is still a lot that I don’t understand about how some of the 
other failing tests work.
For now I’ve dropped this patch from my series though, i.e. lets first get the 
clang build fixes in,
and see how to fix them to actually run separately.

Best regards,
—Edwin