Re: Build errors with fuzz/x86_instruction_emulator harness

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/08/2023 4:21 pm, Jan Beulich wrote:
> 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.

It turns out it was GCC 12 not GCC 13.  Things build cleanly with no LTO.

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

Indeed.  While I don't particularly care for the fuzzing harness (It's a
little dubious that it builds by default but doesn't install anything),
the main emulator harness does need to function properly.  That gets
widespred use in testing.

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

--wrap= each symbol, except when compiling wrappers.c ?

This seems to be the normal way to mock out functions including malloc()
and friends.

~Andrew