mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 18:21:39 +01:00
Christopher Clark
e8dfbc2962
Workaround for compiler rejection of SSE-using always_inlines defined before
SSE is disabled.
Compiling with _FORTIFY_SOURCE or higher levels of optimization enabled
will always_inline several library fns (memset, memcpy, ...)
(with gcc 8.2.0 and glibc 2.28).
In fuzz and x86_emulator test, the compiler is instructed not
to generate SSE instructions via: #pragma GCC target("no-sse")
because those registers are needed for use by the workload.
The combination above causes compilation failure as the inline functions
use those instructions. This is resolved by reordering the inclusion of
<stdio.h> and <string.h> to after the pragma disabling SSE generation.
It would be preferable to locate the no-sse pragma within x86-emulate.h at the
top of the file, prior to including any other headers; unfortunately doing so
before <stdlib.h> causes compilation failure due to declaration of 'atof' with:
"SSE register return with SSE disabled".
Fortunately there is no (known) current dependency on any always_inline
SSE-inclined function declared in <stdlib.h> or any of its dependencies, so the
pragma is therefore issued immediately after inclusion of <stdlib.h> with a
comment introduced to explain its location there.
Add compile-time checks for unwanted prior inclusion of <string.h> and
<stdio.h>, which are the two headers that provide the library functions that
are handled with wrappers and listed within "x86-emulate.h" as ones "we think
might access any of the FPU state".
* Use standard-defined "EOF" macro to detect prior <stdio.h> inclusion.
* Use "_STRING_H" (non-standardized guard macro) as best-effort
for detection of prior <string.h> inclusion. This is non-universally
viable but will provide error output on common GLIBC systems, so
provides some defensive coverage.
Adds conditional #include <stdio.h> to x86-emulate.h because fwrite, printf,
etc. are referenced when WRAP has been defined.
Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
# OVERVIEW This directory provides fuzzing targets to be run inside Google oss-fuzz infrastructure. See also https://github.com/google/oss-fuzz. # HOW IT WORKS We need to provide the source code and the rune to produce objects or archives (artefacts) from source code. These items ideally should live inside xen.git so that they can be kept up to date. The artefacts contain all the code we wish to fuzz and a function called LLVMFuzzerTestOneInput. LLVMFuzzerTestOneInput is the entry point to the code we wish to fuzz. Note that we don't produce executable programs because we don't have libFuzzEngine locally. libFuzzEngine is maintained by oss-fuzz. We also provide build script to oss-fuzz. The build script will inherit the correct compiler settings and be run in a pre-setup environment, which has libFuzzEngine installed. The build script is responsible for calling the correct Xen build rune to produce the artefacts, then link them against libFuzzEngine to produce executables, which will run in oss-fuzz infrastructure. Please refer to official oss-fuzz documents for the most up-to-date descriptions for all moving parts. # HOW TO IMPROVE THE FUZZING TARGETS Feel free to modify each fuzzing targets at will. Make sure they build by invoking make as you would build tools. To actually test the new code, you would need to run the target in standalone mode, please refer to oss-fuzz documents on how to do that. It is highly recommended that you run the new target for a while to weed out error in plumbing code to avoid false positives.