On Wed, Nov 19, 2025 at 02:44:31PM -0800, Kees Cook wrote: > Enable GCC 16's coming "-fdiagnostics-show-context=2" option[1] to > provide enhanced diagnostic information for value-tracking warnings, which > displays the control flow chain leading to the diagnostic. This covers our > existing use of -Wrestrict and -Wstringop-overread, and gets us closer to > enabling -Warray-bounds, -Wstringop-overflow, and -Wstringop-truncation. > > The context depth of 2 provides the immediate decision path that led to > the problematic code location, showing conditional checks and branch > decisions that caused the warning. This will help us understand why > GCC's value-tracking analysis triggered the warning and makes it easier > to determine whether warnings are legitimate issues or false positives.
Would we ever want a depth more than 2? In other words, should this be customizable in case there is a warning that needs more context? > For example, an array bounds warning will now show the conditional > statements (like "if (i >= 4)") that established the out-of-bounds access > range, directly connecting the control flow to the warning location. > This is particularly valuable when GCC's interprocedural analysis can > generate warnings that are difficult to understand without seeing the > inferred control flow. Not that it is that different from what you describe here but having an actual example of the insight that this gives using a problematic case from the past (such as one that resulted in these various warnings getting disabled) might be useful for future travellers. > Link: > https://github.com/gcc-mirror/gcc/commit/6faa3cfe60ff9769d1bebfffdd2c7325217d7389 > [1] I have a small preference for using links that the project controls, i.e. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6faa3cfe60ff9769d1bebfffdd2c7325217d7389 but I am guessing that mirror is not going anywhere and we have the hash regardless so consider it a nit. > Signed-off-by: Kees Cook <[email protected]> > --- Reviewed-by: Nathan Chancellor <[email protected]> Should we take this via Kbuild or do you want to take it via the hardening tree? > --- > Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Makefile b/Makefile > index d14824792227..d97452441cd0 100644 > --- a/Makefile > +++ b/Makefile > @@ -940,6 +940,9 @@ KBUILD_CFLAGS += $(call > cc-option,-fzero-init-padding-bits=all) > # for the randomize_kstack_offset feature. Disable it for all compilers. > KBUILD_CFLAGS += $(call cc-option, -fno-stack-clash-protection) > > +# Get details on warnings generated due to GCC value tracking. > +KBUILD_CFLAGS += $(call cc-option, -fdiagnostics-show-context=2) > + > # Clear used registers at func exit (to reduce data lifetime and ROP > gadgets). > ifdef CONFIG_ZERO_CALL_USED_REGS > KBUILD_CFLAGS += -fzero-call-used-regs=used-gpr > -- > 2.34.1 >
