[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiJ7xt913Lf6rfeq4CyffhXwHLVZ2ZABcKHmV8cf0FArg@mail.gmail.com>
Date: Thu, 17 Dec 2020 09:27:24 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>,
Lyude Paul <lyude@...hat.com>,
Ilia Mirkin <imirkin@...m.mit.edu>
Cc: Peter Zijlstra <peterz@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: New objtool warning..
On Thu, Dec 17, 2020 at 8:25 AM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> Oh yeah, I forgot about that. That would be another option if my patch
> doesn't work out.
Well, one option is to just say "ok, we know gcc generates horrible
code that falls through to another function in a situation that we
claim is unreachable, so let's not claim it is unreachable".
IOW, the problem here is that the compiler fundamentally isn't smart
enough to see that something is unreachable, and the "unreachable()"
annotation we did didn't actually really cause any code that makes it
so. So we basically have code that _if_ we ever change it, it will
simply be wrong, and we'll never see any warnings about it but it will
fall through to nonsensical code.
So maybe the option here is simply "objtool was right before, the
unreachable() is fragile and wrong".
We can easily write that case statement in a way that actually makes
the compiler generate better code and avoids the issue by just making
case 0x00 also be the default case.
So I think I'll just apply this patch instead.
Linus
Download attachment "patch" of type "application/octet-stream" (791 bytes)
Powered by blists - more mailing lists