This is basically a revert of commit 644592d32837 ("objtool: Fail the
kernel build on fatal errors").
That change turned out to be more trouble than it's worth. Failing the
build is an extreme measure which sometimes gets too much attention and
blocks CI build testing.
These fatal-type warnings aren't yet as rare as we'd hope, due to the
ever-increasing matrix of supported toolchains/plugins and their
fast-changing nature as of late.
Also, there are more people (and bots) looking for objtool warnings than
ever before, so such warnings not likely to be ignored for long.
Suggested-by: Nick Desaulniers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
---
tools/objtool/check.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 5f8d3eed78a1..4bd30315eb62 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2928,14 +2928,10 @@ int check(struct objtool_file *file)
warnings += ret;
out:
- if (ret < 0) {
- /*
- * Fatal error. The binary is corrupt or otherwise broken in
- * some way, or objtool itself is broken. Fail the kernel
- * build.
- */
- return ret;
- }
-
+ /*
+ * For now, don't fail the kernel build on fatal warnings. These
+ * errors are still fairly common due to the growing matrix of
+ * supported toolchains and their recent pace of change.
+ */
return 0;
}
--
2.29.2
On Thu, 14 Jan 2021, Josh Poimboeuf wrote:
> This is basically a revert of commit 644592d32837 ("objtool: Fail the
> kernel build on fatal errors").
>
> That change turned out to be more trouble than it's worth. Failing the
> build is an extreme measure which sometimes gets too much attention and
> blocks CI build testing.
>
> These fatal-type warnings aren't yet as rare as we'd hope, due to the
> ever-increasing matrix of supported toolchains/plugins and their
> fast-changing nature as of late.
>
> Also, there are more people (and bots) looking for objtool warnings than
> ever before, so such warnings not likely to be ignored for long.
>
> Suggested-by: Nick Desaulniers <[email protected]>
> Signed-off-by: Josh Poimboeuf <[email protected]>
Reviewed-by: Miroslav Benes <[email protected]>
M
On Thu, Jan 14, 2021 at 2:46 PM Josh Poimboeuf <[email protected]> wrote:
>
> This is basically a revert of commit 644592d32837 ("objtool: Fail the
> kernel build on fatal errors").
>
> That change turned out to be more trouble than it's worth. Failing the
> build is an extreme measure which sometimes gets too much attention and
> blocks CI build testing.
>
> These fatal-type warnings aren't yet as rare as we'd hope, due to the
> ever-increasing matrix of supported toolchains/plugins and their
> fast-changing nature as of late.
>
> Also, there are more people (and bots) looking for objtool warnings than
> ever before, so such warnings not likely to be ignored for long.
>
> Suggested-by: Nick Desaulniers <[email protected]>
> Signed-off-by: Josh Poimboeuf <[email protected]>
Thank you; I feel the arguments against enabling -Werror for the
kernel apply here. The warnings are annoying enough that we plan to
follow up on them all.
Reviewed-by: Nick Desaulniers <[email protected]>
> ---
> tools/objtool/check.c | 14 +++++---------
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 5f8d3eed78a1..4bd30315eb62 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -2928,14 +2928,10 @@ int check(struct objtool_file *file)
> warnings += ret;
>
> out:
> - if (ret < 0) {
> - /*
> - * Fatal error. The binary is corrupt or otherwise broken in
> - * some way, or objtool itself is broken. Fail the kernel
> - * build.
> - */
> - return ret;
> - }
> -
> + /*
> + * For now, don't fail the kernel build on fatal warnings. These
> + * errors are still fairly common due to the growing matrix of
> + * supported toolchains and their recent pace of change.
> + */
> return 0;
> }
> --
> 2.29.2
>
--
Thanks,
~Nick Desaulniers
On 1/15/21 4:15 AM, Josh Poimboeuf wrote:
> This is basically a revert of commit 644592d32837 ("objtool: Fail the
> kernel build on fatal errors").
>
> That change turned out to be more trouble than it's worth. Failing the
> build is an extreme measure which sometimes gets too much attention and
> blocks CI build testing.
>
> These fatal-type warnings aren't yet as rare as we'd hope, due to the
> ever-increasing matrix of supported toolchains/plugins and their
> fast-changing nature as of late.
>
> Also, there are more people (and bots) looking for objtool warnings than
> ever before, so such warnings not likely to be ignored for long.
>
> Suggested-by: Nick Desaulniers <[email protected]>
> Signed-off-by: Josh Poimboeuf <[email protected]>
Reviewed-by: Kamalesh Babulal <[email protected]>
--
Kamalesh
> This is basically a revert of commit 644592d32837 ("objtool: Fail the
kernel build on fatal errors").
> That change turned out to be more trouble than it's worth.
...I'm sorry, what? Fatal errors are normal for you people? Seriously?
I've been compiling my own kernel since 2004, I've never seen one. I'd
like some explanation on this.
> Failing the build is an extreme measure which sometimes gets too much
attention and blocks CI build testing.
If you already know it's broken, there's no point testing it. Why are
you so desperately trying to ignore it? Are you getting paid to be here
or are you this stupid for free?
Have you tried calling an ambulance on Android lately? I can reboot my
Huawei with schedtool on Termux. Unrooted, stock. THE LINUX KERNEL IS
MEASURED IN HUMAN LIVES.
> These fatal-type warnings
GET THE FUCK OUT WITH YOUR BULLSHIT DOUBLESPEAK
> aren't yet as rare as we'd hope
How many times do you need to ignore an obvious compiler bug until you
hope it away?
> due to the ever-increasing matrix of supported toolchains/plugins
llvm+clang compiles with cmake. In "Release" mode, cmake helpfully
appends a -O3 for you, which is the kind of "optimization" where the
compiler deliberately misinterprets the programmer's intention to
declare an UB, and then uses its godlike might to decide the target of
an explicit constcast is unreachable. If you recompile systemd with the
result, it will not understand your password anymore. This was
yesterday. The day before, it errored out on m4 with some undefined
linkage into compiler-rt. WITH AN EXPLICIT --rtlib=libgcc FLAG ON A
GCC-BASED DISTRO
#!/bin/sh
exec /usr/bin/gcc "${@}" -O2
...or did you find a third broken compiler somewhere?
> Also, there are more people (and bots) looking for objtool warnings
than ever before, so such warnings not likely to be ignored for long.
Why not? You seem to be doing just fine.
Ask OpenBSD for a toolchain, see if it works. Or better yet, ask them to
build the kernel for you.
This has already been Reviewed-by.
I'm rejecting both these morons as invalid. Please review everything
they've been doing lately.
---
Yo, Linus! What the fuck is this shit? I'm tempted to I don't care
which one of these whiny little bitches cut your dick off and stuffed it
into your mouth. Either spit it out or swallow and shit it out, but we
can't afford this.
Source-based Linux is dead. Gentoo is a cronjob spewing out endless
broken stage3's, and every single Exherbo dev has unsubscribed from
their own mailing list. I'm the last one standing. I've spent the last
two weeks trying to review the damage. I'm not going to package it
either, but you need to know why. Also, I've quit my job because I
couldn't sleep for four days straight.
I'm typing this in Thunderbird because fucking KONSOLE SEGFAULTED WHEN I
TYPED VIM. I do not feel at home on a binary distro, and I cannot build
a browser on a real one. I would like to explain politely, under the
[foxfire] tag. Anyone who does not want to know why I think it likely
that some Gentoo+ maintainers have literally committed suicide, feel
free to filter it out.
Should you happen to agree with some of my opinions, I'd like you to
revert every single "fix" for "undefined behavior" that was merged for
clang. The C standard committee does not define the result because they
have no idea whether it makes sense in context AND THEY KNOW IT. I mean
seriously, why do these need a lawyer to know whether or not const is
just a helpful suggestion in a UNIX KERNEL?
And we build with -std=gnu -fgnu-keywords -fuck-your-pdf (I mean, did
you get at least this far?). We don't have any more flags to tell you
you're not in Kansas, Dorothy. You don't give us more.
There's nothing undefined about the concept of "Linux boots on MIPS".
THERE IS LITERALLY NO OTHER DEFINITION OF A KERNEL AND IT WORKS WHEN I
BUILD THE TOOLCHAIN. If you fucked it up, that's not our problem.
cmake+llvm builds with -Wno-maybe-uninitialized. They can't even fix
their warnings, so they hide it. This is not a compiler, it's a random
number generator.
---
I came here as a last, desperate stance to get organized and shovel the
shit back in the horse, and this is what I find. Oh well. At least it
will be educational.
On Thu, Jan 21, 2021 at 08:32:35AM +0100, Gy?rgy Andrasek wrote:
> > This is basically a revert of commit 644592d32837 ("objtool: Fail the
> kernel build on fatal errors").
>
> > That change turned out to be more trouble than it's worth.
>
> ...I'm sorry, what? Fatal errors are normal for you people? Seriously? I've
> been compiling my own kernel since 2004, I've never seen one. I'd like some
> explanation on this.
>
I'm sorry, who are you? And why are you wasting our time with your drivel?
This mailing list is not a place to work on your anger management issues,
please find a therapist.
Thanks,
-- Steve
On Thu, Jan 21, 2021 at 08:32:35AM +0100, Gy?rgy Andrasek wrote:
> I'm rejecting both these morons as invalid. Please review everything they've
> been doing lately.
As Stephen said, please take this elsewhere, it does not belong on the
Linux kernel mailing lists.
greg k-h