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. 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. Perhaps that would want mentioning here then as well. Jan
