When building kernel with scan-build for analysis:
$ scan-build make defconfig
$ scan-build make menuconfig # disable RETPOLINE
$ scan-build make -j16 bindeb-pkg
since commit 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
it fails with:
CC scripts/mod/empty.o
could not find clang line
make[4]: *** [scripts/Makefile.build:287: scripts/mod/empty.o] Error 1
Seems like changes to how -fconserve-stack support was detected broke
build with scan-build. Revert part of mentioned commit which changed
that.
Fixes: 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
CC: Nick Desaulniers <[email protected]>
Signed-off-by: Amadeusz Sławiński <[email protected]>
Reviewed-by: Cezary Rojewski <[email protected]>
---
Makefile | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 765115c99655..1174ccd182f5 100644
--- a/Makefile
+++ b/Makefile
@@ -991,9 +991,7 @@ KBUILD_CFLAGS += -fno-strict-overflow
KBUILD_CFLAGS += -fno-stack-check
# conserve stack if available
-ifdef CONFIG_CC_IS_GCC
-KBUILD_CFLAGS += -fconserve-stack
-endif
+KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
# Prohibit date/time macros, which would make the build non-deterministic
KBUILD_CFLAGS += -Werror=date-time
--
2.25.1
On Wed, Jan 19, 2022 at 02:51:47PM +0100, Amadeusz Sławiński wrote:
> When building kernel with scan-build for analysis:
> $ scan-build make defconfig
> $ scan-build make menuconfig # disable RETPOLINE
> $ scan-build make -j16 bindeb-pkg
> since commit 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> it fails with:
> CC scripts/mod/empty.o
> could not find clang line
> make[4]: *** [scripts/Makefile.build:287: scripts/mod/empty.o] Error 1
>
> Seems like changes to how -fconserve-stack support was detected broke
> build with scan-build. Revert part of mentioned commit which changed
> that.
>
> Fixes: 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> CC: Nick Desaulniers <[email protected]>
> Signed-off-by: Amadeusz Sławiński <[email protected]>
> Reviewed-by: Cezary Rojewski <[email protected]>
> ---
> Makefile | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 765115c99655..1174ccd182f5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -991,9 +991,7 @@ KBUILD_CFLAGS += -fno-strict-overflow
> KBUILD_CFLAGS += -fno-stack-check
>
> # conserve stack if available
> -ifdef CONFIG_CC_IS_GCC
> -KBUILD_CFLAGS += -fconserve-stack
> -endif
> +KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
>
> # Prohibit date/time macros, which would make the build non-deterministic
> KBUILD_CFLAGS += -Werror=date-time
> --
> 2.25.1
>
Okay, I think I understand why this happens...
scan-build points CC to its CC wrapper [1], ccc-analyzer, which builds the
code with a compiler [2] then runs clang for the static analyzer [3].
The problem is that the default compiler for ccc-analyzer is GCC, which
means that CONFIG_CC_IS_GCC gets set and flags that are supported by GCC
but not clang will cause the clang analyzer part of ccc-analyzer to
error because ccc-analyzer just passes all '-f' flags along [4].
Prior to 7d73c3e9c514, there was no error because cc-option would run
the flag against ccc-analyzer, which would error out for the reason I
just described, which would prevent the flag from getting added to
KBUILD_CFLAGS.
Now, -fconserve-stack gets passed along to both gcc and clang but clang
does not recognize it and errors out.
This should be fixed in clang, which already has the machinery to
recognize but ignore GCC flags for compatibility reasons (which is
probably how gcc and clang can use the same flags). I have pushed a
patch to Phabricator for review:
https://reviews.llvm.org/D117717
You need to disable CONFIG_RETPOLINE for the same reason but I don't
think working around that in clang is as simple.
Until that fix can proliferate through distributions and such, this is
not an unreasonable workaround (unless Masahiro or Nick have a better
idea) but I would really like a comment so that we can revert this once
that fix is more widely available (it is unlikely that clang will
actually support this option).
[1]: https://github.com/llvm/llvm-project/blob/3062a1469da0569e714aa4634b29345f6d8c874c/clang/tools/scan-build/bin/scan-build#L1080
[2]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L457
[3]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L783
[4]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L661-L665
Cheers,
Nathan
On Wed, Jan 19, 2022 at 02:19:39PM -0700, Nathan Chancellor wrote:
> On Wed, Jan 19, 2022 at 02:51:47PM +0100, Amadeusz Sławiński wrote:
> > When building kernel with scan-build for analysis:
> > $ scan-build make defconfig
> > $ scan-build make menuconfig # disable RETPOLINE
> > $ scan-build make -j16 bindeb-pkg
> > since commit 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> > it fails with:
> > CC scripts/mod/empty.o
> > could not find clang line
> > make[4]: *** [scripts/Makefile.build:287: scripts/mod/empty.o] Error 1
> >
> > Seems like changes to how -fconserve-stack support was detected broke
> > build with scan-build. Revert part of mentioned commit which changed
> > that.
> >
> > Fixes: 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> > CC: Nick Desaulniers <[email protected]>
> > Signed-off-by: Amadeusz Sławiński <[email protected]>
> > Reviewed-by: Cezary Rojewski <[email protected]>
> > ---
> > Makefile | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 765115c99655..1174ccd182f5 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -991,9 +991,7 @@ KBUILD_CFLAGS += -fno-strict-overflow
> > KBUILD_CFLAGS += -fno-stack-check
> >
> > # conserve stack if available
> > -ifdef CONFIG_CC_IS_GCC
> > -KBUILD_CFLAGS += -fconserve-stack
> > -endif
> > +KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
> >
> > # Prohibit date/time macros, which would make the build non-deterministic
> > KBUILD_CFLAGS += -Werror=date-time
> > --
> > 2.25.1
> >
>
> Okay, I think I understand why this happens...
>
> scan-build points CC to its CC wrapper [1], ccc-analyzer, which builds the
> code with a compiler [2] then runs clang for the static analyzer [3].
> The problem is that the default compiler for ccc-analyzer is GCC, which
> means that CONFIG_CC_IS_GCC gets set and flags that are supported by GCC
> but not clang will cause the clang analyzer part of ccc-analyzer to
> error because ccc-analyzer just passes all '-f' flags along [4].
>
> Prior to 7d73c3e9c514, there was no error because cc-option would run
> the flag against ccc-analyzer, which would error out for the reason I
> just described, which would prevent the flag from getting added to
> KBUILD_CFLAGS.
>
> Now, -fconserve-stack gets passed along to both gcc and clang but clang
> does not recognize it and errors out.
>
> This should be fixed in clang, which already has the machinery to
> recognize but ignore GCC flags for compatibility reasons (which is
> probably how gcc and clang can use the same flags). I have pushed a
> patch to Phabricator for review:
>
> https://reviews.llvm.org/D117717
>
> You need to disable CONFIG_RETPOLINE for the same reason but I don't
> think working around that in clang is as simple.
>
> Until that fix can proliferate through distributions and such, this is
> not an unreasonable workaround (unless Masahiro or Nick have a better
> idea) but I would really like a comment so that we can revert this once
> that fix is more widely available (it is unlikely that clang will
> actually support this option).
>
> [1]: https://github.com/llvm/llvm-project/blob/3062a1469da0569e714aa4634b29345f6d8c874c/clang/tools/scan-build/bin/scan-build#L1080
> [2]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L457
> [3]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L783
> [4]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L661-L665
Thinking more about this after Fangrui commented on the clang patch
above, using scan-build with GCC as the compiler is going to be hard to
support, as we are basically trying to support using two different
compilers with a unified set of '-f' flags, which I see as problematic
for a few reasons.
1. It restricts our ability to do cc-option cleanups like Nick did.
We should be eliminating cc-option calls that we know are specific to
one compiler because checking the Kconfig variables (CONFIG_CC_IS_...)
is much cheaper than invoking the compiler.
2. Necessary GCC specific flags will get dropped.
Adding back the call to cc-option will allow the build to succeed but it
drops the flag from KBUILD_CFLAGS. If there were ever a time where an
'-f' flag was needed to get a working kernel with GCC, it would not get
added because clang would reject it.
We already have a static-analyzer target that requires using CC=clang so
I think there is some precedent here to say we require the kernel to be
built with clang to use the static analyzer. The fact that it did prior
to 7d73c3e9c514 can just be chalked up to luck.
$ make -j"$(nproc)" LLVM=1 defconfig bindeb-pkg static-analyzer
would be the equivalent command to the original patch.
You can still use scan-build with the '--use-cc=clang' flag, which will
use clang for the compilation and analysis, if you so prefer.
Masahiro and Nick may have further thoughts and I am open to other
opinions but my vote is to say this is an issue we won't fix or
workaround.
Cheers,
Nathan
On 1/20/2022 12:08 AM, Nathan Chancellor wrote:
> On Wed, Jan 19, 2022 at 02:19:39PM -0700, Nathan Chancellor wrote:
>> On Wed, Jan 19, 2022 at 02:51:47PM +0100, Amadeusz Sławiński wrote:
>>> When building kernel with scan-build for analysis:
>>> $ scan-build make defconfig
>>> $ scan-build make menuconfig # disable RETPOLINE
>>> $ scan-build make -j16 bindeb-pkg
>>> since commit 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
>>> it fails with:
>>> CC scripts/mod/empty.o
>>> could not find clang line
>>> make[4]: *** [scripts/Makefile.build:287: scripts/mod/empty.o] Error 1
>>>
>>> Seems like changes to how -fconserve-stack support was detected broke
>>> build with scan-build. Revert part of mentioned commit which changed
>>> that.
>>>
>>> Fixes: 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
>>> CC: Nick Desaulniers <[email protected]>
>>> Signed-off-by: Amadeusz Sławiński <[email protected]>
>>> Reviewed-by: Cezary Rojewski <[email protected]>
>>> ---
>>> Makefile | 4 +---
>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 765115c99655..1174ccd182f5 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -991,9 +991,7 @@ KBUILD_CFLAGS += -fno-strict-overflow
>>> KBUILD_CFLAGS += -fno-stack-check
>>>
>>> # conserve stack if available
>>> -ifdef CONFIG_CC_IS_GCC
>>> -KBUILD_CFLAGS += -fconserve-stack
>>> -endif
>>> +KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
>>>
>>> # Prohibit date/time macros, which would make the build non-deterministic
>>> KBUILD_CFLAGS += -Werror=date-time
>>> --
>>> 2.25.1
>>>
>>
>> Okay, I think I understand why this happens...
>>
>> scan-build points CC to its CC wrapper [1], ccc-analyzer, which builds the
>> code with a compiler [2] then runs clang for the static analyzer [3].
>> The problem is that the default compiler for ccc-analyzer is GCC, which
>> means that CONFIG_CC_IS_GCC gets set and flags that are supported by GCC
>> but not clang will cause the clang analyzer part of ccc-analyzer to
>> error because ccc-analyzer just passes all '-f' flags along [4].
>>
>> Prior to 7d73c3e9c514, there was no error because cc-option would run
>> the flag against ccc-analyzer, which would error out for the reason I
>> just described, which would prevent the flag from getting added to
>> KBUILD_CFLAGS.
>>
>> Now, -fconserve-stack gets passed along to both gcc and clang but clang
>> does not recognize it and errors out.
>>
>> This should be fixed in clang, which already has the machinery to
>> recognize but ignore GCC flags for compatibility reasons (which is
>> probably how gcc and clang can use the same flags). I have pushed a
>> patch to Phabricator for review:
>>
>> https://reviews.llvm.org/D117717
>>
>> You need to disable CONFIG_RETPOLINE for the same reason but I don't
>> think working around that in clang is as simple.
>>
>> Until that fix can proliferate through distributions and such, this is
>> not an unreasonable workaround (unless Masahiro or Nick have a better
>> idea) but I would really like a comment so that we can revert this once
>> that fix is more widely available (it is unlikely that clang will
>> actually support this option).
>>
>> [1]: https://github.com/llvm/llvm-project/blob/3062a1469da0569e714aa4634b29345f6d8c874c/clang/tools/scan-build/bin/scan-build#L1080
>> [2]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L457
>> [3]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L783
>> [4]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L661-L665
>
> Thinking more about this after Fangrui commented on the clang patch
> above, using scan-build with GCC as the compiler is going to be hard to
> support, as we are basically trying to support using two different
> compilers with a unified set of '-f' flags, which I see as problematic
> for a few reasons.
>
> 1. It restricts our ability to do cc-option cleanups like Nick did.
>
> We should be eliminating cc-option calls that we know are specific to
> one compiler because checking the Kconfig variables (CONFIG_CC_IS_...)
> is much cheaper than invoking the compiler.
>
> 2. Necessary GCC specific flags will get dropped.
>
> Adding back the call to cc-option will allow the build to succeed but it
> drops the flag from KBUILD_CFLAGS. If there were ever a time where an
> '-f' flag was needed to get a working kernel with GCC, it would not get
> added because clang would reject it.
>
> We already have a static-analyzer target that requires using CC=clang so
> I think there is some precedent here to say we require the kernel to be
> built with clang to use the static analyzer. The fact that it did prior
> to 7d73c3e9c514 can just be chalked up to luck.
>
> $ make -j"$(nproc)" LLVM=1 defconfig bindeb-pkg static-analyzer
>
> would be the equivalent command to the original patch.
>
> You can still use scan-build with the '--use-cc=clang' flag, which will
> use clang for the compilation and analysis, if you so prefer.
>
> Masahiro and Nick may have further thoughts and I am open to other
> opinions but my vote is to say this is an issue we won't fix or
> workaround.
>
> Cheers,
> Nathan
Thank you for detailed explanation. Well I guess question then is: how
much scan-build is supported? And if it should even support mixing clang
and gcc? Alternatively maybe use clang as default if CC environment
variable is not set?
What I like about scan-build is that it generates html report file.
'--use-cc=clang' worked fine for me.
I've also tried
> $ make -j"$(nproc)" LLVM=1 defconfig bindeb-pkg static-analyzer
although there seems to be no static-analyzer target, I guess you meant
clang-analyzer instead, but although it seems to generate a lot of text
on terminal, it doesn't seem that useful to me. Not sure if this is
expected?
Quoting a piece of log:
./include/linux/xarray.h:54:2: error: expected '(' after 'asm'
[clang-diagnostic-error]
WARN_ON((long)v < 0);
^
./include/asm-generic/bug.h:123:3: note: expanded from macro 'WARN_ON'
__WARN(); \
^
./include/asm-generic/bug.h:96:19: note: expanded from macro '__WARN'
#define __WARN() __WARN_FLAGS(BUGFLAG_TAINT(TAINT_WARN))
^
./arch/x86/include/asm/bug.h:79:2: note: expanded from macro '__WARN_FLAGS'
_BUG_FLAGS(ASM_UD2, BUGFLAG_WARNING|(flags)); \
^
./arch/x86/include/asm/bug.h:27:2: note: expanded from macro '_BUG_FLAGS'
asm_inline volatile("1:\t" ins "\n" \
^
./include/linux/compiler_types.h:281:24: note: expanded from macro
'asm_inline'
#define asm_inline asm __inline
^
./include/linux/xarray.h:1616:2: error: expected '(' after 'asm'
[clang-diagnostic-error]
BUG_ON(order > 0);
^
./include/asm-generic/bug.h:65:57: note: expanded from macro 'BUG_ON'
#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
^
./arch/x86/include/asm/bug.h:66:2: note: expanded from macro 'BUG'
_BUG_FLAGS(ASM_UD2, 0); \
^
./arch/x86/include/asm/bug.h:27:2: note: expanded from macro '_BUG_FLAGS'
asm_inline volatile("1:\t" ins "\n" \
^
./include/linux/compiler_types.h:281:24: note: expanded from macro
'asm_inline'
#define asm_inline asm __inline
^
Found compiler error(s).
21 errors generated.
Error while processing /home/xxxxxxxx/linux/drivers/hid/hid-ezkey.c.
error: too many errors emitted, stopping now [clang-diagnostic-error]
error: unknown argument: '-fno-stack-clash-protection'
[clang-diagnostic-error]
error: unknown warning option '-Wno-frame-address'; did you mean
'-Wno-address'? [clang-diagnostic-unknown-warning-option]
error: unknown warning option '-Wno-pointer-to-enum-cast'; did you mean
'-Wno-pointer-compare'? [clang-diagnostic-unknown-warning-option]
Unless I did something wrong, this doesn't seem that useful to me
compared to what I get from scan-build?
Cheers,
Amadeusz
On Fri, Jan 21, 2022 at 12:20:39PM +0100, Amadeusz Sławiński wrote:
> On 1/20/2022 12:08 AM, Nathan Chancellor wrote:
> > On Wed, Jan 19, 2022 at 02:19:39PM -0700, Nathan Chancellor wrote:
> > > On Wed, Jan 19, 2022 at 02:51:47PM +0100, Amadeusz Sławiński wrote:
> > > > When building kernel with scan-build for analysis:
> > > > $ scan-build make defconfig
> > > > $ scan-build make menuconfig # disable RETPOLINE
> > > > $ scan-build make -j16 bindeb-pkg
> > > > since commit 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> > > > it fails with:
> > > > CC scripts/mod/empty.o
> > > > could not find clang line
> > > > make[4]: *** [scripts/Makefile.build:287: scripts/mod/empty.o] Error 1
> > > >
> > > > Seems like changes to how -fconserve-stack support was detected broke
> > > > build with scan-build. Revert part of mentioned commit which changed
> > > > that.
> > > >
> > > > Fixes: 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> > > > CC: Nick Desaulniers <[email protected]>
> > > > Signed-off-by: Amadeusz Sławiński <[email protected]>
> > > > Reviewed-by: Cezary Rojewski <[email protected]>
> > > > ---
> > > > Makefile | 4 +---
> > > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > > >
> > > > diff --git a/Makefile b/Makefile
> > > > index 765115c99655..1174ccd182f5 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -991,9 +991,7 @@ KBUILD_CFLAGS += -fno-strict-overflow
> > > > KBUILD_CFLAGS += -fno-stack-check
> > > > # conserve stack if available
> > > > -ifdef CONFIG_CC_IS_GCC
> > > > -KBUILD_CFLAGS += -fconserve-stack
> > > > -endif
> > > > +KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
> > > > # Prohibit date/time macros, which would make the build non-deterministic
> > > > KBUILD_CFLAGS += -Werror=date-time
> > > > --
> > > > 2.25.1
> > > >
> > >
> > > Okay, I think I understand why this happens...
> > >
> > > scan-build points CC to its CC wrapper [1], ccc-analyzer, which builds the
> > > code with a compiler [2] then runs clang for the static analyzer [3].
> > > The problem is that the default compiler for ccc-analyzer is GCC, which
> > > means that CONFIG_CC_IS_GCC gets set and flags that are supported by GCC
> > > but not clang will cause the clang analyzer part of ccc-analyzer to
> > > error because ccc-analyzer just passes all '-f' flags along [4].
> > >
> > > Prior to 7d73c3e9c514, there was no error because cc-option would run
> > > the flag against ccc-analyzer, which would error out for the reason I
> > > just described, which would prevent the flag from getting added to
> > > KBUILD_CFLAGS.
> > >
> > > Now, -fconserve-stack gets passed along to both gcc and clang but clang
> > > does not recognize it and errors out.
> > >
> > > This should be fixed in clang, which already has the machinery to
> > > recognize but ignore GCC flags for compatibility reasons (which is
> > > probably how gcc and clang can use the same flags). I have pushed a
> > > patch to Phabricator for review:
> > >
> > > https://reviews.llvm.org/D117717
> > >
> > > You need to disable CONFIG_RETPOLINE for the same reason but I don't
> > > think working around that in clang is as simple.
> > >
> > > Until that fix can proliferate through distributions and such, this is
> > > not an unreasonable workaround (unless Masahiro or Nick have a better
> > > idea) but I would really like a comment so that we can revert this once
> > > that fix is more widely available (it is unlikely that clang will
> > > actually support this option).
> > >
> > > [1]: https://github.com/llvm/llvm-project/blob/3062a1469da0569e714aa4634b29345f6d8c874c/clang/tools/scan-build/bin/scan-build#L1080
> > > [2]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L457
> > > [3]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L783
> > > [4]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L661-L665
> >
> > Thinking more about this after Fangrui commented on the clang patch
> > above, using scan-build with GCC as the compiler is going to be hard to
> > support, as we are basically trying to support using two different
> > compilers with a unified set of '-f' flags, which I see as problematic
> > for a few reasons.
> >
> > 1. It restricts our ability to do cc-option cleanups like Nick did.
> >
> > We should be eliminating cc-option calls that we know are specific to
> > one compiler because checking the Kconfig variables (CONFIG_CC_IS_...)
> > is much cheaper than invoking the compiler.
> >
> > 2. Necessary GCC specific flags will get dropped.
> >
> > Adding back the call to cc-option will allow the build to succeed but it
> > drops the flag from KBUILD_CFLAGS. If there were ever a time where an
> > '-f' flag was needed to get a working kernel with GCC, it would not get
> > added because clang would reject it.
> >
> > We already have a static-analyzer target that requires using CC=clang so
> > I think there is some precedent here to say we require the kernel to be
> > built with clang to use the static analyzer. The fact that it did prior
> > to 7d73c3e9c514 can just be chalked up to luck.
> >
> > $ make -j"$(nproc)" LLVM=1 defconfig bindeb-pkg static-analyzer
> >
> > would be the equivalent command to the original patch.
> >
> > You can still use scan-build with the '--use-cc=clang' flag, which will
> > use clang for the compilation and analysis, if you so prefer.
> >
> > Masahiro and Nick may have further thoughts and I am open to other
> > opinions but my vote is to say this is an issue we won't fix or
> > workaround.
> >
> > Cheers,
> > Nathan
>
>
> Thank you for detailed explanation. Well I guess question then is: how much
> scan-build is supported? And if it should even support mixing clang and gcc?
> Alternatively maybe use clang as default if CC environment variable is not
> set?
It probably shouldn't, as least not in the way that it currently does.
Someone on the LLVM review I created suggested it should add a filter
for flags that clang does not support from GCC. I think changing the
default would be another good fix but doesn't fix the issue if someone
does actually wants to use GCC for building.
> What I like about scan-build is that it generates html report file.
Ah, that is a good point.
> '--use-cc=clang' worked fine for me.
>
> I've also tried
> > $ make -j"$(nproc)" LLVM=1 defconfig bindeb-pkg static-analyzer
> although there seems to be no static-analyzer target, I guess you meant
> clang-analyzer instead, but although it seems to generate a lot of text on
> terminal, it doesn't seem that useful to me. Not sure if this is expected?
Yes, my apologies, it should have been clang-analyzer.
> Quoting a piece of log:
> ./include/linux/xarray.h:54:2: error: expected '(' after 'asm'
> [clang-diagnostic-error]
> WARN_ON((long)v < 0);
> ^
> ./include/asm-generic/bug.h:123:3: note: expanded from macro 'WARN_ON'
> __WARN(); \
> ^
> ./include/asm-generic/bug.h:96:19: note: expanded from macro '__WARN'
> #define __WARN() __WARN_FLAGS(BUGFLAG_TAINT(TAINT_WARN))
> ^
> ./arch/x86/include/asm/bug.h:79:2: note: expanded from macro '__WARN_FLAGS'
> _BUG_FLAGS(ASM_UD2, BUGFLAG_WARNING|(flags)); \
> ^
> ./arch/x86/include/asm/bug.h:27:2: note: expanded from macro '_BUG_FLAGS'
> asm_inline volatile("1:\t" ins "\n" \
> ^
> ./include/linux/compiler_types.h:281:24: note: expanded from macro
> 'asm_inline'
> #define asm_inline asm __inline
> ^
> ./include/linux/xarray.h:1616:2: error: expected '(' after 'asm'
> [clang-diagnostic-error]
> BUG_ON(order > 0);
> ^
> ./include/asm-generic/bug.h:65:57: note: expanded from macro 'BUG_ON'
> #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
> ^
> ./arch/x86/include/asm/bug.h:66:2: note: expanded from macro 'BUG'
> _BUG_FLAGS(ASM_UD2, 0); \
> ^
> ./arch/x86/include/asm/bug.h:27:2: note: expanded from macro '_BUG_FLAGS'
> asm_inline volatile("1:\t" ins "\n" \
> ^
> ./include/linux/compiler_types.h:281:24: note: expanded from macro
> 'asm_inline'
> #define asm_inline asm __inline
> ^
> Found compiler error(s).
> 21 errors generated.
> Error while processing /home/xxxxxxxx/linux/drivers/hid/hid-ezkey.c.
> error: too many errors emitted, stopping now [clang-diagnostic-error]
> error: unknown argument: '-fno-stack-clash-protection'
> [clang-diagnostic-error]
> error: unknown warning option '-Wno-frame-address'; did you mean
> '-Wno-address'? [clang-diagnostic-unknown-warning-option]
> error: unknown warning option '-Wno-pointer-to-enum-cast'; did you mean
> '-Wno-pointer-compare'? [clang-diagnostic-unknown-warning-option]
>
>
> Unless I did something wrong, this doesn't seem that useful to me compared
> to what I get from scan-build?
I do not see that error but I have little experience with running the
clang-analyzer target. It might be due to a difference between
scan-build and clang-tidy? Regardless, it seems like you prefer reading
the HTML report, so sticking with scan-build with the '--use-cc=clang'
flag will be the way to go.
Cheers,
Nathan
On Sat, Jan 22, 2022 at 1:47 AM Nathan Chancellor <[email protected]> wrote:
>
> On Fri, Jan 21, 2022 at 12:20:39PM +0100, Amadeusz Sławiński wrote:
> > On 1/20/2022 12:08 AM, Nathan Chancellor wrote:
> > > On Wed, Jan 19, 2022 at 02:19:39PM -0700, Nathan Chancellor wrote:
> > > > On Wed, Jan 19, 2022 at 02:51:47PM +0100, Amadeusz Sławiński wrote:
> > > > > When building kernel with scan-build for analysis:
> > > > > $ scan-build make defconfig
> > > > > $ scan-build make menuconfig # disable RETPOLINE
> > > > > $ scan-build make -j16 bindeb-pkg
> > > > > since commit 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> > > > > it fails with:
> > > > > CC scripts/mod/empty.o
> > > > > could not find clang line
> > > > > make[4]: *** [scripts/Makefile.build:287: scripts/mod/empty.o] Error 1
> > > > >
> > > > > Seems like changes to how -fconserve-stack support was detected broke
> > > > > build with scan-build. Revert part of mentioned commit which changed
> > > > > that.
> > > > >
> > > > > Fixes: 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> > > > > CC: Nick Desaulniers <[email protected]>
> > > > > Signed-off-by: Amadeusz Sławiński <[email protected]>
> > > > > Reviewed-by: Cezary Rojewski <[email protected]>
> > > > > ---
> > > > > Makefile | 4 +---
> > > > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/Makefile b/Makefile
> > > > > index 765115c99655..1174ccd182f5 100644
> > > > > --- a/Makefile
> > > > > +++ b/Makefile
> > > > > @@ -991,9 +991,7 @@ KBUILD_CFLAGS += -fno-strict-overflow
> > > > > KBUILD_CFLAGS += -fno-stack-check
> > > > > # conserve stack if available
> > > > > -ifdef CONFIG_CC_IS_GCC
> > > > > -KBUILD_CFLAGS += -fconserve-stack
> > > > > -endif
> > > > > +KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
> > > > > # Prohibit date/time macros, which would make the build non-deterministic
> > > > > KBUILD_CFLAGS += -Werror=date-time
> > > > > --
> > > > > 2.25.1
> > > > >
> > > >
> > > > Okay, I think I understand why this happens...
> > > >
> > > > scan-build points CC to its CC wrapper [1], ccc-analyzer, which builds the
> > > > code with a compiler [2] then runs clang for the static analyzer [3].
> > > > The problem is that the default compiler for ccc-analyzer is GCC, which
> > > > means that CONFIG_CC_IS_GCC gets set and flags that are supported by GCC
> > > > but not clang will cause the clang analyzer part of ccc-analyzer to
> > > > error because ccc-analyzer just passes all '-f' flags along [4].
> > > >
> > > > Prior to 7d73c3e9c514, there was no error because cc-option would run
> > > > the flag against ccc-analyzer, which would error out for the reason I
> > > > just described, which would prevent the flag from getting added to
> > > > KBUILD_CFLAGS.
> > > >
> > > > Now, -fconserve-stack gets passed along to both gcc and clang but clang
> > > > does not recognize it and errors out.
> > > >
> > > > This should be fixed in clang, which already has the machinery to
> > > > recognize but ignore GCC flags for compatibility reasons (which is
> > > > probably how gcc and clang can use the same flags). I have pushed a
> > > > patch to Phabricator for review:
> > > >
> > > > https://reviews.llvm.org/D117717
> > > >
> > > > You need to disable CONFIG_RETPOLINE for the same reason but I don't
> > > > think working around that in clang is as simple.
> > > >
> > > > Until that fix can proliferate through distributions and such, this is
> > > > not an unreasonable workaround (unless Masahiro or Nick have a better
> > > > idea) but I would really like a comment so that we can revert this once
> > > > that fix is more widely available (it is unlikely that clang will
> > > > actually support this option).
> > > >
> > > > [1]: https://github.com/llvm/llvm-project/blob/3062a1469da0569e714aa4634b29345f6d8c874c/clang/tools/scan-build/bin/scan-build#L1080
> > > > [2]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L457
> > > > [3]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L783
> > > > [4]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L661-L665
> > >
> > > Thinking more about this after Fangrui commented on the clang patch
> > > above, using scan-build with GCC as the compiler is going to be hard to
> > > support, as we are basically trying to support using two different
> > > compilers with a unified set of '-f' flags, which I see as problematic
> > > for a few reasons.
> > >
> > > 1. It restricts our ability to do cc-option cleanups like Nick did.
> > >
> > > We should be eliminating cc-option calls that we know are specific to
> > > one compiler because checking the Kconfig variables (CONFIG_CC_IS_...)
> > > is much cheaper than invoking the compiler.
> > >
> > > 2. Necessary GCC specific flags will get dropped.
> > >
> > > Adding back the call to cc-option will allow the build to succeed but it
> > > drops the flag from KBUILD_CFLAGS. If there were ever a time where an
> > > '-f' flag was needed to get a working kernel with GCC, it would not get
> > > added because clang would reject it.
> > >
> > > We already have a static-analyzer target that requires using CC=clang so
> > > I think there is some precedent here to say we require the kernel to be
> > > built with clang to use the static analyzer. The fact that it did prior
> > > to 7d73c3e9c514 can just be chalked up to luck.
> > >
> > > $ make -j"$(nproc)" LLVM=1 defconfig bindeb-pkg static-analyzer
> > >
> > > would be the equivalent command to the original patch.
> > >
> > > You can still use scan-build with the '--use-cc=clang' flag, which will
> > > use clang for the compilation and analysis, if you so prefer.
> > >
> > > Masahiro and Nick may have further thoughts and I am open to other
> > > opinions but my vote is to say this is an issue we won't fix or
> > > workaround.
> > >
> > > Cheers,
> > > Nathan
> >
> >
> > Thank you for detailed explanation. Well I guess question then is: how much
> > scan-build is supported? And if it should even support mixing clang and gcc?
> > Alternatively maybe use clang as default if CC environment variable is not
> > set?
>
> It probably shouldn't, as least not in the way that it currently does.
> Someone on the LLVM review I created suggested it should add a filter
> for flags that clang does not support from GCC. I think changing the
> default would be another good fix but doesn't fix the issue if someone
> does actually wants to use GCC for building.
>
> > What I like about scan-build is that it generates html report file.
>
> Ah, that is a good point.
>
> > '--use-cc=clang' worked fine for me.
> >
> > I've also tried
> > > $ make -j"$(nproc)" LLVM=1 defconfig bindeb-pkg static-analyzer
> > although there seems to be no static-analyzer target, I guess you meant
> > clang-analyzer instead, but although it seems to generate a lot of text on
> > terminal, it doesn't seem that useful to me. Not sure if this is expected?
>
> Yes, my apologies, it should have been clang-analyzer.
>
> > Quoting a piece of log:
> > ./include/linux/xarray.h:54:2: error: expected '(' after 'asm'
> > [clang-diagnostic-error]
> > WARN_ON((long)v < 0);
> > ^
> > ./include/asm-generic/bug.h:123:3: note: expanded from macro 'WARN_ON'
> > __WARN(); \
> > ^
> > ./include/asm-generic/bug.h:96:19: note: expanded from macro '__WARN'
> > #define __WARN() __WARN_FLAGS(BUGFLAG_TAINT(TAINT_WARN))
> > ^
> > ./arch/x86/include/asm/bug.h:79:2: note: expanded from macro '__WARN_FLAGS'
> > _BUG_FLAGS(ASM_UD2, BUGFLAG_WARNING|(flags)); \
> > ^
> > ./arch/x86/include/asm/bug.h:27:2: note: expanded from macro '_BUG_FLAGS'
> > asm_inline volatile("1:\t" ins "\n" \
> > ^
> > ./include/linux/compiler_types.h:281:24: note: expanded from macro
> > 'asm_inline'
> > #define asm_inline asm __inline
> > ^
> > ./include/linux/xarray.h:1616:2: error: expected '(' after 'asm'
> > [clang-diagnostic-error]
> > BUG_ON(order > 0);
> > ^
> > ./include/asm-generic/bug.h:65:57: note: expanded from macro 'BUG_ON'
> > #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
> > ^
> > ./arch/x86/include/asm/bug.h:66:2: note: expanded from macro 'BUG'
> > _BUG_FLAGS(ASM_UD2, 0); \
> > ^
> > ./arch/x86/include/asm/bug.h:27:2: note: expanded from macro '_BUG_FLAGS'
> > asm_inline volatile("1:\t" ins "\n" \
> > ^
> > ./include/linux/compiler_types.h:281:24: note: expanded from macro
> > 'asm_inline'
> > #define asm_inline asm __inline
> > ^
> > Found compiler error(s).
> > 21 errors generated.
> > Error while processing /home/xxxxxxxx/linux/drivers/hid/hid-ezkey.c.
> > error: too many errors emitted, stopping now [clang-diagnostic-error]
> > error: unknown argument: '-fno-stack-clash-protection'
> > [clang-diagnostic-error]
> > error: unknown warning option '-Wno-frame-address'; did you mean
> > '-Wno-address'? [clang-diagnostic-unknown-warning-option]
> > error: unknown warning option '-Wno-pointer-to-enum-cast'; did you mean
> > '-Wno-pointer-compare'? [clang-diagnostic-unknown-warning-option]
> >
> >
> > Unless I did something wrong, this doesn't seem that useful to me compared
> > to what I get from scan-build?
>
> I do not see that error but I have little experience with running the
> clang-analyzer target. It might be due to a difference between
> scan-build and clang-tidy? Regardless, it seems like you prefer reading
> the HTML report, so sticking with scan-build with the '--use-cc=clang'
> flag will be the way to go.
>
> Cheers,
> Nathan
As far as I understood, the conclusion is
[1] There is nothing to fix on the Kbuild side.
(So, this patch was rejected)
[2] If you want to use scan-build for kbuild,
"scan-build --use-cc=clang" should work properly.
The "disable RETPOLINE' workaround is also unneeded.
$ scan-build --use-cc=clang make -j16 defconfig bindeb-pkg
should be enough
[3] If scan-build supports mixed-compilers, it is up to LLVM community.
If they are happy, they will carry the pain of maintaining ignored flags.
The detection of retpoline flags is not working somehow.
$ /usr/share/clang/scan-build-13/bin/../libexec/ccc-analyzer
-mindirect-branch=thunk-extern -c -x c /dev/null -o /dev/null
could not find clang line
$ /usr/share/clang/scan-build-13/bin/../libexec/ccc-analyzer
-mretpoline-external-thunk -c -x c /dev/null -o /dev/null
gcc: error: unrecognized command-line option ‘-mretpoline-external-thunk’
I think this should be fixed.
--
Best Regards
Masahiro Yamada
On Sat, Jan 22, 2022 at 08:53:00PM +0900, Masahiro Yamada wrote:
> On Sat, Jan 22, 2022 at 1:47 AM Nathan Chancellor <[email protected]> wrote:
> >
> > On Fri, Jan 21, 2022 at 12:20:39PM +0100, Amadeusz Sławiński wrote:
> > > On 1/20/2022 12:08 AM, Nathan Chancellor wrote:
> > > > On Wed, Jan 19, 2022 at 02:19:39PM -0700, Nathan Chancellor wrote:
> > > > > On Wed, Jan 19, 2022 at 02:51:47PM +0100, Amadeusz Sławiński wrote:
> > > > > > When building kernel with scan-build for analysis:
> > > > > > $ scan-build make defconfig
> > > > > > $ scan-build make menuconfig # disable RETPOLINE
> > > > > > $ scan-build make -j16 bindeb-pkg
> > > > > > since commit 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> > > > > > it fails with:
> > > > > > CC scripts/mod/empty.o
> > > > > > could not find clang line
> > > > > > make[4]: *** [scripts/Makefile.build:287: scripts/mod/empty.o] Error 1
> > > > > >
> > > > > > Seems like changes to how -fconserve-stack support was detected broke
> > > > > > build with scan-build. Revert part of mentioned commit which changed
> > > > > > that.
> > > > > >
> > > > > > Fixes: 7d73c3e9c514 ("Makefile: remove stale cc-option checks")
> > > > > > CC: Nick Desaulniers <[email protected]>
> > > > > > Signed-off-by: Amadeusz Sławiński <[email protected]>
> > > > > > Reviewed-by: Cezary Rojewski <[email protected]>
> > > > > > ---
> > > > > > Makefile | 4 +---
> > > > > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/Makefile b/Makefile
> > > > > > index 765115c99655..1174ccd182f5 100644
> > > > > > --- a/Makefile
> > > > > > +++ b/Makefile
> > > > > > @@ -991,9 +991,7 @@ KBUILD_CFLAGS += -fno-strict-overflow
> > > > > > KBUILD_CFLAGS += -fno-stack-check
> > > > > > # conserve stack if available
> > > > > > -ifdef CONFIG_CC_IS_GCC
> > > > > > -KBUILD_CFLAGS += -fconserve-stack
> > > > > > -endif
> > > > > > +KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
> > > > > > # Prohibit date/time macros, which would make the build non-deterministic
> > > > > > KBUILD_CFLAGS += -Werror=date-time
> > > > > > --
> > > > > > 2.25.1
> > > > > >
> > > > >
> > > > > Okay, I think I understand why this happens...
> > > > >
> > > > > scan-build points CC to its CC wrapper [1], ccc-analyzer, which builds the
> > > > > code with a compiler [2] then runs clang for the static analyzer [3].
> > > > > The problem is that the default compiler for ccc-analyzer is GCC, which
> > > > > means that CONFIG_CC_IS_GCC gets set and flags that are supported by GCC
> > > > > but not clang will cause the clang analyzer part of ccc-analyzer to
> > > > > error because ccc-analyzer just passes all '-f' flags along [4].
> > > > >
> > > > > Prior to 7d73c3e9c514, there was no error because cc-option would run
> > > > > the flag against ccc-analyzer, which would error out for the reason I
> > > > > just described, which would prevent the flag from getting added to
> > > > > KBUILD_CFLAGS.
> > > > >
> > > > > Now, -fconserve-stack gets passed along to both gcc and clang but clang
> > > > > does not recognize it and errors out.
> > > > >
> > > > > This should be fixed in clang, which already has the machinery to
> > > > > recognize but ignore GCC flags for compatibility reasons (which is
> > > > > probably how gcc and clang can use the same flags). I have pushed a
> > > > > patch to Phabricator for review:
> > > > >
> > > > > https://reviews.llvm.org/D117717
> > > > >
> > > > > You need to disable CONFIG_RETPOLINE for the same reason but I don't
> > > > > think working around that in clang is as simple.
> > > > >
> > > > > Until that fix can proliferate through distributions and such, this is
> > > > > not an unreasonable workaround (unless Masahiro or Nick have a better
> > > > > idea) but I would really like a comment so that we can revert this once
> > > > > that fix is more widely available (it is unlikely that clang will
> > > > > actually support this option).
> > > > >
> > > > > [1]: https://github.com/llvm/llvm-project/blob/3062a1469da0569e714aa4634b29345f6d8c874c/clang/tools/scan-build/bin/scan-build#L1080
> > > > > [2]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L457
> > > > > [3]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L783
> > > > > [4]: https://github.com/llvm/llvm-project/blob/fd0782a37bbf7dd4ece721df92c703a381595661/clang/tools/scan-build/libexec/ccc-analyzer#L661-L665
> > > >
> > > > Thinking more about this after Fangrui commented on the clang patch
> > > > above, using scan-build with GCC as the compiler is going to be hard to
> > > > support, as we are basically trying to support using two different
> > > > compilers with a unified set of '-f' flags, which I see as problematic
> > > > for a few reasons.
> > > >
> > > > 1. It restricts our ability to do cc-option cleanups like Nick did.
> > > >
> > > > We should be eliminating cc-option calls that we know are specific to
> > > > one compiler because checking the Kconfig variables (CONFIG_CC_IS_...)
> > > > is much cheaper than invoking the compiler.
> > > >
> > > > 2. Necessary GCC specific flags will get dropped.
> > > >
> > > > Adding back the call to cc-option will allow the build to succeed but it
> > > > drops the flag from KBUILD_CFLAGS. If there were ever a time where an
> > > > '-f' flag was needed to get a working kernel with GCC, it would not get
> > > > added because clang would reject it.
> > > >
> > > > We already have a static-analyzer target that requires using CC=clang so
> > > > I think there is some precedent here to say we require the kernel to be
> > > > built with clang to use the static analyzer. The fact that it did prior
> > > > to 7d73c3e9c514 can just be chalked up to luck.
> > > >
> > > > $ make -j"$(nproc)" LLVM=1 defconfig bindeb-pkg static-analyzer
> > > >
> > > > would be the equivalent command to the original patch.
> > > >
> > > > You can still use scan-build with the '--use-cc=clang' flag, which will
> > > > use clang for the compilation and analysis, if you so prefer.
> > > >
> > > > Masahiro and Nick may have further thoughts and I am open to other
> > > > opinions but my vote is to say this is an issue we won't fix or
> > > > workaround.
> > > >
> > > > Cheers,
> > > > Nathan
> > >
> > >
> > > Thank you for detailed explanation. Well I guess question then is: how much
> > > scan-build is supported? And if it should even support mixing clang and gcc?
> > > Alternatively maybe use clang as default if CC environment variable is not
> > > set?
> >
> > It probably shouldn't, as least not in the way that it currently does.
> > Someone on the LLVM review I created suggested it should add a filter
> > for flags that clang does not support from GCC. I think changing the
> > default would be another good fix but doesn't fix the issue if someone
> > does actually wants to use GCC for building.
> >
> > > What I like about scan-build is that it generates html report file.
> >
> > Ah, that is a good point.
> >
> > > '--use-cc=clang' worked fine for me.
> > >
> > > I've also tried
> > > > $ make -j"$(nproc)" LLVM=1 defconfig bindeb-pkg static-analyzer
> > > although there seems to be no static-analyzer target, I guess you meant
> > > clang-analyzer instead, but although it seems to generate a lot of text on
> > > terminal, it doesn't seem that useful to me. Not sure if this is expected?
> >
> > Yes, my apologies, it should have been clang-analyzer.
> >
> > > Quoting a piece of log:
> > > ./include/linux/xarray.h:54:2: error: expected '(' after 'asm'
> > > [clang-diagnostic-error]
> > > WARN_ON((long)v < 0);
> > > ^
> > > ./include/asm-generic/bug.h:123:3: note: expanded from macro 'WARN_ON'
> > > __WARN(); \
> > > ^
> > > ./include/asm-generic/bug.h:96:19: note: expanded from macro '__WARN'
> > > #define __WARN() __WARN_FLAGS(BUGFLAG_TAINT(TAINT_WARN))
> > > ^
> > > ./arch/x86/include/asm/bug.h:79:2: note: expanded from macro '__WARN_FLAGS'
> > > _BUG_FLAGS(ASM_UD2, BUGFLAG_WARNING|(flags)); \
> > > ^
> > > ./arch/x86/include/asm/bug.h:27:2: note: expanded from macro '_BUG_FLAGS'
> > > asm_inline volatile("1:\t" ins "\n" \
> > > ^
> > > ./include/linux/compiler_types.h:281:24: note: expanded from macro
> > > 'asm_inline'
> > > #define asm_inline asm __inline
> > > ^
> > > ./include/linux/xarray.h:1616:2: error: expected '(' after 'asm'
> > > [clang-diagnostic-error]
> > > BUG_ON(order > 0);
> > > ^
> > > ./include/asm-generic/bug.h:65:57: note: expanded from macro 'BUG_ON'
> > > #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
> > > ^
> > > ./arch/x86/include/asm/bug.h:66:2: note: expanded from macro 'BUG'
> > > _BUG_FLAGS(ASM_UD2, 0); \
> > > ^
> > > ./arch/x86/include/asm/bug.h:27:2: note: expanded from macro '_BUG_FLAGS'
> > > asm_inline volatile("1:\t" ins "\n" \
> > > ^
> > > ./include/linux/compiler_types.h:281:24: note: expanded from macro
> > > 'asm_inline'
> > > #define asm_inline asm __inline
> > > ^
> > > Found compiler error(s).
> > > 21 errors generated.
> > > Error while processing /home/xxxxxxxx/linux/drivers/hid/hid-ezkey.c.
> > > error: too many errors emitted, stopping now [clang-diagnostic-error]
> > > error: unknown argument: '-fno-stack-clash-protection'
> > > [clang-diagnostic-error]
> > > error: unknown warning option '-Wno-frame-address'; did you mean
> > > '-Wno-address'? [clang-diagnostic-unknown-warning-option]
> > > error: unknown warning option '-Wno-pointer-to-enum-cast'; did you mean
> > > '-Wno-pointer-compare'? [clang-diagnostic-unknown-warning-option]
> > >
> > >
> > > Unless I did something wrong, this doesn't seem that useful to me compared
> > > to what I get from scan-build?
> >
> > I do not see that error but I have little experience with running the
> > clang-analyzer target. It might be due to a difference between
> > scan-build and clang-tidy? Regardless, it seems like you prefer reading
> > the HTML report, so sticking with scan-build with the '--use-cc=clang'
> > flag will be the way to go.
> >
> > Cheers,
> > Nathan
>
>
>
> As far as I understood, the conclusion is
>
> [1] There is nothing to fix on the Kbuild side.
> (So, this patch was rejected)
>
>
> [2] If you want to use scan-build for kbuild,
> "scan-build --use-cc=clang" should work properly.
>
> The "disable RETPOLINE' workaround is also unneeded.
>
> $ scan-build --use-cc=clang make -j16 defconfig bindeb-pkg
>
> should be enough
>
>
> [3] If scan-build supports mixed-compilers, it is up to LLVM community.
> If they are happy, they will carry the pain of maintaining ignored flags.
>
>
>
> The detection of retpoline flags is not working somehow.
>
> $ /usr/share/clang/scan-build-13/bin/../libexec/ccc-analyzer
> -mindirect-branch=thunk-extern -c -x c /dev/null -o /dev/null
> could not find clang line
> $ /usr/share/clang/scan-build-13/bin/../libexec/ccc-analyzer
> -mretpoline-external-thunk -c -x c /dev/null -o /dev/null
> gcc: error: unrecognized command-line option ‘-mretpoline-external-thunk’
>
> I think this should be fixed.
It looks like this happens for the same reason as the error in the
patch:
https://github.com/llvm/llvm-project/blob/c1988dbf2d191d771e3a396eaa6396500965787d/clang/tools/scan-build/libexec/ccc-analyzer#L604
All '-m' flags get forwarded along from the compiler to clang. Because
clang and GCC use different flags for retpoline, there will always be an
error when ccc-analyzer is used with GCC as the compiler. It sounds like
there is some agreement upstream that this is a problem; how it will be
solved remains to be seen but I don't think the kernel should work
around this, which goes along with point #1.
Cheers,
Nathan