On Wed, Dec 18, 2024 at 04:06:56PM -0800, Andrew Morton wrote:
> On Wed, 18 Dec 2024 14:58:54 +0000 Brendan Jackman <jackmanb@xxxxxxxxxx> wrote:
>
> > This adds an option to objtool to exit with an error when it enounters
> > warnings.
>
> Why is it optional? Can we always fail the build so stuff gets fixed?
Eventually, yes. But right now, I'm not so sure...
it will likely break a lot of robot builds, there are some obscure
randconfigs out there triggering some "interesting" edge cases, e.g.:
- ftrace branch profiling which is fundamentally incompatible with
uaccess STAC/CLAC rules
- similar weirdnesses with UBSAN/KASAN/etc and other compiler
features/plugins
- obscure toolchain bugs in certain compiler versions which do weird
things with control flow. some of these bugs break the kernel, some
don't.
Problem is, it usually falls on the objtool maintainers to figure out
the root of the problem and the resolution, neither of which is
necessarily straightforward, especially the latter. There's only two of
us maintainers at the moment, with limited bandwidth.
So yes, it *should* always fail the build. But unless we get more
maintainer bandwidth, I don't think we're ready for that.
We might end up being able to make CONFIG_OBJTOOL_WERROR=y the default,
and then just require broken features to depend on
CONFIG_OBJTOOL_WERROR=n. And then print a big fat warning message at
build and/or runtime in the case of warnings.
We also might need to add some features, like a way to mark certain
compiler versions as bad, or a way to silence objtool warnings for
certain known harmless cases, or improve the specificity and usefulness
of certain vague warnings.
But as a first step I'll planning on just throwing these patches on a
robot-monitored branch with CONFIG_OBJTOOL_WERROR=y over the holidays to
see how bad the damage is.
--
Josh
