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

[Edwin Torok <edwin.torok@xxxxxxxxxx>]

> On 9 Mar 2026, at 14:15, Roger Pau Monne <roger.pau@xxxxxxxxxx> 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@xxxxxxxxxx>
> 
> 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@xxxxxxxxxx/
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