[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK7LNAR1+vxpwLVYgX1jaREav6EkJDoZtwGoKmEPoQLkSbPeHA@mail.gmail.com>
Date: Sun, 20 Dec 2020 03:45:19 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Kees Cook <keescook@...omium.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] gcc-plugins updates for v5.11-rc1
On Sat, Dec 19, 2020 at 3:50 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Wed, Dec 16, 2020 at 12:23 PM Kees Cook <keescook@...omium.org> wrote:
> >
> > Hmm. Yeah, that's a bug. I think that's an existing bug, though. I feel
> > like I scratched my head on that too. I will see if there is a sensible
> > way to have Kbuild "notice" that -- I hope there's an easier way to
> > invalidate all object files instead of adding all the plugins as a dep
> > to all .o builds. O_o
>
> Side note, there's actually a more annoying issue with the gcc plugin
> config code.
>
> Namely that when I get a compiler update, the rest of the Kconfig
> system is smart, and rebuilds all my files.
True. The full rebuild happens after commit 8b59cd81dc5e724.
>
> The gcc-plugins code? The code that *really* depends on the compiler
> version even more? Yeah, not so much. It ends up instead causing a
> build error like
>
> cc1: error: incompatible gcc/plugin versions
> cc1: error: failed to initialize plugin
> ./scripts/gcc-plugins/stackleak_plugin.so
>
> because the plugins don't depend on the compiler version.
>
> Again, this is not new, but it's another example of how fragile and
> annoying the gcc-plugins code can be.
>
> Linus
OK, I will fix it. Thanks.
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists