On Wed, Nov 19, 2025 at 11:49:23PM -0700, Nathan Chancellor wrote: > 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?
Honestly, I'm not sure yet. I think if we find it to be true, we can add it then. So far, everything I've found works with =1, but I went with =2 just to be conservative. (And I did build time comparisons -- there is no measurable difference between off, 1, or 2.) > > 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. Yeah, I can list some of the prior fixes. > > 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. I regularly have gcc.gnu.org time out for me, so I've been using github for trees and references, but I can change this. > > > Signed-off-by: Kees Cook <[email protected]> > > --- > > Reviewed-by: Nathan Chancellor <[email protected]> Thanks! > Should we take this via Kbuild or do you want to take it via the > hardening tree? I figured I'd take it via the hardening tree, but I have no strong rationale for that. ;) -Kees -- Kees Cook
