From: Leo Yan <leo.yan@arm.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
"Liang, Kan" <kan.liang@linux.intel.com>,
James Clark <james.clark@linaro.org>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Leo Yan <leo.yan@arm.com>
Subject: [PATCH v2] perf build: Use -fzero-init-padding-bits=all
Date: Thu, 20 Mar 2025 10:52:35 +0000 [thread overview]
Message-ID: <20250320105235.3498106-1-leo.yan@arm.com> (raw)
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.
This new behaviour might cause unexpected data when we define a union
with using the '{ 0 }' initializer. Currently, the perf tool has ruled
out these cases with the sanitizer "-fsanitize=undefined".
But the sanitizer is not enabled by default, we need to manually enable
it with EXTRA_CFLAGS='-fsanitize=undefined'. This means developers
might encounter issues caused by the initializer with new compilers.
Enable -fzero-init-padding-bits=all to zero padding bits in unions and
structures that might otherwise be left uninitialized.
[1] https://gcc.gnu.org/gcc-15/changes.html
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
Changes from v1:
- Changed to use '-fzero-init-padding-bits=all' to replace
'-fzero-init-padding-bits=unions'. (Namhyung)
- Updated commit log for a bit background info. (Ian)
tools/perf/Makefile.config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index a148ca9efca9..b4f6d656c729 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -323,6 +323,8 @@ FEATURE_CHECK_LDFLAGS-libaio = -lrt
FEATURE_CHECK_LDFLAGS-disassembler-four-args = -lbfd -lopcodes -ldl
FEATURE_CHECK_LDFLAGS-disassembler-init-styled = -lbfd -lopcodes -ldl
+# Explicitly clear padding bits with the initializer '{ 0 }'
+CORE_CFLAGS += $(call cc-option,-fzero-init-padding-bits=all)
CORE_CFLAGS += -fno-omit-frame-pointer
CORE_CFLAGS += -Wall
CORE_CFLAGS += -Wextra
--
2.34.1
next reply other threads:[~2025-03-20 10:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 10:52 Leo Yan [this message]
2025-03-20 11:46 ` James Clark
2025-03-20 15:06 ` Leo Yan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250320105235.3498106-1-leo.yan@arm.com \
--to=leo.yan@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=namhyung@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®