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
