[PATCH v3 0/1] avoid duplicate symbol errors with clang

[PATCH v3 0/1] avoid duplicate symbol errors with clang

[Edwin Török]

The previous attempt with .ifndef is not necessarily always correct,
and may lead to subtle bugs. The instructions executed from the
emulator would always come from the first (and now only) labeled block.
Although the approach worked with the existing tests, it may have broken
again when more instructions are added in the future.

Using -O0 achieves the same outcome as the .ifndef patch (being able to
compile the tests with clang), without the drawbacks.
Only added -O0 to the test runner code, which is not performance
critical.

This is a workaround, if a better solution is found then this can be
removed.

Edwin Török (1):
  tools/tests/x86_emulator: avoid duplicate symbol error with clang: use
    -O0

 tools/tests/x86_emulator/Makefile | 5 +++++
 1 file changed, 5 insertions(+)

-- 
2.47.3

[PATCH v3 1/1] 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: 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.

Signed-off-by: Edwin Török <edwin.torok@citrix.com>
---
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 | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile
index 5003c464f3..ba1d27177f 100644
--- 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
+
 test_x86_emulator.o: $(addsuffix .h,$(TESTCASES)) $(addsuffix -opmask.h,$(OPMASK))
-- 
2.47.3

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

[Jan Beulich]

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

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

[Edwin Torok]

> On 9 Mar 2026, at 07:47, Jan Beulich <jbeulich@suse.com> 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

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

[Jan Beulich]

On 09.03.2026 10:49, Edwin Torok wrote:
>> On 9 Mar 2026, at 07:47, Jan Beulich <jbeulich@suse.com> wrote:
>> 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."

And did you check that -Og works for the purposes here? I'd indeed prefer to
use that, if we can.

>> 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.

Of course.

Jan

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

[Edwin Torok]

> On 9 Mar 2026, at 10:20, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 09.03.2026 10:49, Edwin Torok wrote:
>>> On 9 Mar 2026, at 07:47, Jan Beulich <jbeulich@suse.com> wrote:
>>> 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."
> 
> And did you check that -Og works for the purposes here? I'd indeed prefer to
> use that, if we can.


It avoids the duplicate symbol error with version of Clang that I have, so I have sent a V4 that uses -Og and the updated comments.
Was a bit worried this might not work with old GCCs, but AFAICT Og is supported since 4.8, and the minimum is 5.1.

Best regards,
—Edwin

> 
>>> 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.
> 
> Of course.
> 
> Jan