From: Kees Cook <kees@kernel.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Kees Cook <kees@kernel.org>,
Nicolas Schier <nicolas.schier@linux.dev>,
Nathan Chancellor <nathan@kernel.org>,
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>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-kbuild@vger.kernel.org, kasan-dev@googlegroups.com,
llvm@lists.linux.dev
Subject: [PATCH v3 0/3] Detect changed compiler dependencies for full rebuild
Date: Sat, 3 May 2025 11:46:17 -0700 [thread overview]
Message-ID: <20250503184001.make.594-kees@kernel.org> (raw)
v3: move to include/generated, add touch helper
v2: https://lore.kernel.org/lkml/20250502224512.it.706-kees@kernel.org/
v1: https://lore.kernel.org/lkml/20250501193839.work.525-kees@kernel.org/
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 current solution is to:
- Touch a .h file in include/generated that is updated when the specific
dependencies change.
e.g.: randstruct_hash.h depends on randstruct.seed
- Add a conditional -D argument for each separate case
e.g.: RANDSTRUCT_CFLAGS += -DRANDSTRUCT
- Include the .h file from compiler-version.h through an #ifdef for the define
e.g.:
#ifdef RANDSTUCT
#include <generated/randstruct_hash.h>
#endif
This means that all targets gain the dependency (via fixdep), but only
when the defines are active, which means they are trivially controlled
by the existing CFLAGS removal mechanisms that are already being used
to turn off each of the above features.
-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/compiler-version.h | 10 ++++++++++
include/linux/vermagic.h | 1 -
scripts/Makefile.gcc-plugins | 2 +-
scripts/Makefile.lib | 18 ++++++++++++++++++
scripts/Makefile.ubsan | 1 +
scripts/basic/Makefile | 5 +++++
scripts/gcc-plugins/Makefile | 4 ++++
7 files changed, 39 insertions(+), 2 deletions(-)
--
2.34.1
next reply other threads:[~2025-05-03 18:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-03 18:46 Kees Cook [this message]
2025-05-03 18:46 ` [PATCH v3 1/3] gcc-plugins: Force full rebuild when plugins change Kees Cook
2025-05-07 12:01 ` Nicolas Schier
2025-05-07 12:10 ` Nicolas Schier
2025-05-03 18:46 ` [PATCH v3 2/3] randstruct: Force full rebuild when seed changes Kees Cook
2025-05-07 12:14 ` Nicolas Schier
2025-05-03 18:46 ` [PATCH v3 3/3] integer-wrap: Force full rebuild when .scl file changes Kees Cook
2025-05-05 18:16 ` Justin Stitt
2025-05-05 18:18 ` Justin Stitt
2025-05-07 12:21 ` Nicolas Schier
2025-05-07 12:02 ` [PATCH v3 0/3] Detect changed compiler dependencies for full rebuild Nicolas Schier
2025-05-08 15:56 ` 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=20250503184001.make.594-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=llvm@lists.linux.dev \
--cc=masahiroy@kernel.org \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--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