Re: Build errors with fuzz/x86_instruction_emulator harness

[Jan Beulich <jbeulich@xxxxxxxx>]

On 14.08.2023 16:52, Andrew Cooper wrote:
> See the attached log snippet.  This is current staging, with a GCC 13
> toolchain.
> 
> First of all, a minor issue.  Counting the number of
> `-D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__`'s, we
> have included CFLAGS on the CC line 4 times.  This is something that
> appears to be in common with all of tools/ and is probably the primary
> contributor to exceeding the Gitlab CI 4M log limit...
> 
> Next the error.  This doesn't build when CFLAGS coming in from the
> packaging environment include `-flto=auto`.
> 
> Clearly our wrapping trick doesn't work with LTO, but it's not obvious why.
> 
> readelf -Wa tools/fuzz/x86_instruction_emulator/wrappers.o | grep emul_
>   [223] .gnu.lto_emul_fwrite.38.43da3a7fd30cc0a1 PROGBITS       
> 0000000000000000 01c2ec 000194 00   E  0   0  1
>   [224] .gnu.lto_emul_memcmp.39.43da3a7fd30cc0a1 PROGBITS       
> 0000000000000000 01c480 0001a7 00   E  0   0  1
>   [225] .gnu.lto_emul_memcpy.40.43da3a7fd30cc0a1 PROGBITS       
> 0000000000000000 01c627 000175 00   E  0   0  1
>   [226] .gnu.lto_emul_memset.41.43da3a7fd30cc0a1 PROGBITS       
> 0000000000000000 01c79c 000186 00   E  0   0  1
>   [227] .gnu.lto_emul_printf.42.43da3a7fd30cc0a1 PROGBITS       
> 0000000000000000 01c922 0002cd 00   E  0   0  1
>   [228] .gnu.lto_emul_putchar.43.43da3a7fd30cc0a1 PROGBITS       
> 0000000000000000 01cbef 000216 00   E  0   0  1
>   [229] .gnu.lto_emul_puts.44.43da3a7fd30cc0a1 PROGBITS       
> 0000000000000000 01ce05 000180 00   E  0   0  1
> 
> shows that there's something relevant in the object file.

But only sections, no symbols. Doing a simple test with a trivial source
file, I observe that no actual code is emitted at all, and hence also no
symbols. Which means our trick - working entirely behind the back of the
compiler by inserting .equ in the assembly output - takes no effect on
our own sources. And really the errors in the log fragment you provided
all point back to standard library headers, where (just a guess)
something may be done that cause _some_ code to be emitted, for which
our overrides then take effect.

> Manual poking about in the build environment indicates that
> tools/tests/x86_instruction_emulator is similarly impacted.
> 
> Any ideas?
> 
> Obviously we can inhibit LTO for the x86_emul userspace, but that ought
> to be a last resort.

To get the build issue addressed, merely suppressing LTO for wrappers.o
may suffice (provided such mixing is permitted in the first place).
However, due to our overrides not taking effect (as per above) I can't
see how the resulting binaries then would work correctly.

Question therefore is whether we can find a way of effecting the needed
overrides (including for compiler generated calls) without resorting to
emitting .equ (or alike), and hence without doing it fully behind the
compiler's back.

Jan