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

[Namhyung Kim <namhyung@kernel.org>]

On Wed, Mar 04, 2026 at 02:28:05AM +0100, Quentin Monnet wrote:
> 2026-03-03 17:14 UTC-0800 ~ 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
> 
> 
> Hi Namhyung
> 
> (I'm not entirely sure what v1/v2 refer to, this one was tagged v2 and I
> suspect v1 was the first post before the resend - I suppose you mean
> this one is v1 and a v2 would be with an additional host variable.)

Oops, right.  They should be v2 and v3.

> 
> I don't want bpftool's HOST_CFLAGS to inherit
> -fzero-init-padding-bits=all if the compiler doesn't support it, which
> may happen with the current version of the patch. I'd prefer a version
> with separate EXTRA_CFLAGS and HOST_EXTRA_CFLAGS, as proposed by Leo and
> discussed above, to address the cross-compilation issue.

Got it.  Leo, can you please update the patch?

Thanks,
Namhyung