[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YrMwXAs9apFRdkVo@debian>
Date: Wed, 22 Jun 2022 16:08:12 +0100
From: Sudip Mukherjee <sudipm.mukherjee@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Nathan Chancellor <nathan@...nel.org>,
Kees Cook <keescook@...omium.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Netdev <netdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang
support")
Hi Linus,
On Wed, Jun 22, 2022 at 08:47:22AM -0500, Linus Torvalds wrote:
> On Wed, Jun 22, 2022 at 5:23 AM Sudip Mukherjee
> <sudipm.mukherjee@...il.com> wrote:
> >
> > I have recently (since yesterday) started building the mainline kernel
> > with clang-14 and I am seeing a build failure with allmodconfig.
>
> Yeah, the clang build has never been allmodconfig-clean, although I
> think it's starting to get pretty close.
>
> I build the kernel I actually _use_ with clang, and make sure it's
> clean in sane configurations, but my full allmodconfig build I do with
> gcc.
After yesterday's stable report about clang build, I have now added clang
to my nightly builds apart from running gcc also. Both x86_64 and arm64
gave this error. Trying to add arm, mips, powerpc and riscv with clang
also, which all failed due to some configuration issue and I might ask
for help from Nick, Nathan if I can't figure that out.
>
> Partly because of that "the clang build hasn't quite gotten there yet"
> and partly because last I tried it was even slower to build (not a big
> issue for my default config, but does matter for the allmodconfig
> build, even on my beefy home machine)
I am going to run them every night and will report back problems.
>
> I would love for people to start doing allmodconfig builds with clang
> too, but it would require some initial work to fix it... Hint, hint.
>
> And in the case of this warning attribute case, the clang error messages are
>
> (a) verbose
>
> (b) useless
>
> because they point to where the warning attribute is (I know where it
> is), but don't point to where it's actually triggering (ie where it
> was actually inlined and called from).
Yeah, true. I had to check to find out its from the memcpy() in check_image_valid().
--
Regards
Sudip
Powered by blists - more mailing lists