Thank you for reviewing v3 and I appreciate much Ian's suggestions, most
of which have been adopted into this series.

For anyone new to the series, the reason for appending this compiler
option is described in v3 (see "Link to v3" below).

In this version, the changes are organized into three parts:

  Patches 01 – 07: Preparation before adding the new compiler option.
                   Fix typos, adjust Makefiles to ensure the newly
                   introduced option does not cause regressions.
  Patch 08:        Propagate -fzero-init-padding-bits=all to
                   EXTRA_CFLAGS and HOST_EXTRACFLAGS for the
                   CC and HOSTCC compilers, respectively.
  Patches 09 – 30: Apply EXTRA_CFLAGS and HOST_EXTRACFLAGS in
                   project Makefiles.

The change has been verified:

Test 1: Cross compiling perf
	host: gcc 15.2.0 (x86_64), target: aarch64-linux-gnu-gcc

  make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LDFLAGS="-static" \
	    -C tools/perf VF=1 CORESIGHT=1 NO_JEVENTS=1 DEBUG=1

Test 2: Cross compiling selftest bpf and sched_ext
	host: gcc 15.2.0 (x86_64), target: aarch64-linux-gnu-gcc

  export ARCH=arm64
  export CROSS_COMPILE=aarch64-linux-gnu-
  make -C tools/testing/selftests/ TARGETS="bpf sched_ext" SKIP_TARGETS=""

Test 3: Native compiling selftest bpf and sched_ext
	host: gcc 15.2.0 (x86_64)

  make -C tools/testing/selftests/ TARGETS="bpf sched_ext" SKIP_TARGETS=""

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
Changes in v4:
- Placed EXTRA_CFLAGS last so it can override the default options (Ian).
- Cached evaluated values to avoid invoking cc-option when each
  reference EXTRA_CFLAGS/HOST_EXTRACFLAGS (Ian).
- Dropped useless patches for feature, verification and nolibc
  (Gabriele / Ian / Thomas).
- Fixed typos for thermal (Ian).
- Removed duplicate $(CLANG_CROSS_FLAGS) in libbpf (Ian).
- Collected maintainers' reviewed and ACK tags.
- Link to v3: https://lore.kernel.org/r/20260308-tools_build_fix_zero_init-v3-0-6477808123b7@arm.com

Changes in v3:
- Extended to support cross compilation (Quentin).
- Link to v2: https://lore.kernel.org/r/20260224-tools_build_fix_zero_init-v2-1-b1acc817a01e@arm.com

---
Leo Yan (30):
      tools: lib: thermal: Fix typo
      tools/thermal: Fix typo
      tools: lib: thermal: Initialize CFLAGS before including Makefile.include
      tools/thermal: Initialize CFLAGS before including Makefile.include
      bpftool: Avoid adding EXTRA_CFLAGS to HOST_CFLAGS
      libbpf: Remove duplicate $(CLANG_CROSS_FLAGS)
      libbpf: Initialize CFLAGS before including Makefile.include
      tools build: Append -fzero-init-padding-bits=all to extra cflags
      bpftool: Append extra host flags
      perf build: Append extra host flags
      tools/bpf: build: Append extra cflags
      tools build: Append extra host cflags
      tools: bootconfig: Append extra cflags
      tools: counter: Append extra cflags
      tools: dma: Append extra cflags
      tools: gpio: Append extra cflags
      tools: hv: Append extra cflags
      tools: iio: Append extra cflags
      tools: mm: Append extra cflags
      tools: objtool: Append extra host cflags
      tools: power: acpi: Append extra cflags
      tools: power: x86/intel-speed-select: Append extra cflags
      tools: sched_ext: Append extra cflags
      tools: spi: Append extra cflags
      tools: tracing: Append extra cflags
      tools: usb: Append extra cflags
      selftests/bpf: Append extra cflags
      selftests/hid: Append extra cflags
      selftests/nolibc: Append extra cflags
      selftests/sched_ext: Append extra cflags

 tools/bootconfig/Makefile                   |  1 +
 tools/bpf/Makefile                          |  1 +
 tools/bpf/bpftool/Makefile                  |  9 +++++++--
 tools/build/Makefile                        |  6 ++++--
 tools/counter/Makefile                      |  1 +
 tools/dma/Makefile                          |  1 +
 tools/gpio/Makefile                         |  1 +
 tools/hv/Makefile                           |  1 +
 tools/iio/Makefile                          |  1 +
 tools/lib/bpf/Makefile                      | 17 ++++++++--------
 tools/lib/thermal/Makefile                  | 20 ++++++++++---------
 tools/mm/Makefile                           |  1 +
 tools/objtool/Makefile                      |  2 ++
 tools/perf/Makefile.config                  |  2 +-
 tools/power/acpi/Makefile.config            |  1 +
 tools/power/x86/intel-speed-select/Makefile |  1 +
 tools/sched_ext/Makefile                    |  1 +
 tools/scripts/Makefile.include              | 30 +++++++++++++++++++++++++++++
 tools/spi/Makefile                          |  1 +
 tools/testing/selftests/bpf/Makefile        | 10 ++++++++--
 tools/testing/selftests/hid/Makefile        |  1 +
 tools/testing/selftests/nolibc/Makefile     |  6 ++----
 tools/testing/selftests/sched_ext/Makefile  |  1 +
 tools/thermal/lib/Makefile                  | 20 ++++++++++---------
 tools/tracing/latency/Makefile              |  1 +
 tools/usb/Makefile                          |  1 +
 26 files changed, 101 insertions(+), 37 deletions(-)
---
base-commit: 4ae12d8bd9a830799db335ee661d6cbc6597f838
change-id: 20260224-tools_build_fix_zero_init-dc5261bd8b8b

Best regards,
-- 
Leo Yan <leo.yan@arm.com>

Hi Leo,

On 3/11/26 09:29, Leo Yan wrote:
> Thank you for reviewing v3 and I appreciate much Ian's suggestions, most
> of which have been adopted into this series.
> 
> For anyone new to the series, the reason for appending this compiler
> option is described in v3 (see "Link to v3" below).
> 
> In this version, the changes are organized into three parts:
> 
>    Patches 01 – 07: Preparation before adding the new compiler option.
>                     Fix typos, adjust Makefiles to ensure the newly
>                     introduced option does not cause regressions.
>    Patch 08:        Propagate -fzero-init-padding-bits=all to
>                     EXTRA_CFLAGS and HOST_EXTRACFLAGS for the
>                     CC and HOSTCC compilers, respectively.
>    Patches 09 – 30: Apply EXTRA_CFLAGS and HOST_EXTRACFLAGS in
>                     project Makefiles.
> 
Through which tree do you expect these patch to be picked up ? Each 
maintainer picks the patches related to their subsystem ?

Hi Daniel,

On Wed, Mar 11, 2026 at 09:44:16AM +0100, Daniel Lezcano wrote:

[...]

> > In this version, the changes are organized into three parts:
> > 
> >    Patches 01 – 07: Preparation before adding the new compiler option.
> >                     Fix typos, adjust Makefiles to ensure the newly
> >                     introduced option does not cause regressions.
> >    Patch 08:        Propagate -fzero-init-padding-bits=all to
> >                     EXTRA_CFLAGS and HOST_EXTRACFLAGS for the
> >                     CC and HOSTCC compilers, respectively.
> >    Patches 09 – 30: Apply EXTRA_CFLAGS and HOST_EXTRACFLAGS in
> >                     project Makefiles.
> > 
> Through which tree do you expect these patch to be picked up ? Each
> maintainer picks the patches related to their subsystem ?

I can propose a pickup sequence, but this may need confirmation from the
tools maintainers (especially perf, bpftool, BPF).

I expect patches 01-08 can be merged in one go, as this would be safe
not break anything.  Afterwards, patches 09–30 can be picked up
separately by subsystem maintainers, or merged together.

So far, IIUC, there are no maintainers for the tools build.  If no
objection from maintainers to merge in one go, I think we have chance
via perf-tools-next tree.  Arnaldo, Namhyung, how about you think ?
(sorry this might introduce extra efforts for you).

Thanks,
Leo

On Wed, 11 Mar 2026 09:44:16 +0100
Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> wrote:

> Hi Leo,
> 
> On 3/11/26 09:29, Leo Yan wrote:
> > Thank you for reviewing v3 and I appreciate much Ian's suggestions, most
> > of which have been adopted into this series.
> > 
> > For anyone new to the series, the reason for appending this compiler
> > option is described in v3 (see "Link to v3" below).
> > 
> > In this version, the changes are organized into three parts:
> > 
> >    Patches 01 – 07: Preparation before adding the new compiler option.
> >                     Fix typos, adjust Makefiles to ensure the newly
> >                     introduced option does not cause regressions.
> >    Patch 08:        Propagate -fzero-init-padding-bits=all to
> >                     EXTRA_CFLAGS and HOST_EXTRACFLAGS for the
> >                     CC and HOSTCC compilers, respectively.
> >    Patches 09 – 30: Apply EXTRA_CFLAGS and HOST_EXTRACFLAGS in
> >                     project Makefiles.
> >   
> Through which tree do you expect these patch to be picked up ? Each 
> maintainer picks the patches related to their subsystem ?

If that's the case it would be helpful to +CC the relevant
subsystem lists on the patches that you expect to go that path.

Jonathan

On Wed, Mar 11, 2026 at 08:52:52AM +0000, Jonathan Cameron wrote:
> On Wed, 11 Mar 2026 09:44:16 +0100
> Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> wrote:
> 
> > Hi Leo,
> > 
> > On 3/11/26 09:29, Leo Yan wrote:
> > > Thank you for reviewing v3 and I appreciate much Ian's suggestions, most
> > > of which have been adopted into this series.
> > > 
> > > For anyone new to the series, the reason for appending this compiler
> > > option is described in v3 (see "Link to v3" below).
> > > 
> > > In this version, the changes are organized into three parts:
> > > 
> > >    Patches 01 – 07: Preparation before adding the new compiler option.
> > >                     Fix typos, adjust Makefiles to ensure the newly
> > >                     introduced option does not cause regressions.
> > >    Patch 08:        Propagate -fzero-init-padding-bits=all to
> > >                     EXTRA_CFLAGS and HOST_EXTRACFLAGS for the
> > >                     CC and HOSTCC compilers, respectively.
> > >    Patches 09 – 30: Apply EXTRA_CFLAGS and HOST_EXTRACFLAGS in
> > >                     project Makefiles.
> > >   
> > Through which tree do you expect these patch to be picked up ? Each 
> > maintainer picks the patches related to their subsystem ?
> 
> If that's the case it would be helpful to +CC the relevant
> subsystem lists on the patches that you expect to go that path.

I deliberately looped mainatiners but not CC'ed each subsystem lists,
as it is a long list so I don't want to spam them.

If we conclude to go via subsystem trees, I will CC subsystem lists.
Thanks for reminding.

On Wed, 11 Mar 2026 09:23:31 +0000 Leo Yan <leo.yan@arm.com> wrote:

> On Wed, Mar 11, 2026 at 08:52:52AM +0000, Jonathan Cameron wrote:
> > On Wed, 11 Mar 2026 09:44:16 +0100
> > Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> wrote:
> > 
> > > Hi Leo,
> > > 
> > > On 3/11/26 09:29, Leo Yan wrote:
> > > > Thank you for reviewing v3 and I appreciate much Ian's suggestions, most
> > > > of which have been adopted into this series.
> > > > 
> > > > For anyone new to the series, the reason for appending this compiler
> > > > option is described in v3 (see "Link to v3" below).
> > > > 
> > > > In this version, the changes are organized into three parts:
> > > > 
> > > >    Patches 01 – 07: Preparation before adding the new compiler option.
> > > >                     Fix typos, adjust Makefiles to ensure the newly
> > > >                     introduced option does not cause regressions.
> > > >    Patch 08:        Propagate -fzero-init-padding-bits=all to
> > > >                     EXTRA_CFLAGS and HOST_EXTRACFLAGS for the
> > > >                     CC and HOSTCC compilers, respectively.
> > > >    Patches 09 – 30: Apply EXTRA_CFLAGS and HOST_EXTRACFLAGS in
> > > >                     project Makefiles.
> > > >   
> > > Through which tree do you expect these patch to be picked up ? Each 
> > > maintainer picks the patches related to their subsystem ?

My common approach to this sort of thing (which works) is to put
everything into mm.git, try to cc the whole world.

If Mark alerts us to the appearance of particular patches in linux-next
via another tree, I drop the mm.git copy, so maintainers can simply
cherrypick things and it's all automatic.

If maintainers send an ack (easiest!) then great.

Whatever is left over I upstream in the next merge window.

> > If that's the case it would be helpful to +CC the relevant
> > subsystem lists on the patches that you expect to go that path.
> 
> I deliberately looped mainatiners but not CC'ed each subsystem lists,
> as it is a long list so I don't want to spam them.
> 
> If we conclude to go via subsystem trees, I will CC subsystem lists.
> Thanks for reminding.

Sure.

I can ensure that the appropriate maintainers are cc'ed on the relevant
mm.git commits.    I generally don't auto-cc mailing lists - I already spray
out too many emails!