Re: [PATCH v3 1/1] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0

[Edwin Torok <edwin.torok@xxxxxxxxxx>]

> On 9 Mar 2026, at 07:47, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 06.03.2026 17:25, Edwin Török wrote:
>> clang would duplicate the loop body and end up with a double definition
>> of the symbol:
>> ```
>> /tmp/test_x86_emulator-0f3576.s:27823: Error: symbol `vmovsh_to_mem' is 
>> already defined
>> /tmp/test_x86_emulator-0f3576.s:27825: Error: symbol `.Lvmovsh_to_mem_end' 
>> is already defined
>> ```
>> 
>> Until a better solution is found: disable all optimizations in the test 
>> runner.
>> 
>> Using -Os might also work, but we can't rely on the size optimization
>> always avoiding the duplication of asm blocks.
>> This is test code, not performance critical code, and -O0 is more future
>> proof.
> 
> Hmm, yes, the good thing is that this then doesn't even conflict with my
> https://lists.xen.org/archives/html/xen-devel/2023-04/msg00283.html.
> 
>> --- a/tools/tests/x86_emulator/Makefile
>> +++ b/tools/tests/x86_emulator/Makefile
>> @@ -323,4 +323,9 @@ x86-emulate.o x86_emulate/%.o: HOSTCFLAGS += 
>> -D__XEN_TOOLS__
>> $(call cc-option-add,HOSTCFLAGS-toplevel,HOSTCC,-fno-toplevel-reorder)
>> test_x86_emulator.o: HOSTCFLAGS += $(HOSTCFLAGS-toplevel)
>> 
>> +# clang duplicates inline assembly when unrolling loops,
>> +# which causes a duplicate label error.
>> +# Until a better solution is found: disable all optimizations in the test 
>> runner.
>> +test_x86_emulator.o: HOSTCFLAGS += -O0
> 
> I think the first sentence may want wording a little differently, and I
> further think it absolutely needs to mention put_insn(). Maybe:
> 
> "When unrolling loops, compilers may duplicate inline assembly. put_insn()
> emits labels, which may not be emitted multiple times."
> 
> Happy to adjust while committing if you're okay with me doing so.


Sure, go ahead.


> There's
> one other question though: Isn't -O0 the default? Where would any other
> optimization setting come from in HOSTCFLAGS? Ah, I see ./Config.mk does
> this, for an unclear to me reason.

One possible reason I’d enable optimisations (even for non-performance critical 
code) is to get better warnings.
I looked this up, and I see it is actually documented in the GCC manual:
"The effectiveness of some warnings depends on optimizations also being enabled.
For example, -Wsuggest-final-types is more effective with link-time 
optimization. 
Some other warnings may not be issued at all unless optimization is enabled.
While optimization in general improves the efficacy of warnings about control 
and data-flow problems,
in some cases it may also cause false positives.”

In fact warnings rely on optimisations even more than I thought, didn’t know 
about link time optimisations having an effect
(from the example that warning is only relevant for C++ for now)

I can see why in general a compiler would decide to implement it that way (if 
you run an analysis to get more accurate
information for showing warnings then you might as well use it to emit better 
code), but I wish that wasn’t the case. 
E.g. you may want to use a low optimisation level to get better debugging, 
without giving up on the better warnings.
The only way to do that currently is to build it twice (or rely on a CI that 
builds with different flags).

If you want to change it I’d suggest setting it at least to -Og, which is 
recommended over O0:
"In contrast to -O0, this enables -fvar-tracking-assignments and -fvar-tracking 
which handle debug information in the prologue and epilogue of functions better 
than -O0."
But I don’t know how this affects the effectiveness of warnings.

> Perhaps that would want mentioning
> here then as well.

How about:

# The default HOSTCFLAGS from $(XEN_ROOT)/Config.mk would set
# a non-zero optimisation level

I’d avoid mentioning -O2, in case that changes.


Best regards,
—Edwin