| Message ID | 20220119135147.1859982-1-amadeuszx.slawinski@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Makefile: Fix build with scan-build | expand |
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 <ndesaulniers@google.com> > Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> > Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> > --- > 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 <ndesaulniers@google.com> > > Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> > > Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> > > --- > > 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 <ndesaulniers@google.com> >>> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> >>> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> >>> --- >>> 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 <ndesaulniers@google.com> > > > > Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> > > > > Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> > > > > --- > > > > 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 <nathan@kernel.org> 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 <ndesaulniers@google.com> > > > > > Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> > > > > > Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> > > > > > --- > > > > > 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.
On Sat, Jan 22, 2022 at 08:53:00PM +0900, Masahiro Yamada wrote: > On Sat, Jan 22, 2022 at 1:47 AM Nathan Chancellor <nathan@kernel.org> 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 <ndesaulniers@google.com> > > > > > > Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> > > > > > > Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> > > > > > > --- > > > > > > 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
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
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 <ndesaulniers@google.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> --- Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)