Re: [PATCH v2 1/4] tools/tests/x86_emulator: avoid duplicate symbol error with clang

[Edwin Torok <edwin.torok@xxxxxxxxxx>]

> On 3 Mar 2026, at 15:36, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 03.03.2026 16:09, Edwin Torok wrote:
>>> On 3 Mar 2026, at 13:59, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> On 27.02.2026 11:58, Edwin Török wrote:
>>>> --- a/tools/tests/x86_emulator/test_x86_emulator.c
>>>> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
>>>> @@ -1882,8 +1882,13 @@ int main(int argc, char **argv)
>>>> #define decl_insn(which) extern const unsigned char which[], \
>>>>                         which##_end[] asm ( ".L" #which "_end" )
>>>> #define put_insn(which, insn) ".pushsection .test\n" \
>>>> -                              #which ": " insn "\n"  \
>>>> +                              ".ifndef "#which"\n" \
>>>> +                              #which ": \n" \
>>>> +                              ".endif\n" \
>>>> +                              insn "\n"  \
>>>> +                              ".ifndef .L"#which"_end\n" \
>>>>                              ".L" #which "_end:\n"  \
>>>> +                              ".endif\n" \
>>>>                              ".popsection"
>>> 
>>> Nice idea, but why multiple .ifndef, and why emitting the insn even if the
>>> labels are already there (and hence won't be emitted a 2nd time)?
>> 
>> I think we still need to execute the instructions, so they can be compared 
>> against the emulator.
> 
> Of course, but they cannot be executed without having a label. We use the
> label to point the emulated IP there, and then we use the end label to
> check that after emulation the emulated IP has advanced as expected.

Oh that means that we won’t actually be testing anything useful in iterations>=1
(the test passes, but it runs the same test as it did on iteration 0).

I had another approach in mind (always use a locally unique label with %=, and 
update a C pointer to point to current one),
but it’d be very invasive. Would have to use extended asm syntax instead of 
basic, but that isn’t even the biggest problem:
all the %0, %1 would get shifted because I’d need to introduce another output 
variable.
And if I don’t introduce an output variable then clang completely optimises 
away the pointer on the C side, thinking it is never written to,
volatile might help, but that’d require even more casts).
Probably not worth going too deep on this particular rabbit hole.

Since this is just test-code maybe I should try using -O0 instead for compiling 
the emulator *test code only* (i.e. add O0 to the tests/x86_emulator/Makefile)
I tried -Os from 
https://lists.xen.org/archives/html/xen-devel/2023-04/msg00283.html, but -Os is 
-O2 with *extra* optimisations to reduce code size for clang, so it doesn’t 
really turn any optimisations off (it turns more optimisations on…)
https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-O0
That isn’t necessarily the correct solution, but if it works it’d at least 
allow us to begin running both GCC and clang tests in the CI.


Best regards,
—Edwin