By default GCC uses "simple" coverage counter update
mechanism. It is perfectly fine for single-threaded (or single CPU in
our case) setups, but will cause race conditions on SMP systems.
For example, I observed that counters are going backwards when running
Xen inside QEMU.
GCC starting from version 7 and LLVM/Clang starting from version 11
support -fprofile-update=atomic option, which forces coverage counter
updates to be atomic, which resolves the issue. As Xen runs mostly on
SMP systems, force use this option if it is supported by a compiler.
Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com>
---
Changes in v2:
- Use $(cc-option-add) instead of a Kconfig variable
---
xen/Rules.mk | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index da21850926..24f447b957 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -141,6 +141,9 @@ else
cov-cflags-$(CONFIG_CONDITION_COVERAGE) += -fcondition-coverage
endif
+# Ensure that profile/coverage data is updated atomically
+$(call cc-option-add,cov-cflags-$(CONFIG_COVERAGE),CC,-fprofile-update=atomic)
+
# Reset cov-cflags-y in cases where an objects has another one as prerequisite
$(nocov-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)): \
cov-cflags-y :=
--
2.50.0
