build: add Wswitch to clang for more consistency with gcc

[rscheff]

Summary

gcc12 and gcc13 appear to include Wswitch with Wall, while
clang doesn't.

For switch() statements on enum, this forces the use of at
least a default: clause, in adherance with style(9).

[emaste]

Makes sense to me. Have you tested make tinderbox?

[karels]

Does -Wswitch require a default if all values of an enum are explicitly included? I don't know if that is common though.

[rscheff]

Unfortunately, my box here is too small to build serveral universes.

My understanding is that some universes already use gcc12, gcc13 and clang - so the probability is high there there aren't any issues showing up by this.

I only bumped into that venn region where the implicit acceptance of int32 for enum (gcc12, clang) combined with clang not warning about incomplete switch() evaluations of enums, caused trouble (see
f74352fbcf15341accaf5a92240871f98323215d
5e248c23d995a059d24f4784d5a256cddd42e557
c9b6241e250a4f1156e2150ccdbad0d3029dcef6
8917131e00b0fcd47113bdf3fa8f9b01d6c7f8da
)
Thats certainly because of oversights and rushing (after corrupting the build process) on my part, but in part not caught by local (clang) build jobs due to the suble difference between these compilers; the other major one (-Wenum-int-mismatch) currenly doesn't seem to have an equivalent in clang (I submitted https://github.com/llvm/llvm-project/issues/82972 ).

In order to evaluate any possible compler warning differences, this is the command I'll be using to excercise the gcc13 toolchain in the future:

make -j4 buildkernel KERNCONF=GENERIC WERROR=-Wenum-int-mismatch TARGET_ARCH=amd64 CROSS_TOOLCHAIN=amd64-gcc13

[rscheff]

In D44092#1005876, @karels wrote:

Does -Wswitch require a default if all values of an enum are explicitly included? I don't know if that is common though.

I believe thats the -Wswitch-enum per http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

-Wswitch Warn whenever a switch statement has an index of enumerated type and lacks a case for one or more of the named codes of that enumeration. (The presence of a default label prevents this warning.) case labels outside the enumeration range also provoke warnings when this option is used (even if there is a default label). This warning is enabled by -Wall.

-Wswitch-enum Warn whenever a switch statement has an index of enumerated type and lacks a case for one or more of the named codes of that enumeration. case labels outside the enumeration range also provoke warnings when this option is used.

Interestingly, the clang documentation claims that -Wswitch is enabled by default - but somehow it obviously gets disabled in the settings used for building the kernel, as I had the misfortune to discover.

https://clang.llvm.org/docs/DiagnosticsReference.html#wswitch

[rscheff]

In D44092#1005867, @emaste wrote:

Makes sense to me. Have you tested make tinderbox?

I've got myself a proper build vm - but make tinderbox fails already on MAIN commit 865baeaf1abeb14327ad6a4a1f8ce722e242ff73, without the above change. I don't know about any the other arch/platform combinations, since the first error stops the entire build...

How shall I proceed, since this doesn't appear to be (directly) related to the issue around enum/int mix-ups and requiring either a default or all enums in a switch{} statement?

• vmm_hyp_exception.o ---

cc -target aarch64-unknown-freebsd15.0 --sysroot=/usr/obj/root/freebsd-master/usr/src/arm64.aarch64/tmp -B/usr/obj/root/freebsd-master/usr/src/arm64.aarch64/tmp/usr/bin -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-common -DVMM_KEEP_STATS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -nostdinc -I/root/freebsd-master/usr/src/sys/arm64/vmm -I/root/freebsd-master/usr/src/sys/arm64/vmm/io -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/root/freebsd-master/usr/src/arm64.aarch64/sys/GENERIC-KMSAN/opt_global.h -I. -I/root/freebsd-master/usr/src/sys -I/root/freebsd-master/usr/src/sys/contrib/ck/include -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC -fdebug-prefix-map=./machine=/root/freebsd-master/usr/src/sys/arm64/include -I/usr/obj/root/freebsd-master/usr/src/arm64.aarch64/sys/GENERIC-KMSAN -DSAN_NEEDS_INTERCEPTORS -DSAN_INTERCEPTOR_PREFIX=kmsan -fno-sanitize-memory-param-retval -mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=0 -MD -MF.depend.vmm_hyp_exception.o -MTvmm_hyp_exception.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-4 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -Dprintf=freebsd_kprintf -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length -std=gnu99 /root/freebsd-master/usr/src/sys/arm64/vmm/vmm_hyp_exception.S -o vmm_hyp_exception.o -fpie
cc: error: argument unused during compilation: '-fno-sanitize-memory-param-retval' [-Werror,-Wunused-command-line-argument]

• all_subdir_usb ---
• all_subdir_usb/template ---

> usb/template (all)

• all_subdir_vmm ---
• [vmm_hyp_exception.o] Error code 1

[rscheff]

MAIN e0dfecadf5946b6a8ad423be4eb1c14017b3a8a7 errors on make tinderbox with the same error:

cc: error: argument unused during compilation: '-fno-sanitize-memory-param-retval' [-Werror,-Wunused-command-line-argument]

• [vmm_hyp_exception.o] Error code 1

[rscheff]

In D44092#1005867, @emaste wrote:

Makes sense to me. Have you tested make tinderbox?

@tuexen and I have now run make universe and make tinderbox on HEAD multiple times, with and without this change, on two different platforms (native and cross compiles). This change is benign and none of the builds are complaining.

However, the amd64 KMSAN build keeps on failing (also with a compiler option issue apparently) in our machines.

Interestingly, looking at a recent build of amd64-KMSAN on ci.freebsd.org, there is no hint of vmm_hyp_exception.o being compiled.... So I have no idea what to make of this...

_.arm64.GENERIC-KMSAN:* [vmm_hyp_exception.o] Error code 1
_.arm64.GENERIC-KMSAN:* [modules-all] Error code 2

---

_.arm64.GENERIC-KMSAN-cc: note: diagnostic msg: /tmp/ah_osdep-210172.c
_.arm64.GENERIC-KMSAN-cc: note: diagnostic msg: /tmp/ah_osdep-210172.sh
_.arm64.GENERIC-KMSAN-cc: note: diagnostic msg:
_.arm64.GENERIC-KMSAN-
_.arm64.GENERIC-KMSAN-****
_.arm64.GENERIC-KMSAN:*** [ah_osdep.o] Error code 1
_.arm64.GENERIC-KMSAN-
_.arm64.GENERIC-KMSAN-make[7]: stopped in /usr/home/tuexen/freebsd-src/sys/modules/ath_hal
_.arm64.GENERIC-KMSAN-1 error
_.arm64.GENERIC-KMSAN-

_.arm64.GENERIC-KMSAN-make[7]: stopped in /usr/home/tuexen/freebsd-src/sys/modules/ath_hal

_.arm64.GENERIC-KMSAN-ld -m aarch64elf -Bshareable -znotext -znorelro -warn-common --build-id=sha1 --no-relax -o atapci.ko.full atapci.kld
_.arm64.GENERIC-KMSAN---- atapci.ko.debug --- _.arm64.GENERIC-KMSAN-objcopy --only-keep-debug atapci.ko.full atapci.ko.debug
_.arm64.GENERIC-KMSAN---- atapci.ko ---
_.arm64.GENERIC-KMSAN-objcopy --strip-debug --add-gnu-debuglink=atapci.ko.debug atapci.ko.full atapci.ko
_.arm64.GENERIC-KMSAN:*** [modules-all] Error code 2
_.arm64.GENERIC-KMSAN-
_.arm64.GENERIC-KMSAN-make[5]: stopped in /usr/obj/usr/home/tuexen/freebsd-src/arm64.aarch64/sys/GENERIC-KMSAN
_.arm64.GENERIC-KMSAN-1 error
_.arm64.GENERIC-KMSAN-
_.arm64.GENERIC-KMSAN-make[5]: stopped in /usr/obj/usr/home/tuexen/freebsd-src/arm64.aarch64/sys/GENERIC-KMSAN

Who is maintaining this "KMSAN" compilation,

[dim]

KMSAN is @markj I believe? Though it looks like you're getting a clang assertion there. So what is the clang version being used?

[rscheff]

In D44092#1013944, @dim wrote:

KMSAN is @markj I believe? Though it looks like you're getting a clang assertion there. So what is the clang version being used?

Whatever is in HEAD; currently, it is probably

FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367)
Target: x86_64-unknown-freebsd15.0
Thread model: posix
InstalledDir: /usr/bin

[markj]

In D44092#1013944, @dim wrote:

KMSAN is @markj I believe? Though it looks like you're getting a clang assertion there. So what is the clang version being used?

This is a silly artifact of the fact that we have to filter both "-fsanitize*" and "-fno-sanitize*" for some files. The problem is fixed in main now, 26173a919ced6179aa758db44fffc3bcac532be6