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

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

[Edwin Török]

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: reduce 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.
However for debugging -Og is recommended over -O0, and this still
avoids the duplicate label problem.

Signed-off-by: Edwin Török <edwin.torok@citrix.com>
---
Changed since v3:
 * use -Og instead of -O0, adjust comment
Changed since v2:
 * use -O0 instead of .ifndef (with ifndef the 2nd iteration would use code identical to first)
Changed since v1:
 * use .ifndef directive instead of volatile workaround
---
 tools/tests/x86_emulator/Makefile | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile
index 5003c464f3..8210e83345 100644
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -323,4 +323,11 @@ 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)
 
+# When unrolling loops, compilers may duplicate inline assembly. put_insn()
+# emits labels, which may not be emitted multiple times.
+# The default HOSTCFLAGS from $(XEN_ROOT)/Config.mk would set a non-zero
+# optimisation level.
+# Until a better solution is found: reduce optimizations in the test runner.
+test_x86_emulator.o: HOSTCFLAGS += -Og
+
 test_x86_emulator.o: $(addsuffix .h,$(TESTCASES)) $(addsuffix -opmask.h,$(OPMASK))
-- 
2.47.3

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

[Jan Beulich]

On 09.03.2026 11:41, 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: reduce 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.
> However for debugging -Og is recommended over -O0, and this still
> avoids the duplicate label problem.
> 
> Signed-off-by: Edwin Török <edwin.torok@citrix.com>

With the subject also switched to say -Og (will adjust while committing):
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan

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

[Roger Pau Monné]

On Mon, Mar 09, 2026 at 10:41:35AM +0000, 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: reduce 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.
> However for debugging -Og is recommended over -O0, and this still
> avoids the duplicate label problem.
> 
> Signed-off-by: Edwin Török <edwin.torok@citrix.com>

Building the x86 emulator test harness is currently gated on:

ifneq ($(clang),y)
SUBDIRS-$(CONFIG_X86) += x86_emulator
endif

So I think there should be a further patch (or done here) that removed
this check.  And then we should also run the test harness from one of
the LLVM FreeBSD builds ideally.

Have you tested with a full LLVM based toolchain (so also using LLVM
linker?)

Thanks, Roger.

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

[Edwin Torok]

> On 9 Mar 2026, at 14:15, Roger Pau Monne <roger.pau@citrix.com> wrote:
> 
> On Mon, Mar 09, 2026 at 10:41:35AM +0000, 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: reduce 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.
>> However for debugging -Og is recommended over -O0, and this still
>> avoids the duplicate label problem.
>> 
>> Signed-off-by: Edwin Török <edwin.torok@citrix.com>
> 
> Building the x86 emulator test harness is currently gated on:
> 
> ifneq ($(clang),y)
> SUBDIRS-$(CONFIG_X86) += x86_emulator
> endif

Good point, I haven’t spotted that.
Although I don’t think that flag is set if you set CC=clang/HOSTCC=clang instead of using clang=y.
(I only discovered clang=y after I started fixing some clang build failures).

> 
> So I think there should be a further patch (or done here) that removed
> this check.
>  And then we should also run the test harness from one of
> the LLVM FreeBSD builds ideally.


Running with clang would currently fail.
See https://lore.kernel.org/xen-devel/10B1B7D9-352F-4203-AC30-88EF674114F5@citrix.com/
Until a (better) solution is found for that, if I remove the gate then I assume the CI would fail?

I think it’d be useful to enable build-testing with clang though, so I could remove the SUBDIRS gate,
and introduce a gate on the tests/x86_emulator/Makefile:run rule instead?

> 
> Have you tested with a full LLVM based toolchain (so also using LLVM
> linker?)

No, the clang I’m using is configured to use the binutils linker by default.

Best regards,
—Edwin