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

[Quentin Monnet <qmo@kernel.org>]

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.)

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.

Thanks,
Quentin