Re: [PATCH RESEND v2] tools build: Use -fzero-init-padding-bits=all

[Namhyung Kim <namhyung@kernel.org>]

Hello,

On Fri, Feb 27, 2026 at 11:52:38AM +0000, Quentin Monnet wrote:
> 2026-02-27 10:36 UTC+0000 ~ Leo Yan <leo.yan@arm.com>
> > On Thu, Feb 26, 2026 at 10:52:01PM +0000, Quentin Monnet wrote:
> >> 2026-02-26 10:38 UTC-0800 ~ Namhyung Kim <namhyung@kernel.org>
> >>> Adding bpftool maintainer.
> >>>
> >>> On Tue, Feb 24, 2026 at 12:16:40PM +0000, Leo Yan wrote:
> >>>> GCC-15 release claims [1]:
> >>>>
> >>>>   {0} initializer in C or C++ for unions no longer guarantees clearing
> >>>>   of the whole union (except for static storage duration initialization),
> >>>>   it just initializes the first union member to zero. If initialization
> >>>>   of the whole union including padding bits is desirable, use {} (valid
> >>>>   in C23 or C++) or use -fzero-init-padding-bits=unions option to
> >>>>   restore old GCC behavior.
> >>>>
> >>>> As a result, this new behaviour might cause unexpected data when we
> >>>> initialize a union with using the '{ 0 }' initializer.
> >>>>
> >>>> Since commit dce4aab8441d ("kbuild: Use -fzero-init-padding-bits=all"),
> >>>> the kernel has enabled -fzero-init-padding-bits=all to zero padding bits
> >>>> in unions and structures.  This commit applies the same option for tools
> >>>> building.
> >>>>
> >>>> The option is not supported neither by any version older than GCC 15 and
> >>>> is also not supported by LLVM, this patch adds the cc-option function to
> >>>> dynamically detect the compiler option.
> >>>>
> >>>> [1] https://gcc.gnu.org/gcc-15/changes.html
> >>>>
> >>>> Signed-off-by: Leo Yan <leo.yan@arm.com>
> >>
> >>
> >> Thank you Namhyung for the Cc.
> >>
> >> I built bpftool with the patch, with gcc 13 (which didn't get the flag,
> >> as expected) and gcc 15, and it's fine with both. As far as I can tell,
> >> bpftool does not initialise any union with "{0}" anyway.
> > 
> > Thanks a lot for testing!
> > 
> >> One potential concern (I didn't try) could be for cross-compilation:
> >> bpftool's Makefile sets HOST_CFLAGS based on $(CFLAGS), but $(HOSTCC)
> >> and $(CC) could be different versions of gcc, for example.
> > 
> > To avoid confusion, we can use EXTRA_CFLAGS and HOST_EXTRACFLAGS instead
> > in Makefile.include:
> > 
> > -----
> > 
> > # cc-option
> > # Usage: CFLAGS += $(call cc-option,-march=winchip-c6,-march=i586)
> > cc-option = $(call try-run, \
> >        $(CC) -Werror $(1) -c -x c /dev/null -o "$$TMP",$(1),$(2))
> > 
> > host-cc-option = $(call try-run, \
> >        $(HOSTCC) -Werror $(1) -c -x c /dev/null -o "$$TMP",$(1),$(2))
> > 
> > # Explicitly clear padding bits with the initializer '{ 0 }'
> > EXTRA_CFLAGS += $(call cc-option,-fzero-init-padding-bits=all)
> > HOST_EXTRACFLAGS += $(call host-cc-option,-fzero-init-padding-bits=all)
> > 
> > -----
> > 
> > Then, in a project, its Makefile can append EXTRA_CFLAGS and
> > HOST_EXTRACFLAGS to CFLAGS and HOSTCFLAGS respectively.
> 
> 
> This sounds like it should work for bpftool as long as we += and don't
> overwrite the EXTRA_CFLAGS passed from command line. In bpftool's
> Makefile we'd have to move HOST_CFLAGS's CFLAGS-based defintion higher
> up, before we add the EXTRA_CFLAGS to CFLAGS; and if anything needs to
> be passed to the host binary, users will have to specify
> HOST_EXTRACFLAGS (or HOST_EXTRA_CFLAGS?) independently, which is acceptable.

Quentin, do you want v2 with this or just ok for v1?

Thanks,
Namhyung

> 
> Out of curiosity I looked at other tools, and of course everyone does it
> differently:
> 
> - Some of them, like bpftool, reuse the CFLAGS inherited from
> tools/scripts/Makefile.include, adding EXTRA_CFLAGS to it, so setting
> aside cross-compiling, both approaches (using CFLAGS or EXTRA_CFLAGS)
> are fine.
> 
> - Some of them, such as tools/lib/bpf/Makefile for example, reset CFLAGS
> before/by adding EXTRA_CFLAGS, so your v2 relying on CFLAGS would
> probably have no effect for them.
> 
> - Some of them, such as tools/tracing/latency/Makefile or
> tools/mm/Makefile, do not use EXTRA_CFLAGS - maybe it's worth adding it
> if your objective is to pass the flag to all/most tools.
> 
> - (Also many smaller Makefiles such as most of the ones in selftests do
> not pull tools/scripts/Makefile.include at all, but I suppose this is
> out of scope.)
> 
> 
> > If this is fine for us, I will repin patches
> > 
> >> The same concern could apply to perf with HOSTCFLAGS, by the way?
> > 
> > I don't see perf's HOSTCFLAGS to reuse CFLAGS.
> 
> 
> Woops I can't see the HOSTCFLAGS using the CFLAGS either for perf, sorry
> about that.
> 
> Thanks,
> Quentin