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

[Quentin Monnet]

2026-02-27 10:36 UTC+0000 ~ Leo Yan <leo.yan@xxxxxxx>
> On Thu, Feb 26, 2026 at 10:52:01PM +0000, Quentin Monnet wrote:
>> 2026-02-26 10:38 UTC-0800 ~ Namhyung Kim <namhyung@xxxxxxxxxx>
>>> 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@xxxxxxx>
>>
>>
>> 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.

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