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

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

[Leo Yan]

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

[Nathan Chancellor]

Hi Leo,

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.

Kbuild does not maintain/touch tools/. This should go via another tree
like perf or something. It does not look like
tools/scripts/Makefile.include has a clear owner, perf and bpf tend to
be the ones who touch it the most.

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

[Kees Cook]

On Tue, Feb 24, 2026 at 10:19:56AM -0700, Nathan Chancellor wrote:
> Hi Leo,
> 
> 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.
> 
> Kbuild does not maintain/touch tools/. This should go via another tree
> like perf or something. It does not look like
> tools/scripts/Makefile.include has a clear owner, perf and bpf tend to
> be the ones who touch it the most.

You could claim it! ;)

Regardless, I like to see cc-option available here, as I doubt this will
be the last conditional option for tool builds. (Actually, are there
other conditional options that could use this today in the tools
Makefiles?)

-Kees

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

-- 
Kees Cook

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

[Leo Yan]

On Tue, Feb 24, 2026 at 01:11:19PM -0800, Kees Cook wrote:
> On Tue, Feb 24, 2026 at 10:19:56AM -0700, Nathan Chancellor wrote:
> > Hi Leo,
> > 
> > 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.
> > 
> > Kbuild does not maintain/touch tools/. This should go via another tree
> > like perf or something. It does not look like
> > tools/scripts/Makefile.include has a clear owner, perf and bpf tend to
> > be the ones who touch it the most.

This is a circular deadlock.  Namhyung (the perf maintainer) advised me
to send patch to the linux-kbuild [1], for fixing an union init issue
found recently.

> You could claim it! ;)
> 
> Regardless, I like to see cc-option available here, as I doubt this will
> be the last conditional option for tool builds. (Actually, are there
> other conditional options that could use this today in the tools
> Makefiles?)

Some subprojects in tools have their own conditional options.

This patch is ambitious that it changes the global Makefile.include file
so it can propagate the '-fzero-init-padding-bits=all' option to
projects that include it.  Why do we need to do this globally?  This is
because Perf needs to build several subprojects (libperf and bpftool).

Thanks,
Leo

[1] https://lore.kernel.org/linux-perf-users/20260224122054.GB4184494@e132581.arm.com/T/#ma07fc114e84254d0173490409955e9d3bea147be

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

[Nathan Chancellor]

On Wed, Feb 25, 2026 at 09:22:10AM +0000, Leo Yan wrote:
> On Tue, Feb 24, 2026 at 01:11:19PM -0800, Kees Cook wrote:
> > On Tue, Feb 24, 2026 at 10:19:56AM -0700, Nathan Chancellor wrote:
> > > Kbuild does not maintain/touch tools/. This should go via another tree
> > > like perf or something. It does not look like
> > > tools/scripts/Makefile.include has a clear owner, perf and bpf tend to
> > > be the ones who touch it the most.
> 
> This is a circular deadlock.  Namhyung (the perf maintainer) advised me
> to send patch to the linux-kbuild [1], for fixing an union init issue
> found recently.

The tools/ build system is not Kbuild, so I do not want to take patches
for it, sorry. Issues from patches I take become my responsibility to
deal with and I am not at all familiar with the tools build system
because I am not a consumer of it. Nicolas may feel differently but I am
going to assume not based on his level of expertise with tools/ [1]. I
am not trying to deadlock you though.

Namhyung, I think this patch can reasonably go via the perf tree since
it will be a primary consumer of it.

> > You could claim it! ;)

Heh, Kbuild and ClangBuiltLinux give me more than enough to do around
here ;)

> > Regardless, I like to see cc-option available here, as I doubt this will
> > be the last conditional option for tool builds. (Actually, are there
> > other conditional options that could use this today in the tools
> > Makefiles?)
> 
> Some subprojects in tools have their own conditional options.
> 
> This patch is ambitious that it changes the global Makefile.include file
> so it can propagate the '-fzero-init-padding-bits=all' option to
> projects that include it.  Why do we need to do this globally?  This is
> because Perf needs to build several subprojects (libperf and bpftool).

This seems like a great reason for it to go via the perf tree as noted
above.

[1]: https://lore.kernel.org/aNhGp7NDCCrtwJqm@levanger/

Cheers,
Nathan

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

[Namhyung Kim]

Hello,

On Wed, Feb 25, 2026 at 12:25:05PM -0700, Nathan Chancellor wrote:
> On Wed, Feb 25, 2026 at 09:22:10AM +0000, Leo Yan wrote:
> > On Tue, Feb 24, 2026 at 01:11:19PM -0800, Kees Cook wrote:
> > > On Tue, Feb 24, 2026 at 10:19:56AM -0700, Nathan Chancellor wrote:
> > > > Kbuild does not maintain/touch tools/. This should go via another tree
> > > > like perf or something. It does not look like
> > > > tools/scripts/Makefile.include has a clear owner, perf and bpf tend to
> > > > be the ones who touch it the most.
> > 
> > This is a circular deadlock.  Namhyung (the perf maintainer) advised me
> > to send patch to the linux-kbuild [1], for fixing an union init issue
> > found recently.
> 
> The tools/ build system is not Kbuild, so I do not want to take patches
> for it, sorry. Issues from patches I take become my responsibility to
> deal with and I am not at all familiar with the tools build system
> because I am not a consumer of it. Nicolas may feel differently but I am
> going to assume not based on his level of expertise with tools/ [1]. I
> am not trying to deadlock you though.
> 
> Namhyung, I think this patch can reasonably go via the perf tree since
> it will be a primary consumer of it.

Sorry for the trouble.  I'm fine to take it to the perf tree once
everyone involved is happy about it.  Let me CC the bpf list in the
original patch.

Thanks,
Namhyung

> 
> > > You could claim it! ;)
> 
> Heh, Kbuild and ClangBuiltLinux give me more than enough to do around
> here ;)
> 
> > > Regardless, I like to see cc-option available here, as I doubt this will
> > > be the last conditional option for tool builds. (Actually, are there
> > > other conditional options that could use this today in the tools
> > > Makefiles?)
> > 
> > Some subprojects in tools have their own conditional options.
> > 
> > This patch is ambitious that it changes the global Makefile.include file
> > so it can propagate the '-fzero-init-padding-bits=all' option to
> > projects that include it.  Why do we need to do this globally?  This is
> > because Perf needs to build several subprojects (libperf and bpftool).
> 
> This seems like a great reason for it to go via the perf tree as noted
> above.
> 
> [1]: https://lore.kernel.org/aNhGp7NDCCrtwJqm@levanger/
> 
> Cheers,
> Nathan

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