From: Kees Cook <kees@kernel.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Kees Cook <kees@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nicolas.schier@linux.dev>,
Petr Pavlu <petr.pavlu@suse.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Justin Stitt <justinstitt@google.com>,
Marco Elver <elver@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-kbuild@vger.kernel.org, kasan-dev@googlegroups.com
Subject: [PATCH 0/3] Detect changed compiler dependencies for full rebuild
Date: Thu, 1 May 2025 12:48:15 -0700 [thread overview]
Message-ID: <20250501193839.work.525-kees@kernel.org> (raw)
Hi,
This is my attempt to introduce dependencies that track the various
compiler behaviors that may globally change the build that aren't
represented by either compiler flags nor the compiler version
(CC_VERSION_TEXT). Namely, this is to detect when the contents of a
file the compiler uses changes. We have 3 such situations currently in
the tree:
- If any of the GCC plugins change, we need to rebuild everything that
was built with them, as they may have changed their behavior and those
behaviors may need to be synchronized across all translation units.
(The most obvious of these is the randstruct GCC plugin, but is true
for most of them.)
- If the randstruct seed itself changes (whether for GCC plugins or
Clang), the entire tree needs to be rebuilt since the randomization of
structures may change between compilation units if not.
- If the integer-wrap-ignore.scl file for Clang's integer wrapping
sanitizer changes, a full rebuild is needed as the coverage for wrapping
types may have changed, once again cause behavior differences between
compilation units.
The best way I found to deal with this is to use a -include argument
for each of the above cases, which causes fixdep to pick up the file and
naturally depend on it causing the build to notice any date stamp changes.
Each case updates its .h file when its internal dependencies change.
-Kees
Kees Cook (3):
gcc-plugins: Force full rebuild when plugins change
randstruct: Force full rebuild when seed changes
integer-wrap: Force full rebuild when .scl file changes
include/linux/vermagic.h | 1 -
scripts/Makefile.gcc-plugins | 2 +-
scripts/Makefile.randstruct | 3 ++-
scripts/Makefile.ubsan | 1 +
scripts/basic/Makefile | 20 +++++++++++++++-----
scripts/gcc-plugins/Makefile | 8 ++++++++
6 files changed, 27 insertions(+), 8 deletions(-)
--
2.34.1
next reply other threads:[~2025-05-01 19:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-01 19:48 Kees Cook [this message]
2025-05-01 19:48 ` [PATCH 1/3] gcc-plugins: Force full rebuild when plugins change Kees Cook
2025-05-02 20:39 ` Kees Cook
2025-05-01 19:48 ` [PATCH 2/3] randstruct: Force full rebuild when seed changes Kees Cook
2025-05-02 16:12 ` Nathan Chancellor
2025-05-02 22:57 ` Kees Cook
2025-05-01 19:48 ` [PATCH 3/3] integer-wrap: Force full rebuild when .scl file changes Kees Cook
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=20250501193839.work.525-kees@kernel.org \
--to=kees@kernel.org \
--cc=andreyknvl@gmail.com \
--cc=bigeasy@linutronix.de \
--cc=elver@google.com \
--cc=justinstitt@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=petr.pavlu@suse.com \
--cc=ryabinin.a.a@gmail.com \
/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