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

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

[Namhyung Kim]

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>
> ---
> Resent to linux-kbuild mailing list.
> ---
>  tools/scripts/Makefile.include | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
> index b5ecf137febcae59f506e107a7f2e2ad72f4bef4..73f6aef4f3fda0cda7ee8f4b9a3b7ff7d956070d 100644
> --- a/tools/scripts/Makefile.include
> +++ b/tools/scripts/Makefile.include
> @@ -40,6 +40,30 @@ EXTRA_WARNINGS += -Wwrite-strings
>  EXTRA_WARNINGS += -Wformat
>  EXTRA_WARNINGS += -Wno-type-limits
>  
> +# output directory for tests below
> +TMPOUT = .tmp_$$$$
> +
> +# try-run
> +# Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise)
> +# Exit code chooses option. "$$TMP" serves as a temporary file and is
> +# automatically cleaned up.
> +try-run = $(shell set -e;		\
> +	TMP=$(TMPOUT)/tmp;		\
> +	trap "rm -rf $(TMPOUT)" EXIT;	\
> +	mkdir -p $(TMPOUT);		\
> +	if ($(1)) >/dev/null 2>&1;	\
> +	then echo "$(2)";		\
> +	else echo "$(3)";		\
> +	fi)
> +
> +# 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))
> +
> +# Explicitly clear padding bits with the initializer '{ 0 }'
> +CFLAGS += $(call cc-option,-fzero-init-padding-bits=all)
> +
>  # Makefiles suck: This macro sets a default value of $(2) for the
>  # variable named by $(1), unless the variable has been set by
>  # environment or command line. This is necessary for CC and AR
> 
> ---
> base-commit: 7dff99b354601dd01829e1511711846e04340a69
> change-id: 20260224-tools_build_fix_zero_init-dc5261bd8b8b
> 
> Best regards,
> -- 
> Leo Yan <leo.yan@arm.com>
> 

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

[Quentin Monnet]

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.

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. The same
concern could apply to perf with HOSTCFLAGS, by the way?

Best regards,
Quentin


Note: For fellow bpf@ readers, the original thread is at
https://lore.kernel.org/linux-kbuild/aaCTC86U9KjnmZmu@google.com/T/#m700907de1a84c007bfda62981af590ad7aed0f11

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

[Leo Yan]

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.

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.

Thanks,
Leo

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

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

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

[Namhyung Kim]

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

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

[Quentin Monnet]

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

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

[Namhyung Kim]

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

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

[Leo Yan]

On Tue, Mar 03, 2026 at 05:35:04PM -0800, Namhyung Kim wrote:

[...]

> > 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?

Yes, I will prepare a new patch series.

Also thanks Quentin's detailed suggestions.

Leo