Fail the build on objtool warnings

The CONFIG_X86_ESPFIX64 version of exc_double_fault() can return to its caller, but the !CONFIG_X86_ESPFIX64 version never does. In the latter case the compiler and/or objtool may consider it to be implicitly noreturn.

However, due to the currently inflexible way objtool detects noreturns, a function's noreturn status needs to be consistent across configs.

The current workaround for this issue is to suppress unreachable warnings for exc_double_fault()'s callers. Unfortunately that can result in ORC coverage gaps and potentially worse issues like inert static calls and silently disabled CPU mitigations.

Instead, prevent exc_double_fault() from ever being implicitly marked noreturn by forcing a return behind a never-taken conditional.

Until a more integrated noreturn detection method exists, this is likely the least objectionable workaround.

The CONFIG_X86_ESPFIX64 version of exc_double_fault() can return to its caller, but the !CONFIG_X86_ESPFIX64 version never does. In the latter case the compiler and/or objtool may consider it to be implicitly noreturn.

However, due to the currently inflexible way objtool detects noreturns, a function's noreturn status needs to be consistent across configs.

The current workaround for this issue is to suppress unreachable warnings for exc_double_fault()'s callers. Unfortunately that can result in ORC coverage gaps and potentially worse issues like inert static calls and silently disabled CPU mitigations.

Instead, prevent exc_double_fault() from ever being implicitly marked noreturn by forcing a return behind a never-taken conditional.

Until a more integrated noreturn detection method exists, this is likely the least objectionable workaround.

Fixes 55eeab2a8a11 ("objtool: Ignore exc_double_fault() __noreturn warnings")

Signed-off-by Josh Poimboeuf <[email protected]>

Make sure all fatal errors are funneled through the 'out' label with a negative ret.

Signed-off-by Josh Poimboeuf <[email protected]>

Make sure all fatal errors are funneled through the 'out' label with a negative ret.

Signed-off-by Josh Poimboeuf <[email protected]>

Clarify what needs to be done to resolve the missing __noreturn warning.

Signed-off-by Josh Poimboeuf <[email protected]>

---
 tools/objtool/Documentation/objtool.txt | 12 +++++-------
 tools/objtool/check.c                   |  2 +-
 2 files changed, 6 insertions(+), 8 deletions(-)

tools/objtool/Documentation/objtool.txt +0 -0

index 7c3ee959b63c..87950a7aaa17 100644

Quoted 16 lines · Josh Poimboeuf

Clarify what needs to be done to resolve the missing __noreturn warning.

Signed-off-by Josh Poimboeuf <[email protected]>

---
 tools/objtool/Documentation/objtool.txt | 12 +++++-------
 tools/objtool/check.c                   |  2 +-
 2 files changed, 6 insertions(+), 8 deletions(-)

tools/objtool/Documentation/objtool.txt +0 -0

index 7c3ee959b63c..87950a7aaa17 100644
@@ -319,14 +319,12 @@ the objtool maintainers.
    a just a bad person, you can tell objtool to ignore it.  See the
    "Adding exceptions" section below.
 

tools/objtool/Documentation/objtool.txt the objtool maintainers. · line 323

Quoted 2 lines

tools/objtool/Documentation/objtool.txt +0 -2

-   If it's not actually in a callable function (e.g. kernel entry code),
-   change ENDPROC to END.

Did you mean to delete that?

Fix some outdated information in the objtool doc.

Such normal callable functions
are annotated with the ENTRY/ENDPROC macros.

Signed-off-by Josh Poimboeuf <[email protected]>

---
 tools/objtool/Documentation/objtool.txt | 95 ++++++++++++++-----------
 1 file changed, 53 insertions(+), 42 deletions(-)

tools/objtool/Documentation/objtool.txt +0 -0

index 87950a7aaa17..28ac57b9e102 100644

Increase the per-function WARN_FUNC() rate limit from 1 to 2. If the number of warnings for a given function goes beyond 2, print "skipping duplicate warning(s)". This helps root out additional warnings in a function that might be hiding behind the first one.

Signed-off-by Josh Poimboeuf <[email protected]>

---
 tools/objtool/check.c                |  2 +-
 tools/objtool/include/objtool/elf.h  |  2 +-
 tools/objtool/include/objtool/warn.h | 14 +++++++++++---
 3 files changed, 13 insertions(+), 5 deletions(-)

tools/objtool/check.c +1 -1

index 6b9ad3afe389..3ddaefe97f55 100644
@@ -4528,7 +4528,7 @@ static int disas_warned_funcs(struct objtool_file *file)
 	char *funcs = NULL, *tmp;
 
 	for_each_sym(file, sym) {
-		if (sym->warned) {
+		if (sym->warnings) {
 			if (!funcs) {
 				funcs = malloc(strlen(sym->name) + 1);
 				strcpy(funcs, sym->name);

tools/objtool/include/objtool/elf.h +1 -1

index d7e815c2fd15..223ac1c24b90 100644
@@ -65,10 +65,10 @@ struct symbol {
 	u8 return_thunk      : 1;
 	u8 fentry            : 1;
 	u8 profiling_func    : 1;
-	u8 warned	     : 1;
 	u8 embedded_insn     : 1;
 	u8 local_label       : 1;
 	u8 frame_pointer     : 1;
+	u8 warnings	     : 2;
 	struct list_head pv_target;
 	struct reloc *relocs;
 };

tools/objtool/include/objtool/warn.h +0 -0

index ac04d3fe4dd9..6180288927fd 100644

Quoted 49 lines · Josh Poimboeuf

Increase the per-function WARN_FUNC() rate limit from 1 to 2. If the number of warnings for a given function goes beyond 2, print "skipping duplicate warning(s)". This helps root out additional warnings in a function that might be hiding behind the first one.

Signed-off-by Josh Poimboeuf <[email protected]>

---
 tools/objtool/check.c                |  2 +-
 tools/objtool/include/objtool/elf.h  |  2 +-
 tools/objtool/include/objtool/warn.h | 14 +++++++++++---
 3 files changed, 13 insertions(+), 5 deletions(-)

tools/objtool/check.c +1 -1

index 6b9ad3afe389..3ddaefe97f55 100644
@@ -4528,7 +4528,7 @@ static int disas_warned_funcs(struct objtool_file *file)
 	char *funcs = NULL, *tmp;
 
 	for_each_sym(file, sym) {
-		if (sym->warned) {
+		if (sym->warnings) {
 			if (!funcs) {
 				funcs = malloc(strlen(sym->name) + 1);
 				strcpy(funcs, sym->name);

tools/objtool/include/objtool/elf.h +1 -1

index d7e815c2fd15..223ac1c24b90 100644
@@ -65,10 +65,10 @@ struct symbol {
 	u8 return_thunk      : 1;
 	u8 fentry            : 1;
 	u8 profiling_func    : 1;
-	u8 warned	     : 1;
 	u8 embedded_insn     : 1;
 	u8 local_label       : 1;
 	u8 frame_pointer     : 1;
+	u8 warnings	     : 2;
 	struct list_head pv_target;
 	struct reloc *relocs;
 };

tools/objtool/include/objtool/warn.h +0 -0

index ac04d3fe4dd9..6180288927fd 100644
@@ -53,14 +53,22 @@ static inline char *offstr(struct section *sec, unsigned long offset)
 	free(_str);					\
 })
 

tools/objtool/include/objtool/warn.h static inline char *offstr(struct section *sec, unsigned long offset) · line 61

Quoted 7 lines

tools/objtool/include/objtool/warn.h +3 -1

+#define WARN_LIMIT 2
+
 #define WARN_INSN(insn, format, ...)					\
 ({									\
 	struct instruction *_insn = (insn);				\
-	if (!_insn->sym || !_insn->sym->warned)				\
+	BUILD_BUG_ON(WARN_LIMIT > 2);					\

Shouldn't this be >3? Anyway, I think it would be clearer if the coupling was more explicit, e.g:

tools/objtool/include/objtool/elf.h +3 -1

index 223ac1c24b90..a86e43d2056f 100644
@@ -46,6 +46,8 @@ struct section {
        struct reloc *relocs;
 };
 
+#define STRUCT_SYMBOL_WARNING_BITS 2
+
 struct symbol {
        struct list_head list;
        struct rb_node node;

@@ -68,7 +70,7 @@ struct symbol {
        u8 embedded_insn     : 1;
        u8 local_label       : 1;
        u8 frame_pointer     : 1;
-       u8 warnings          : 2;
+       u8 warnings          : STRUCT_SYMBOL_WARNING_BITS;
        struct list_head pv_target;
        struct reloc *relocs;
 };

tools/objtool/include/objtool/warn.h +1 -0

index e72b9d630551..2fba6866fd2d 100644
@@ -56,6 +56,7 @@ static inline char *offstr(struct section *sec, unsigned long offset)
 })
 
 #define WARN_LIMIT 2
+static_assert(WARN_LIMIT < (1 << STRUCT_SYMBOL_WARNING_BITS), "symbol.warnings too small");
 
 #define WARN_INSN(insn, format, ...)                                   \
 ({

Or just drop the bitfield (surely it can't be that important to save a byte here?) and use sizeof, e.g:

BUILD_BUG_ON(ilog2(WARN_LIMIT) > sizeof(_insn->sym->warnings));

Quoted 8 lines

Quoted 8 lines

tools/objtool/include/objtool/warn.h +0 -0

index ac04d3fe4dd9..6180288927fd 100644
@@ -53,14 +53,22 @@ static inline char *offstr(struct section *sec, unsigned long offset)
 	free(_str);					\
 })
 

Quoted 10 lines

tools/objtool/include/objtool/warn.h static inline char *offstr(struct section *sec, unsigned long offset) · line 61

Quoted 7 lines

tools/objtool/include/objtool/warn.h +3 -1

+#define WARN_LIMIT 2
+
 #define WARN_INSN(insn, format, ...)					\
 ({									\
 	struct instruction *_insn = (insn);				\
-	if (!_insn->sym || !_insn->sym->warned)				\
+	BUILD_BUG_ON(WARN_LIMIT > 2);					\

Shouldn't this be >3? Anyway, I think it would be clearer if the coupling was more explicit, e.g:

I think it is correct but I also think that the difference between bits and the actual number of "allowed" warnings can be confusing.

With unret validation enabled and IBT/LTO disabled, objtool runs on TUs with --rethunk and on vmlinux.o with --unret. So this dependency isn't valid as they don't always run on the same object.

This error never triggered before because --unret is always coupled with --noinstr, so the first conditional in opts_valid() returns early due to opts.noinstr being true.

Signed-off-by Josh Poimboeuf <[email protected]>

---
 tools/objtool/builtin-check.c | 5 -----
 1 file changed, 5 deletions(-)

tools/objtool/builtin-check.c +0 -0

index 387d56a7f5fb..c7275cf7641b 100644

Quoted 21 lines · Josh Poimboeuf

With unret validation enabled and IBT/LTO disabled, objtool runs on TUs with --rethunk and on vmlinux.o with --unret. So this dependency isn't valid as they don't always run on the same object.

This error never triggered before because --unret is always coupled with --noinstr, so the first conditional in opts_valid() returns early due to opts.noinstr being true.

Signed-off-by Josh Poimboeuf <[email protected]>

---
 tools/objtool/builtin-check.c | 5 -----
 1 file changed, 5 deletions(-)

tools/objtool/builtin-check.c +0 -0

index 387d56a7f5fb..c7275cf7641b 100644
@@ -151,11 +151,6 @@ static bool opts_valid(void)
 		return true;
 	}
 

tools/objtool/builtin-check.c static bool opts_valid(void) · line 157

Quoted 4 lines

tools/objtool/builtin-check.c +0 -4

-	if (opts.unret && !opts.rethunk) {
-		ERROR("--unret requires --rethunk");
-		return false;
-	}

But but but, the whole UNTRAIN_RET stuff relies on return thunks. Even though objtool can do that VALUDATE_UNRET_BEGIN -> VALIDATE_UNRET_END check without there being return thunks, it simply doesn't make sense.

Quoted 22 lines · Peter Zijlstra

Quoted 21 lines · Josh Poimboeuf

With unret validation enabled and IBT/LTO disabled, objtool runs on TUs with --rethunk and on vmlinux.o with --unret. So this dependency isn't valid as they don't always run on the same object.

This error never triggered before because --unret is always coupled with --noinstr, so the first conditional in opts_valid() returns early due to opts.noinstr being true.

Signed-off-by Josh Poimboeuf <[email protected]>

---
 tools/objtool/builtin-check.c | 5 -----
 1 file changed, 5 deletions(-)

tools/objtool/builtin-check.c +0 -0

index 387d56a7f5fb..c7275cf7641b 100644
@@ -151,11 +151,6 @@ static bool opts_valid(void)
 		return true;
 	}
 

Quoted 8 lines

tools/objtool/builtin-check.c static bool opts_valid(void) · line 157

Quoted 4 lines

tools/objtool/builtin-check.c +0 -4

-	if (opts.unret && !opts.rethunk) {
-		ERROR("--unret requires --rethunk");
-		return false;
-	}

But but but, the whole UNTRAIN_RET stuff relies on return thunks. Even though objtool can do that VALUDATE_UNRET_BEGIN -> VALIDATE_UNRET_END check without there being return thunks, it simply doesn't make sense.

That's at least enforced by kconfig dependencies as MITIGATION_UNRET_ENTRY depends on MITIGATION_RETHUNK.

If you wanted to enforce it on the objtool level, we might need to do some makefile acrobatics to defer --rethunk to vmlinux link time for the above mentioned case.

Quoted 22 lines · Peter Zijlstra

Quoted 21 lines · Josh Poimboeuf

With unret validation enabled and IBT/LTO disabled, objtool runs on TUs with --rethunk and on vmlinux.o with --unret. So this dependency isn't valid as they don't always run on the same object.

This error never triggered before because --unret is always coupled with --noinstr, so the first conditional in opts_valid() returns early due to opts.noinstr being true.

Signed-off-by Josh Poimboeuf <[email protected]>

---
 tools/objtool/builtin-check.c | 5 -----
 1 file changed, 5 deletions(-)

tools/objtool/builtin-check.c +0 -0

index 387d56a7f5fb..c7275cf7641b 100644
@@ -151,11 +151,6 @@ static bool opts_valid(void)
 		return true;
 	}
 

Quoted 8 lines

tools/objtool/builtin-check.c static bool opts_valid(void) · line 157

Quoted 4 lines

tools/objtool/builtin-check.c +0 -4

-	if (opts.unret && !opts.rethunk) {
-		ERROR("--unret requires --rethunk");
-		return false;
-	}

But but but, the whole UNTRAIN_RET stuff relies on return thunks. Even though objtool can do that VALUDATE_UNRET_BEGIN -> VALIDATE_UNRET_END check without there being return thunks, it simply doesn't make sense.

That's at least enforced by kconfig dependencies as MITIGATION_UNRET_ENTRY depends on MITIGATION_RETHUNK.

The option validations are a bit scattered, consolidate them.

Signed-off-by Josh Poimboeuf <[email protected]>

The option validations are a bit scattered, consolidate them.

Signed-off-by Josh Poimboeuf <[email protected]>

Force the user to fix their cmdline if they forget the '--link' option.

Signed-off-by Josh Poimboeuf <[email protected]>

Force the user to fix their cmdline if they forget the '--link' option.

Signed-off-by Josh Poimboeuf <[email protected]>

---
 tools/objtool/builtin-check.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

tools/objtool/builtin-check.c +0 -0

index 36d81a455b01..79843512a51b 100644

Add option to allow writing the changed binary to a separate file rather than changing it in place.

Libelf makes this suprisingly hard, so take the easy way out and just copy the file before editing it.

Also steal the -o short option from --orc. Nobody will notice ;-)

Signed-off-by Josh Poimboeuf <[email protected]>

---
 tools/objtool/builtin-check.c           | 98 ++++++++++++++++++++-----
 tools/objtool/elf.c                     |  3 -
 tools/objtool/include/objtool/builtin.h |  1 +
 tools/objtool/objtool.c                 | 15 ++--
 tools/objtool/orc_dump.c                |  7 +-
 5 files changed, 89 insertions(+), 35 deletions(-)

tools/objtool/builtin-check.c +7 -8

index 79843512a51b..3de3afa0a19c 100644
@@ -6,6 +6,10 @@
 #include <subcmd/parse-options.h>
 #include <string.h>
 #include <stdlib.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <sys/stat.h>
+#include <sys/sendfile.h>
 #include <objtool/builtin.h>
 #include <objtool/objtool.h>
 

@@ -14,6 +18,8 @@
 		"error: objtool: " format "\n",		\
 		##__VA_ARGS__)
 
+const char *objname;
+
 struct opts opts;
 
 static const char * const check_usage[] = {

@@ -71,7 +77,7 @@ static const struct option check_options[] = {
 	OPT_BOOLEAN('i', "ibt", &opts.ibt, "validate and annotate IBT"),
 	OPT_BOOLEAN('m', "mcount", &opts.mcount, "annotate mcount/fentry calls for ftrace"),
 	OPT_BOOLEAN('n', "noinstr", &opts.noinstr, "validate noinstr rules"),
-	OPT_BOOLEAN('o', "orc", &opts.orc, "generate ORC metadata"),
+	OPT_BOOLEAN(0,   "orc", &opts.orc, "generate ORC metadata"),
 	OPT_BOOLEAN('r', "retpoline", &opts.retpoline, "validate and annotate retpoline usage"),
 	OPT_BOOLEAN(0,   "rethunk", &opts.rethunk, "validate and annotate rethunk usage"),
 	OPT_BOOLEAN(0,   "unret", &opts.unret, "validate entry unret placement"),

@@ -84,15 +90,16 @@ static const struct option check_options[] = {
 	OPT_CALLBACK_OPTARG(0, "dump", NULL, NULL, "orc", "dump metadata", parse_dump),
 
 	OPT_GROUP("Options:"),
-	OPT_BOOLEAN(0, "backtrace", &opts.backtrace, "unwind on error"),
-	OPT_BOOLEAN(0, "backup", &opts.backup, "create .orig files before modification"),
-	OPT_BOOLEAN(0, "dry-run", &opts.dryrun, "don't write modifications"),
-	OPT_BOOLEAN(0, "link", &opts.link, "object is a linked object"),
-	OPT_BOOLEAN(0, "module", &opts.module, "object is part of a kernel module"),
-	OPT_BOOLEAN(0, "mnop", &opts.mnop, "nop out mcount call sites"),
-	OPT_BOOLEAN(0, "no-unreachable", &opts.no_unreachable, "skip 'unreachable instruction' warnings"),

tools/objtool/builtin-check.c +8 -0

+	OPT_BOOLEAN(0,   "sec-address", &opts.sec_address, "print section addresses in warnings"),
+	OPT_BOOLEAN(0,   "stats", &opts.stats, "print statistics"),
 	OPT_BOOLEAN('v', "verbose", &opts.verbose, "verbose warnings"),
 
 	OPT_END(),

@@ -178,24 +185,75 @@ static bool opts_valid(void)
 	return false;
 }
 
+static int copy_file(const char *src, const char *dst)
+{
+	size_t to_copy, copied;
+	int dst_fd, src_fd;
+	struct stat stat;
+	off_t offset = 0;

Add option to allow writing the changed binary to a separate file rather than changing it in place.

Libelf makes this suprisingly hard, so take the easy way out and just copy the file before editing it.

Also steal the -o short option from --orc. Nobody will notice ;-)

Signed-off-by Josh Poimboeuf <[email protected]>

Any objtool warning has the potential of reflecting (or triggering) a major bug in the kernel or compiler which could result in crashing the kernel or breaking the livepatch consistency model.

In preparation for failing the build on objtool errors/warnings, add a new --Werror option.

[ jpoimboe: commit log, comments, error out on fatal errors too ]

Co-developed-by Brendan Jackman <[email protected]>

Signed-off-by Josh Poimboeuf <[email protected]>

This is similar to GCC's behavior and makes it more obvious why the build failed.

Suggested-by Nathan Chancellor <[email protected]>

Signed-off-by Josh Poimboeuf <[email protected]>

This is similar to GCC's behavior and makes it more obvious why the build failed.

Suggested-by Nathan Chancellor <[email protected]>

Signed-off-by Josh Poimboeuf <[email protected]>

Recreating objtool errors can be a manual process. Kbuild removes the object, so it has to be compiled or linked again before running objtool. Then the objtool args need to be reversed engineered.

Make that all easier by automatically making a backup of the object file on error, and print a modified version of the args which can be used to recreate.

Signed-off-by Josh Poimboeuf <[email protected]>

tools/objtool/builtin-check.c +8 -0

 		unlink(opts.output);
+		goto err_msg;
+	}
+
+	/*
+	 * Make a backup before kbuild deletes the file so the error
+	 * can be recreated without recompiling or relinking.
+	 */
+	backup = malloc(strlen(objname) + strlen(ORIG_SUFFIX) + 1);

Recreating objtool errors can be a manual process. Kbuild removes the object, so it has to be compiled or linked again before running objtool. Then the objtool args need to be reversed engineered.

Make that all easier by automatically making a backup of the object file on error, and print a modified version of the args which can be used to recreate.

Signed-off-by Josh Poimboeuf <[email protected]>

Objtool warnings can be indicative of crashes, broken live patching, or even boot failures. Ignoring them is not recommended.

Add CONFIG_OBJTOOL_WERROR to upgrade objtool warnings to errors by enabling the objtool --Werror option. Also set --backtrace to print the branches leading up to the warning, which can help considerably when debugging certain warnings.

To avoid breaking bots too badly for now, make it the default for real world builds only (!COMPILE_TEST).

Co-developed-by Brendan Jackman <[email protected]>

Signed-off-by Josh Poimboeuf <[email protected]>

---
 lib/Kconfig.debug    | 12 ++++++++++++
 scripts/Makefile.lib |  1 +
 2 files changed, 13 insertions(+)

lib/Kconfig.debug +0 -0

index 35796c290ca3..bbfb9d575f97 100644

lib/Kconfig.debug config FRAME_POINTER · line 553

Quoted 6 lines

lib/Kconfig.debug +6 -0

+config OBJTOOL_WERROR
+	bool "Upgrade objtool warnings to errors"
+	default y
+	depends on OBJTOOL && !COMPILE_TEST
+	help
+	  Fail the build on objtool warnings.

This is *way* too aggressive: objtool false positives are still common,

and an 'allmodconfig' should not fail the build IMO.

Quoted 8 lines · Ingo Molnar

lib/Kconfig.debug config FRAME_POINTER · line 553

Quoted 6 lines

lib/Kconfig.debug +6 -0

+config OBJTOOL_WERROR
+	bool "Upgrade objtool warnings to errors"
+	default y
+	depends on OBJTOOL && !COMPILE_TEST
+	help
+	  Fail the build on objtool warnings.

This is *way* too aggressive: objtool false positives are still common,

I'm not sure what false positives you'd be referring to, these days the vast majority of warnings I see are actual bugs.

Quoted 1 line

and an 'allmodconfig' should not fail the build IMO.

In fact it doesn't: allmodconfig sets COMPILE_TEST which prevents OBJTOOL_WERROR.

I've had complaints from people who spent days debugging a broken kernel only to discover it was related to an ignored objtool warning.

# Included a fix for a false positive:
#
4e32645cd8f9 x86/smp: Fix mwait_play_dead() and acpi_processor_ffh_play_dead() noreturn behavior

  # objtool poinpointed a problem that has no runtime effects,
  # ie. it's a functional false positive and breaking the build
  # for *that* would have been excessive:
  #
  73e8079be9e7 x86/ibt: Make cfi_bhi a constant for FINEIBT_BHI=n

# Commit works around an objtool false positive found during development:
#
b815f6877d80 x86/bhi: Add BHI stubs

# Commit works around what appears to be a objtool false positive

  # about too aggressive code generation in function prologues:
  # (An issue that does not seem to trigger in practice.)
  #
  4087e16b0331 x86/locking: Use ALT_OUTPUT_SP() for percpu_{,try_}cmpxchg{64,128}_op()

I literally tried to find the first *actual* bug that objtool prevented and the first 4 appear to be struggles with objtool over false positives or non-runtime-bugs.

At least in x86 architecture code a significant percentage of objtool warnings isn't bugs - and to be fair that's maybe in part due to the lockdep effect: developers notice warnings and prevent them, so only traces of false positives trickle into the kernel.

But lockdep too tries to be rather benign and doesn't crash the kernel, it reports an issue and turns itself off.

The following commit has been merged into the objtool/core branch of tip:

Commit-ID:     36799069b48198e5ce92d99310060c4aecb4b3e3
Gitweb:        https://git.kernel.org/tip/36799069b48198e5ce92d99310060c4aecb4b3e3
Author:        Josh Poimboeuf <[email protected]>
AuthorDate:    Fri, 14 Mar 2025 12:29:11 -07:00
Committer:     Peter Zijlstra <[email protected]>
CommitterDate: Mon, 17 Mar 2025 11:51:44 +01:00

objtool: Add CONFIG_OBJTOOL_WERROR