* [PATCH] gcc-plugins: simplify GCC plugin-dev capability test @ 2020-12-03 12:57 Masahiro Yamada 2020-12-03 17:37 ` Linus Torvalds ` (3 more replies) 0 siblings, 4 replies; 18+ messages in thread From: Masahiro Yamada @ 2020-12-03 12:57 UTC (permalink / raw) To: linux-kbuild, Kees Cook, Emese Revfy, linux-hardening Cc: Linus Torvalds, Masahiro Yamada, Nathan Chancellor, Nick Desaulniers, clang-built-linux, linux-kernel Linus pointed out a third of the time in the Kconfig parse stage comes from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], and directly testing plugin-version.h for existence cuts down the overhead a lot. [2] This commit takes one step further to kill the build test entirely. The small piece of code was probably intended to test the C++ designated initializer, which was not supported until C++20. In fact, with -pedantic option given, both GCC and Clang emit a warning. $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] class test { public: int test; } test = { .test = 1 }; ^ 1 warning generated. Otherwise, modern C++ compilers should be able to build the code, and hopefully skipping this test should not make any practical problem. Checking the existence of plugin-version.h is still needed to ensure the plugin-dev package is installed. The test code is now small enough to be embedded in scripts/gcc-plugins/Kconfig. [1] https://lore.kernel.org/lkml/CAHk-=wjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ@mail.gmail.com/ [2] https://lore.kernel.org/lkml/CAHk-=whK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig=+vnw@mail.gmail.com/ Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> --- scripts/gcc-plugin.sh | 19 ------------------- scripts/gcc-plugins/Kconfig | 2 +- 2 files changed, 1 insertion(+), 20 deletions(-) delete mode 100755 scripts/gcc-plugin.sh diff --git a/scripts/gcc-plugin.sh b/scripts/gcc-plugin.sh deleted file mode 100755 index b79fd0bea838..000000000000 --- a/scripts/gcc-plugin.sh +++ /dev/null @@ -1,19 +0,0 @@ -#!/bin/sh -# SPDX-License-Identifier: GPL-2.0 - -set -e - -srctree=$(dirname "$0") - -gccplugins_dir=$($* -print-file-name=plugin) - -# we need a c++ compiler that supports the designated initializer GNU extension -$HOSTCC -c -x c++ -std=gnu++98 - -fsyntax-only -I $srctree/gcc-plugins -I $gccplugins_dir/include 2>/dev/null <<EOF -#include "gcc-common.h" -class test { -public: - int test; -} test = { - .test = 1 -}; -EOF diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig index ae19fb0243b9..ab9eb4cbe33a 100644 --- a/scripts/gcc-plugins/Kconfig +++ b/scripts/gcc-plugins/Kconfig @@ -9,7 +9,7 @@ menuconfig GCC_PLUGINS bool "GCC plugins" depends on HAVE_GCC_PLUGINS depends on CC_IS_GCC - depends on $(success,$(srctree)/scripts/gcc-plugin.sh $(CC)) + depends on $(success,test -e $(shell,$(CC) -print-file-name=plugin)/include/plugin-version.h) default y help GCC plugins are loadable modules that provide extra features to the -- 2.27.0 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-03 12:57 [PATCH] gcc-plugins: simplify GCC plugin-dev capability test Masahiro Yamada @ 2020-12-03 17:37 ` Linus Torvalds 2020-12-04 22:02 ` Kees Cook ` (2 subsequent siblings) 3 siblings, 0 replies; 18+ messages in thread From: Linus Torvalds @ 2020-12-03 17:37 UTC (permalink / raw) To: Masahiro Yamada Cc: Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List On Thu, Dec 3, 2020 at 5:03 AM Masahiro Yamada <masahiroy@kernel.org> wrote: > > Checking the existence of plugin-version.h is still needed to ensure > the plugin-dev package is installed. The test code is now small enough > to be embedded in scripts/gcc-plugins/Kconfig. Ack. I think the "plugin" directory name should be quoted, but that's a pre-existing bug. Linus ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-03 12:57 [PATCH] gcc-plugins: simplify GCC plugin-dev capability test Masahiro Yamada 2020-12-03 17:37 ` Linus Torvalds @ 2020-12-04 22:02 ` Kees Cook 2020-12-04 23:46 ` Kees Cook [not found] ` <CGME20201218075758eucas1p1605768803a5c9edce4fbe54b3e3b859a@eucas1p1.samsung.com> 3 siblings, 0 replies; 18+ messages in thread From: Kees Cook @ 2020-12-04 22:02 UTC (permalink / raw) To: Masahiro Yamada Cc: linux-kbuild, Emese Revfy, linux-hardening, Linus Torvalds, Nathan Chancellor, Nick Desaulniers, clang-built-linux, linux-kernel On Thu, Dec 03, 2020 at 09:57:00PM +0900, Masahiro Yamada wrote: > Linus pointed out a third of the time in the Kconfig parse stage comes > from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], > and directly testing plugin-version.h for existence cuts down the > overhead a lot. [2] > > This commit takes one step further to kill the build test entirely. > > The small piece of code was probably intended to test the C++ designated > initializer, which was not supported until C++20. > > In fact, with -pedantic option given, both GCC and Clang emit a warning. > > $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only > <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] > $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only > <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] > class test { public: int test; } test = { .test = 1 }; > ^ > 1 warning generated. > > Otherwise, modern C++ compilers should be able to build the code, and > hopefully skipping this test should not make any practical problem. > > Checking the existence of plugin-version.h is still needed to ensure > the plugin-dev package is installed. The test code is now small enough > to be embedded in scripts/gcc-plugins/Kconfig. > > [1] https://lore.kernel.org/lkml/CAHk-=wjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ@mail.gmail.com/ > [2] https://lore.kernel.org/lkml/CAHk-=whK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig=+vnw@mail.gmail.com/ > > Reported-by: Linus Torvalds <torvalds@linux-foundation.org> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Kees Cook <keescook@chromium.org> -- Kees Cook ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-03 12:57 [PATCH] gcc-plugins: simplify GCC plugin-dev capability test Masahiro Yamada 2020-12-03 17:37 ` Linus Torvalds 2020-12-04 22:02 ` Kees Cook @ 2020-12-04 23:46 ` Kees Cook [not found] ` <CGME20201218075758eucas1p1605768803a5c9edce4fbe54b3e3b859a@eucas1p1.samsung.com> 3 siblings, 0 replies; 18+ messages in thread From: Kees Cook @ 2020-12-04 23:46 UTC (permalink / raw) To: linux-kbuild, Emese Revfy, linux-hardening, Masahiro Yamada Cc: Kees Cook, clang-built-linux, Nick Desaulniers, linux-kernel, Nathan Chancellor, Linus Torvalds On Thu, 3 Dec 2020 21:57:00 +0900, Masahiro Yamada wrote: > Linus pointed out a third of the time in the Kconfig parse stage comes > from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], > and directly testing plugin-version.h for existence cuts down the > overhead a lot. [2] > > This commit takes one step further to kill the build test entirely. > > [...] Applied to for-next/gcc-plugins, thanks! [1/1] gcc-plugins: simplify GCC plugin-dev capability test https://git.kernel.org/kees/c/1e860048c53e -- Kees Cook ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <CGME20201218075758eucas1p1605768803a5c9edce4fbe54b3e3b859a@eucas1p1.samsung.com>]
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test [not found] ` <CGME20201218075758eucas1p1605768803a5c9edce4fbe54b3e3b859a@eucas1p1.samsung.com> @ 2020-12-18 7:57 ` Marek Szyprowski 2020-12-18 9:43 ` Masahiro Yamada 0 siblings, 1 reply; 18+ messages in thread From: Marek Szyprowski @ 2020-12-18 7:57 UTC (permalink / raw) To: Masahiro Yamada, linux-kbuild, Kees Cook, Emese Revfy, linux-hardening Cc: Linus Torvalds, Nathan Chancellor, Nick Desaulniers, clang-built-linux, linux-kernel Hi, On 03.12.2020 13:57, Masahiro Yamada wrote: > Linus pointed out a third of the time in the Kconfig parse stage comes > from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], > and directly testing plugin-version.h for existence cuts down the > overhead a lot. [2] > > This commit takes one step further to kill the build test entirely. > > The small piece of code was probably intended to test the C++ designated > initializer, which was not supported until C++20. > > In fact, with -pedantic option given, both GCC and Clang emit a warning. > > $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only > <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] > $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only > <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] > class test { public: int test; } test = { .test = 1 }; > ^ > 1 warning generated. > > Otherwise, modern C++ compilers should be able to build the code, and > hopefully skipping this test should not make any practical problem. > > Checking the existence of plugin-version.h is still needed to ensure > the plugin-dev package is installed. The test code is now small enough > to be embedded in scripts/gcc-plugins/Kconfig. > > [1] https://lore.kernel.org/lkml/CAHk-=wjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ@mail.gmail.com/ > [2] https://lore.kernel.org/lkml/CAHk-=whK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig=+vnw@mail.gmail.com/ > > Reported-by: Linus Torvalds <torvalds@linux-foundation.org> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> This patch landed in linux next-20201217 as commit 1e860048c53e ("gcc-plugins: simplify GCC plugin-dev capability test"). It causes a build break with my tests setup, but I'm not sure weather it is really an issue of this commit or a toolchain I use. However I've checked various versions of the gcc cross-compilers released by Linaro at https://releases.linaro.org/components/toolchain/binaries/ and all fails with the same error: $ make ARCH=arm CROSS_COMPILE=../../cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/arm-none-eabi- zImage HOSTCXX scripts/gcc-plugins/arm_ssp_per_task_plugin.so In file included from /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/gcc-plugin.h:28:0, from scripts/gcc-plugins/gcc-common.h:7, from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3: /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/system.h:687:10: fatal error: gmp.h: No such file or directory #include <gmp.h> ^~~~~~~ compilation terminated. scripts/gcc-plugins/Makefile:47: recipe for target 'scripts/gcc-plugins/arm_ssp_per_task_plugin.so' failed make[2]: *** [scripts/gcc-plugins/arm_ssp_per_task_plugin.so] Error 1 scripts/Makefile.build:496: recipe for target 'scripts/gcc-plugins' failed make[1]: *** [scripts/gcc-plugins] Error 2 Makefile:1190: recipe for target 'scripts' failed make: *** [scripts] Error 2 Compilation works if I use the cross-gcc provided by gcc-7-arm-linux-gnueabi/gcc-arm-linux-gnueabi Ubuntu packages, which is: $ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 7:57 ` Marek Szyprowski @ 2020-12-18 9:43 ` Masahiro Yamada 2020-12-18 10:05 ` Marek Szyprowski 0 siblings, 1 reply; 18+ messages in thread From: Masahiro Yamada @ 2020-12-18 9:43 UTC (permalink / raw) To: Marek Szyprowski Cc: Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Linus Torvalds, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > Hi, > > On 03.12.2020 13:57, Masahiro Yamada wrote: > > Linus pointed out a third of the time in the Kconfig parse stage comes > > from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], > > and directly testing plugin-version.h for existence cuts down the > > overhead a lot. [2] > > > > This commit takes one step further to kill the build test entirely. > > > > The small piece of code was probably intended to test the C++ designated > > initializer, which was not supported until C++20. > > > > In fact, with -pedantic option given, both GCC and Clang emit a warning. > > > > $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only > > <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] > > $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only > > <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] > > class test { public: int test; } test = { .test = 1 }; > > ^ > > 1 warning generated. > > > > Otherwise, modern C++ compilers should be able to build the code, and > > hopefully skipping this test should not make any practical problem. > > > > Checking the existence of plugin-version.h is still needed to ensure > > the plugin-dev package is installed. The test code is now small enough > > to be embedded in scripts/gcc-plugins/Kconfig. > > > > [1] https://lore.kernel.org/lkml/CAHk-=wjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ@mail.gmail.com/ > > [2] https://lore.kernel.org/lkml/CAHk-=whK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig=+vnw@mail.gmail.com/ > > > > Reported-by: Linus Torvalds <torvalds@linux-foundation.org> > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > > This patch landed in linux next-20201217 as commit 1e860048c53e > ("gcc-plugins: simplify GCC plugin-dev capability test"). > > It causes a build break with my tests setup, but I'm not sure weather it > is really an issue of this commit or a toolchain I use. However I've > checked various versions of the gcc cross-compilers released by Linaro > at https://releases.linaro.org/components/toolchain/binaries/ and all > fails with the same error: > > $ make ARCH=arm > CROSS_COMPILE=../../cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/arm-none-eabi- > zImage > HOSTCXX scripts/gcc-plugins/arm_ssp_per_task_plugin.so > In file included from > /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/gcc-plugin.h:28:0, > from scripts/gcc-plugins/gcc-common.h:7, > from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3: > /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/system.h:687:10: > fatal error: gmp.h: No such file or directory > #include <gmp.h> > ^~~~~~~ > compilation terminated. > scripts/gcc-plugins/Makefile:47: recipe for target > 'scripts/gcc-plugins/arm_ssp_per_task_plugin.so' failed > make[2]: *** [scripts/gcc-plugins/arm_ssp_per_task_plugin.so] Error 1 > scripts/Makefile.build:496: recipe for target 'scripts/gcc-plugins' failed > make[1]: *** [scripts/gcc-plugins] Error 2 > Makefile:1190: recipe for target 'scripts' failed > make: *** [scripts] Error 2 > > Compilation works if I use the cross-gcc provided by > gcc-7-arm-linux-gnueabi/gcc-arm-linux-gnueabi Ubuntu packages, which is: > > $ arm-linux-gnueabi-gcc --version > arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 > > Best regards > > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > I can compile gcc-plugins with Linaro toolchians. The version of mine is this: masahiro@oscar:~/ref/linux-next$ ~/tools/arm-linaro-7.5/bin/arm-linux-gnueabihf-gcc --version arm-linux-gnueabihf-gcc (Linaro GCC 7.5-2019.12) 7.5.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Maybe, it depends on the host environment? Please try this: $ sudo apt install libgmp-dev -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 9:43 ` Masahiro Yamada @ 2020-12-18 10:05 ` Marek Szyprowski 2020-12-18 15:03 ` Jon Hunter 0 siblings, 1 reply; 18+ messages in thread From: Marek Szyprowski @ 2020-12-18 10:05 UTC (permalink / raw) To: Masahiro Yamada Cc: Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Linus Torvalds, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List On 18.12.2020 10:43, Masahiro Yamada wrote: > On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski > <m.szyprowski@samsung.com> wrote: >> On 03.12.2020 13:57, Masahiro Yamada wrote: >>> Linus pointed out a third of the time in the Kconfig parse stage comes >>> from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], >>> and directly testing plugin-version.h for existence cuts down the >>> overhead a lot. [2] >>> >>> This commit takes one step further to kill the build test entirely. >>> >>> The small piece of code was probably intended to test the C++ designated >>> initializer, which was not supported until C++20. >>> >>> In fact, with -pedantic option given, both GCC and Clang emit a warning. >>> >>> $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only >>> <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] >>> $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only >>> <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] >>> class test { public: int test; } test = { .test = 1 }; >>> ^ >>> 1 warning generated. >>> >>> Otherwise, modern C++ compilers should be able to build the code, and >>> hopefully skipping this test should not make any practical problem. >>> >>> Checking the existence of plugin-version.h is still needed to ensure >>> the plugin-dev package is installed. The test code is now small enough >>> to be embedded in scripts/gcc-plugins/Kconfig. >>> >>> [1] https://protect2.fireeye.com/v1/url?k=03db90e1-5c40a828-03da1bae-0cc47a336fae-4cc36f5830aeb78d&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ%40mail.gmail.com%2F >>> [2] https://protect2.fireeye.com/v1/url?k=965b670a-c9c05fc3-965aec45-0cc47a336fae-e34339513ff747c0&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwhK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig%3D%2Bvnw%40mail.gmail.com%2F >>> >>> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> >>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> >> This patch landed in linux next-20201217 as commit 1e860048c53e >> ("gcc-plugins: simplify GCC plugin-dev capability test"). >> >> It causes a build break with my tests setup, but I'm not sure weather it >> is really an issue of this commit or a toolchain I use. However I've >> checked various versions of the gcc cross-compilers released by Linaro >> at https://protect2.fireeye.com/v1/url?k=053727b6-5aac1f7f-0536acf9-0cc47a336fae-5bd799e7ce6b1b9b&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Freleases.linaro.org%2Fcomponents%2Ftoolchain%2Fbinaries%2F and all >> fails with the same error: >> >> $ make ARCH=arm >> CROSS_COMPILE=../../cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/arm-none-eabi- >> zImage >> HOSTCXX scripts/gcc-plugins/arm_ssp_per_task_plugin.so >> In file included from >> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/gcc-plugin.h:28:0, >> from scripts/gcc-plugins/gcc-common.h:7, >> from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3: >> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/system.h:687:10: >> fatal error: gmp.h: No such file or directory >> #include <gmp.h> >> ^~~~~~~ >> compilation terminated. >> scripts/gcc-plugins/Makefile:47: recipe for target >> 'scripts/gcc-plugins/arm_ssp_per_task_plugin.so' failed >> make[2]: *** [scripts/gcc-plugins/arm_ssp_per_task_plugin.so] Error 1 >> scripts/Makefile.build:496: recipe for target 'scripts/gcc-plugins' failed >> make[1]: *** [scripts/gcc-plugins] Error 2 >> Makefile:1190: recipe for target 'scripts' failed >> make: *** [scripts] Error 2 >> >> Compilation works if I use the cross-gcc provided by >> gcc-7-arm-linux-gnueabi/gcc-arm-linux-gnueabi Ubuntu packages, which is: >> >> $ arm-linux-gnueabi-gcc --version >> arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 >> > > I can compile gcc-plugins with Linaro toolchians. > > The version of mine is this: > > masahiro@oscar:~/ref/linux-next$ > ~/tools/arm-linaro-7.5/bin/arm-linux-gnueabihf-gcc --version > arm-linux-gnueabihf-gcc (Linaro GCC 7.5-2019.12) 7.5.0 > Copyright (C) 2017 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > > > Maybe, it depends on the host environment? > > > Please try this: > > $ sudo apt install libgmp-dev Indeed, it was missing on my setup. Sorry for the noise. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 10:05 ` Marek Szyprowski @ 2020-12-18 15:03 ` Jon Hunter 2020-12-18 15:09 ` Marek Szyprowski 0 siblings, 1 reply; 18+ messages in thread From: Jon Hunter @ 2020-12-18 15:03 UTC (permalink / raw) To: Marek Szyprowski, Masahiro Yamada Cc: Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Linus Torvalds, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List, linux-tegra On 18/12/2020 10:05, Marek Szyprowski wrote: > On 18.12.2020 10:43, Masahiro Yamada wrote: >> On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski >> <m.szyprowski@samsung.com> wrote: >>> On 03.12.2020 13:57, Masahiro Yamada wrote: >>>> Linus pointed out a third of the time in the Kconfig parse stage comes >>>> from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], >>>> and directly testing plugin-version.h for existence cuts down the >>>> overhead a lot. [2] >>>> >>>> This commit takes one step further to kill the build test entirely. >>>> >>>> The small piece of code was probably intended to test the C++ designated >>>> initializer, which was not supported until C++20. >>>> >>>> In fact, with -pedantic option given, both GCC and Clang emit a warning. >>>> >>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only >>>> <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] >>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only >>>> <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] >>>> class test { public: int test; } test = { .test = 1 }; >>>> ^ >>>> 1 warning generated. >>>> >>>> Otherwise, modern C++ compilers should be able to build the code, and >>>> hopefully skipping this test should not make any practical problem. >>>> >>>> Checking the existence of plugin-version.h is still needed to ensure >>>> the plugin-dev package is installed. The test code is now small enough >>>> to be embedded in scripts/gcc-plugins/Kconfig. >>>> >>>> [1] https://protect2.fireeye.com/v1/url?k=03db90e1-5c40a828-03da1bae-0cc47a336fae-4cc36f5830aeb78d&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ%40mail.gmail.com%2F >>>> [2] https://protect2.fireeye.com/v1/url?k=965b670a-c9c05fc3-965aec45-0cc47a336fae-e34339513ff747c0&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwhK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig%3D%2Bvnw%40mail.gmail.com%2F >>>> >>>> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> >>>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> >>> This patch landed in linux next-20201217 as commit 1e860048c53e >>> ("gcc-plugins: simplify GCC plugin-dev capability test"). >>> >>> It causes a build break with my tests setup, but I'm not sure weather it >>> is really an issue of this commit or a toolchain I use. However I've >>> checked various versions of the gcc cross-compilers released by Linaro >>> at https://protect2.fireeye.com/v1/url?k=053727b6-5aac1f7f-0536acf9-0cc47a336fae-5bd799e7ce6b1b9b&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Freleases.linaro.org%2Fcomponents%2Ftoolchain%2Fbinaries%2F and all >>> fails with the same error: >>> >>> $ make ARCH=arm >>> CROSS_COMPILE=../../cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/arm-none-eabi- >>> zImage >>> HOSTCXX scripts/gcc-plugins/arm_ssp_per_task_plugin.so >>> In file included from >>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/gcc-plugin.h:28:0, >>> from scripts/gcc-plugins/gcc-common.h:7, >>> from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3: >>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/system.h:687:10: >>> fatal error: gmp.h: No such file or directory >>> #include <gmp.h> >>> ^~~~~~~ >>> compilation terminated. >>> scripts/gcc-plugins/Makefile:47: recipe for target >>> 'scripts/gcc-plugins/arm_ssp_per_task_plugin.so' failed >>> make[2]: *** [scripts/gcc-plugins/arm_ssp_per_task_plugin.so] Error 1 >>> scripts/Makefile.build:496: recipe for target 'scripts/gcc-plugins' failed >>> make[1]: *** [scripts/gcc-plugins] Error 2 >>> Makefile:1190: recipe for target 'scripts' failed >>> make: *** [scripts] Error 2 >>> >>> Compilation works if I use the cross-gcc provided by >>> gcc-7-arm-linux-gnueabi/gcc-arm-linux-gnueabi Ubuntu packages, which is: >>> >>> $ arm-linux-gnueabi-gcc --version >>> arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 >>> >> >> I can compile gcc-plugins with Linaro toolchians. >> >> The version of mine is this: >> >> masahiro@oscar:~/ref/linux-next$ >> ~/tools/arm-linaro-7.5/bin/arm-linux-gnueabihf-gcc --version >> arm-linux-gnueabihf-gcc (Linaro GCC 7.5-2019.12) 7.5.0 >> Copyright (C) 2017 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> >> >> >> Maybe, it depends on the host environment? >> >> >> Please try this: >> >> $ sudo apt install libgmp-dev > > Indeed, it was missing on my setup. Sorry for the noise. So this change also breaks the build on our farm build machines and while we can request that packages are installed on these machines, it takes time. Is there anyway to avoid this? Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 15:03 ` Jon Hunter @ 2020-12-18 15:09 ` Marek Szyprowski 2020-12-18 15:12 ` Jon Hunter 0 siblings, 1 reply; 18+ messages in thread From: Marek Szyprowski @ 2020-12-18 15:09 UTC (permalink / raw) To: Jon Hunter, Masahiro Yamada Cc: Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Linus Torvalds, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List, linux-tegra On 18.12.2020 16:03, Jon Hunter wrote: > On 18/12/2020 10:05, Marek Szyprowski wrote: >> On 18.12.2020 10:43, Masahiro Yamada wrote: >>> On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski >>> <m.szyprowski@samsung.com> wrote: >>>> On 03.12.2020 13:57, Masahiro Yamada wrote: >>>>> Linus pointed out a third of the time in the Kconfig parse stage comes >>>>> from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], >>>>> and directly testing plugin-version.h for existence cuts down the >>>>> overhead a lot. [2] >>>>> >>>>> This commit takes one step further to kill the build test entirely. >>>>> >>>>> The small piece of code was probably intended to test the C++ designated >>>>> initializer, which was not supported until C++20. >>>>> >>>>> In fact, with -pedantic option given, both GCC and Clang emit a warning. >>>>> >>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only >>>>> <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] >>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only >>>>> <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] >>>>> class test { public: int test; } test = { .test = 1 }; >>>>> ^ >>>>> 1 warning generated. >>>>> >>>>> Otherwise, modern C++ compilers should be able to build the code, and >>>>> hopefully skipping this test should not make any practical problem. >>>>> >>>>> Checking the existence of plugin-version.h is still needed to ensure >>>>> the plugin-dev package is installed. The test code is now small enough >>>>> to be embedded in scripts/gcc-plugins/Kconfig. >>>>> >>>>> [1] https://protect2.fireeye.com/v1/url?k=03db90e1-5c40a828-03da1bae-0cc47a336fae-4cc36f5830aeb78d&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ%40mail.gmail.com%2F >>>>> [2] https://protect2.fireeye.com/v1/url?k=965b670a-c9c05fc3-965aec45-0cc47a336fae-e34339513ff747c0&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwhK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig%3D%2Bvnw%40mail.gmail.com%2F >>>>> >>>>> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> >>>>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> >>>> This patch landed in linux next-20201217 as commit 1e860048c53e >>>> ("gcc-plugins: simplify GCC plugin-dev capability test"). >>>> >>>> It causes a build break with my tests setup, but I'm not sure weather it >>>> is really an issue of this commit or a toolchain I use. However I've >>>> checked various versions of the gcc cross-compilers released by Linaro >>>> at https://protect2.fireeye.com/v1/url?k=053727b6-5aac1f7f-0536acf9-0cc47a336fae-5bd799e7ce6b1b9b&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Freleases.linaro.org%2Fcomponents%2Ftoolchain%2Fbinaries%2F and all >>>> fails with the same error: >>>> >>>> $ make ARCH=arm >>>> CROSS_COMPILE=../../cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/arm-none-eabi- >>>> zImage >>>> HOSTCXX scripts/gcc-plugins/arm_ssp_per_task_plugin.so >>>> In file included from >>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/gcc-plugin.h:28:0, >>>> from scripts/gcc-plugins/gcc-common.h:7, >>>> from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3: >>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/system.h:687:10: >>>> fatal error: gmp.h: No such file or directory >>>> #include <gmp.h> >>>> ^~~~~~~ >>>> compilation terminated. >>>> scripts/gcc-plugins/Makefile:47: recipe for target >>>> 'scripts/gcc-plugins/arm_ssp_per_task_plugin.so' failed >>>> make[2]: *** [scripts/gcc-plugins/arm_ssp_per_task_plugin.so] Error 1 >>>> scripts/Makefile.build:496: recipe for target 'scripts/gcc-plugins' failed >>>> make[1]: *** [scripts/gcc-plugins] Error 2 >>>> Makefile:1190: recipe for target 'scripts' failed >>>> make: *** [scripts] Error 2 >>>> >>>> Compilation works if I use the cross-gcc provided by >>>> gcc-7-arm-linux-gnueabi/gcc-arm-linux-gnueabi Ubuntu packages, which is: >>>> >>>> $ arm-linux-gnueabi-gcc --version >>>> arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 >>>> >>> I can compile gcc-plugins with Linaro toolchians. >>> >>> The version of mine is this: >>> >>> masahiro@oscar:~/ref/linux-next$ >>> ~/tools/arm-linaro-7.5/bin/arm-linux-gnueabihf-gcc --version >>> arm-linux-gnueabihf-gcc (Linaro GCC 7.5-2019.12) 7.5.0 >>> Copyright (C) 2017 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >>> >>> >>> >>> >>> Maybe, it depends on the host environment? >>> >>> >>> Please try this: >>> >>> $ sudo apt install libgmp-dev >> Indeed, it was missing on my setup. Sorry for the noise. > > So this change also breaks the build on our farm build machines and > while we can request that packages are installed on these machines, it > takes time. Is there anyway to avoid this? You can temporarily revert 1e860048c53e (this patch). Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 15:09 ` Marek Szyprowski @ 2020-12-18 15:12 ` Jon Hunter 2020-12-18 15:33 ` Jon Hunter 0 siblings, 1 reply; 18+ messages in thread From: Jon Hunter @ 2020-12-18 15:12 UTC (permalink / raw) To: Marek Szyprowski, Masahiro Yamada Cc: Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Linus Torvalds, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List, linux-tegra On 18/12/2020 15:09, Marek Szyprowski wrote: > > On 18.12.2020 16:03, Jon Hunter wrote: >> On 18/12/2020 10:05, Marek Szyprowski wrote: >>> On 18.12.2020 10:43, Masahiro Yamada wrote: >>>> On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski >>>> <m.szyprowski@samsung.com> wrote: >>>>> On 03.12.2020 13:57, Masahiro Yamada wrote: >>>>>> Linus pointed out a third of the time in the Kconfig parse stage comes >>>>>> from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], >>>>>> and directly testing plugin-version.h for existence cuts down the >>>>>> overhead a lot. [2] >>>>>> >>>>>> This commit takes one step further to kill the build test entirely. >>>>>> >>>>>> The small piece of code was probably intended to test the C++ designated >>>>>> initializer, which was not supported until C++20. >>>>>> >>>>>> In fact, with -pedantic option given, both GCC and Clang emit a warning. >>>>>> >>>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only >>>>>> <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] >>>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only >>>>>> <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] >>>>>> class test { public: int test; } test = { .test = 1 }; >>>>>> ^ >>>>>> 1 warning generated. >>>>>> >>>>>> Otherwise, modern C++ compilers should be able to build the code, and >>>>>> hopefully skipping this test should not make any practical problem. >>>>>> >>>>>> Checking the existence of plugin-version.h is still needed to ensure >>>>>> the plugin-dev package is installed. The test code is now small enough >>>>>> to be embedded in scripts/gcc-plugins/Kconfig. >>>>>> >>>>>> [1] https://protect2.fireeye.com/v1/url?k=03db90e1-5c40a828-03da1bae-0cc47a336fae-4cc36f5830aeb78d&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ%40mail.gmail.com%2F >>>>>> [2] https://protect2.fireeye.com/v1/url?k=965b670a-c9c05fc3-965aec45-0cc47a336fae-e34339513ff747c0&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwhK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig%3D%2Bvnw%40mail.gmail.com%2F >>>>>> >>>>>> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> >>>>>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> >>>>> This patch landed in linux next-20201217 as commit 1e860048c53e >>>>> ("gcc-plugins: simplify GCC plugin-dev capability test"). >>>>> >>>>> It causes a build break with my tests setup, but I'm not sure weather it >>>>> is really an issue of this commit or a toolchain I use. However I've >>>>> checked various versions of the gcc cross-compilers released by Linaro >>>>> at https://protect2.fireeye.com/v1/url?k=053727b6-5aac1f7f-0536acf9-0cc47a336fae-5bd799e7ce6b1b9b&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Freleases.linaro.org%2Fcomponents%2Ftoolchain%2Fbinaries%2F and all >>>>> fails with the same error: >>>>> >>>>> $ make ARCH=arm >>>>> CROSS_COMPILE=../../cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/arm-none-eabi- >>>>> zImage >>>>> HOSTCXX scripts/gcc-plugins/arm_ssp_per_task_plugin.so >>>>> In file included from >>>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/gcc-plugin.h:28:0, >>>>> from scripts/gcc-plugins/gcc-common.h:7, >>>>> from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3: >>>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/system.h:687:10: >>>>> fatal error: gmp.h: No such file or directory >>>>> #include <gmp.h> >>>>> ^~~~~~~ >>>>> compilation terminated. >>>>> scripts/gcc-plugins/Makefile:47: recipe for target >>>>> 'scripts/gcc-plugins/arm_ssp_per_task_plugin.so' failed >>>>> make[2]: *** [scripts/gcc-plugins/arm_ssp_per_task_plugin.so] Error 1 >>>>> scripts/Makefile.build:496: recipe for target 'scripts/gcc-plugins' failed >>>>> make[1]: *** [scripts/gcc-plugins] Error 2 >>>>> Makefile:1190: recipe for target 'scripts' failed >>>>> make: *** [scripts] Error 2 >>>>> >>>>> Compilation works if I use the cross-gcc provided by >>>>> gcc-7-arm-linux-gnueabi/gcc-arm-linux-gnueabi Ubuntu packages, which is: >>>>> >>>>> $ arm-linux-gnueabi-gcc --version >>>>> arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 >>>>> >>>> I can compile gcc-plugins with Linaro toolchians. >>>> >>>> The version of mine is this: >>>> >>>> masahiro@oscar:~/ref/linux-next$ >>>> ~/tools/arm-linaro-7.5/bin/arm-linux-gnueabihf-gcc --version >>>> arm-linux-gnueabihf-gcc (Linaro GCC 7.5-2019.12) 7.5.0 >>>> Copyright (C) 2017 Free Software Foundation, Inc. >>>> This is free software; see the source for copying conditions. There is NO >>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >>>> >>>> >>>> >>>> >>>> Maybe, it depends on the host environment? >>>> >>>> >>>> Please try this: >>>> >>>> $ sudo apt install libgmp-dev >>> Indeed, it was missing on my setup. Sorry for the noise. >> >> So this change also breaks the build on our farm build machines and >> while we can request that packages are installed on these machines, it >> takes time. Is there anyway to avoid this? > > You can temporarily revert 1e860048c53e (this patch). Again that works locally, but these automated builders just pull the latest -next branch and build. Jon -- nvpublic ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 15:12 ` Jon Hunter @ 2020-12-18 15:33 ` Jon Hunter 2020-12-18 15:42 ` Masahiro Yamada 2020-12-18 17:54 ` Linus Torvalds 0 siblings, 2 replies; 18+ messages in thread From: Jon Hunter @ 2020-12-18 15:33 UTC (permalink / raw) To: Marek Szyprowski, Masahiro Yamada Cc: Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Linus Torvalds, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List, linux-tegra On 18/12/2020 15:12, Jon Hunter wrote: > > On 18/12/2020 15:09, Marek Szyprowski wrote: >> >> On 18.12.2020 16:03, Jon Hunter wrote: >>> On 18/12/2020 10:05, Marek Szyprowski wrote: >>>> On 18.12.2020 10:43, Masahiro Yamada wrote: >>>>> On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski >>>>> <m.szyprowski@samsung.com> wrote: >>>>>> On 03.12.2020 13:57, Masahiro Yamada wrote: >>>>>>> Linus pointed out a third of the time in the Kconfig parse stage comes >>>>>>> from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], >>>>>>> and directly testing plugin-version.h for existence cuts down the >>>>>>> overhead a lot. [2] >>>>>>> >>>>>>> This commit takes one step further to kill the build test entirely. >>>>>>> >>>>>>> The small piece of code was probably intended to test the C++ designated >>>>>>> initializer, which was not supported until C++20. >>>>>>> >>>>>>> In fact, with -pedantic option given, both GCC and Clang emit a warning. >>>>>>> >>>>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only >>>>>>> <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] >>>>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only >>>>>>> <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] >>>>>>> class test { public: int test; } test = { .test = 1 }; >>>>>>> ^ >>>>>>> 1 warning generated. >>>>>>> >>>>>>> Otherwise, modern C++ compilers should be able to build the code, and >>>>>>> hopefully skipping this test should not make any practical problem. >>>>>>> >>>>>>> Checking the existence of plugin-version.h is still needed to ensure >>>>>>> the plugin-dev package is installed. The test code is now small enough >>>>>>> to be embedded in scripts/gcc-plugins/Kconfig. >>>>>>> >>>>>>> [1] https://protect2.fireeye.com/v1/url?k=03db90e1-5c40a828-03da1bae-0cc47a336fae-4cc36f5830aeb78d&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ%40mail.gmail.com%2F >>>>>>> [2] https://protect2.fireeye.com/v1/url?k=965b670a-c9c05fc3-965aec45-0cc47a336fae-e34339513ff747c0&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwhK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig%3D%2Bvnw%40mail.gmail.com%2F >>>>>>> >>>>>>> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> >>>>>>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> >>>>>> This patch landed in linux next-20201217 as commit 1e860048c53e >>>>>> ("gcc-plugins: simplify GCC plugin-dev capability test"). >>>>>> >>>>>> It causes a build break with my tests setup, but I'm not sure weather it >>>>>> is really an issue of this commit or a toolchain I use. However I've >>>>>> checked various versions of the gcc cross-compilers released by Linaro >>>>>> at https://protect2.fireeye.com/v1/url?k=053727b6-5aac1f7f-0536acf9-0cc47a336fae-5bd799e7ce6b1b9b&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Freleases.linaro.org%2Fcomponents%2Ftoolchain%2Fbinaries%2F and all >>>>>> fails with the same error: >>>>>> >>>>>> $ make ARCH=arm >>>>>> CROSS_COMPILE=../../cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/arm-none-eabi- >>>>>> zImage >>>>>> HOSTCXX scripts/gcc-plugins/arm_ssp_per_task_plugin.so >>>>>> In file included from >>>>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/gcc-plugin.h:28:0, >>>>>> from scripts/gcc-plugins/gcc-common.h:7, >>>>>> from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3: >>>>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/system.h:687:10: >>>>>> fatal error: gmp.h: No such file or directory >>>>>> #include <gmp.h> >>>>>> ^~~~~~~ >>>>>> compilation terminated. >>>>>> scripts/gcc-plugins/Makefile:47: recipe for target >>>>>> 'scripts/gcc-plugins/arm_ssp_per_task_plugin.so' failed >>>>>> make[2]: *** [scripts/gcc-plugins/arm_ssp_per_task_plugin.so] Error 1 >>>>>> scripts/Makefile.build:496: recipe for target 'scripts/gcc-plugins' failed >>>>>> make[1]: *** [scripts/gcc-plugins] Error 2 >>>>>> Makefile:1190: recipe for target 'scripts' failed >>>>>> make: *** [scripts] Error 2 >>>>>> >>>>>> Compilation works if I use the cross-gcc provided by >>>>>> gcc-7-arm-linux-gnueabi/gcc-arm-linux-gnueabi Ubuntu packages, which is: >>>>>> >>>>>> $ arm-linux-gnueabi-gcc --version >>>>>> arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 >>>>>> >>>>> I can compile gcc-plugins with Linaro toolchians. >>>>> >>>>> The version of mine is this: >>>>> >>>>> masahiro@oscar:~/ref/linux-next$ >>>>> ~/tools/arm-linaro-7.5/bin/arm-linux-gnueabihf-gcc --version >>>>> arm-linux-gnueabihf-gcc (Linaro GCC 7.5-2019.12) 7.5.0 >>>>> Copyright (C) 2017 Free Software Foundation, Inc. >>>>> This is free software; see the source for copying conditions. There is NO >>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >>>>> >>>>> >>>>> >>>>> >>>>> Maybe, it depends on the host environment? >>>>> >>>>> >>>>> Please try this: >>>>> >>>>> $ sudo apt install libgmp-dev >>>> Indeed, it was missing on my setup. Sorry for the noise. >>> >>> So this change also breaks the build on our farm build machines and >>> while we can request that packages are installed on these machines, it >>> takes time. Is there anyway to avoid this? >> >> You can temporarily revert 1e860048c53e (this patch). > > > Again that works locally, but these automated builders just pull the > latest -next branch and build. However, if you are saying that this is a problem/bug with our builders, then of course we will have to get this fixed. Jon -- nvpublic ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 15:33 ` Jon Hunter @ 2020-12-18 15:42 ` Masahiro Yamada 2020-12-18 15:55 ` Jon Hunter 2020-12-18 16:53 ` Thierry Reding 2020-12-18 17:54 ` Linus Torvalds 1 sibling, 2 replies; 18+ messages in thread From: Masahiro Yamada @ 2020-12-18 15:42 UTC (permalink / raw) To: Jon Hunter Cc: Marek Szyprowski, Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Linus Torvalds, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List, linux-tegra On Sat, Dec 19, 2020 at 12:33 AM Jon Hunter <jonathanh@nvidia.com> wrote: > > > On 18/12/2020 15:12, Jon Hunter wrote: > > > > On 18/12/2020 15:09, Marek Szyprowski wrote: > >> > >> On 18.12.2020 16:03, Jon Hunter wrote: > >>> On 18/12/2020 10:05, Marek Szyprowski wrote: > >>>> On 18.12.2020 10:43, Masahiro Yamada wrote: > >>>>> On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski > >>>>> <m.szyprowski@samsung.com> wrote: > >>>>>> On 03.12.2020 13:57, Masahiro Yamada wrote: > >>>>>>> Linus pointed out a third of the time in the Kconfig parse stage comes > >>>>>>> from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], > >>>>>>> and directly testing plugin-version.h for existence cuts down the > >>>>>>> overhead a lot. [2] > >>>>>>> > >>>>>>> This commit takes one step further to kill the build test entirely. > >>>>>>> > >>>>>>> The small piece of code was probably intended to test the C++ designated > >>>>>>> initializer, which was not supported until C++20. > >>>>>>> > >>>>>>> In fact, with -pedantic option given, both GCC and Clang emit a warning. > >>>>>>> > >>>>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only > >>>>>>> <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] > >>>>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only > >>>>>>> <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] > >>>>>>> class test { public: int test; } test = { .test = 1 }; > >>>>>>> ^ > >>>>>>> 1 warning generated. > >>>>>>> > >>>>>>> Otherwise, modern C++ compilers should be able to build the code, and > >>>>>>> hopefully skipping this test should not make any practical problem. > >>>>>>> > >>>>>>> Checking the existence of plugin-version.h is still needed to ensure > >>>>>>> the plugin-dev package is installed. The test code is now small enough > >>>>>>> to be embedded in scripts/gcc-plugins/Kconfig. > >>>>>>> > >>>>>>> [1] https://protect2.fireeye.com/v1/url?k=03db90e1-5c40a828-03da1bae-0cc47a336fae-4cc36f5830aeb78d&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ%40mail.gmail.com%2F > >>>>>>> [2] https://protect2.fireeye.com/v1/url?k=965b670a-c9c05fc3-965aec45-0cc47a336fae-e34339513ff747c0&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwhK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig%3D%2Bvnw%40mail.gmail.com%2F > >>>>>>> > >>>>>>> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> > >>>>>>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > >>>>>> This patch landed in linux next-20201217 as commit 1e860048c53e > >>>>>> ("gcc-plugins: simplify GCC plugin-dev capability test"). > >>>>>> > >>>>>> It causes a build break with my tests setup, but I'm not sure weather it > >>>>>> is really an issue of this commit or a toolchain I use. However I've > >>>>>> checked various versions of the gcc cross-compilers released by Linaro > >>>>>> at https://protect2.fireeye.com/v1/url?k=053727b6-5aac1f7f-0536acf9-0cc47a336fae-5bd799e7ce6b1b9b&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Freleases.linaro.org%2Fcomponents%2Ftoolchain%2Fbinaries%2F and all > >>>>>> fails with the same error: > >>>>>> > >>>>>> $ make ARCH=arm > >>>>>> CROSS_COMPILE=../../cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/arm-none-eabi- > >>>>>> zImage > >>>>>> HOSTCXX scripts/gcc-plugins/arm_ssp_per_task_plugin.so > >>>>>> In file included from > >>>>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/gcc-plugin.h:28:0, > >>>>>> from scripts/gcc-plugins/gcc-common.h:7, > >>>>>> from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3: > >>>>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/system.h:687:10: > >>>>>> fatal error: gmp.h: No such file or directory > >>>>>> #include <gmp.h> > >>>>>> ^~~~~~~ > >>>>>> compilation terminated. > >>>>>> scripts/gcc-plugins/Makefile:47: recipe for target > >>>>>> 'scripts/gcc-plugins/arm_ssp_per_task_plugin.so' failed > >>>>>> make[2]: *** [scripts/gcc-plugins/arm_ssp_per_task_plugin.so] Error 1 > >>>>>> scripts/Makefile.build:496: recipe for target 'scripts/gcc-plugins' failed > >>>>>> make[1]: *** [scripts/gcc-plugins] Error 2 > >>>>>> Makefile:1190: recipe for target 'scripts' failed > >>>>>> make: *** [scripts] Error 2 > >>>>>> > >>>>>> Compilation works if I use the cross-gcc provided by > >>>>>> gcc-7-arm-linux-gnueabi/gcc-arm-linux-gnueabi Ubuntu packages, which is: > >>>>>> > >>>>>> $ arm-linux-gnueabi-gcc --version > >>>>>> arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 > >>>>>> > >>>>> I can compile gcc-plugins with Linaro toolchians. > >>>>> > >>>>> The version of mine is this: > >>>>> > >>>>> masahiro@oscar:~/ref/linux-next$ > >>>>> ~/tools/arm-linaro-7.5/bin/arm-linux-gnueabihf-gcc --version > >>>>> arm-linux-gnueabihf-gcc (Linaro GCC 7.5-2019.12) 7.5.0 > >>>>> Copyright (C) 2017 Free Software Foundation, Inc. > >>>>> This is free software; see the source for copying conditions. There is NO > >>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Maybe, it depends on the host environment? > >>>>> > >>>>> > >>>>> Please try this: > >>>>> > >>>>> $ sudo apt install libgmp-dev > >>>> Indeed, it was missing on my setup. Sorry for the noise. > >>> > >>> So this change also breaks the build on our farm build machines and > >>> while we can request that packages are installed on these machines, it > >>> takes time. Is there anyway to avoid this? > >> > >> You can temporarily revert 1e860048c53e (this patch). > > > > > > Again that works locally, but these automated builders just pull the > > latest -next branch and build. > > > However, if you are saying that this is a problem/bug with our builders, > then of course we will have to get this fixed. > Yes, please do so. Kconfig evaluates $(CC) capabilities, and hides CONFIG options it cannot support. In contrast, we do not do that for $(HOSTCC) capabilities because it is just a matter of some missing packages. For example, if you enable CONFIG_SYSTEM_TRUSTED_KEYRING and fail to build scripts/extrace-cert.c due to missing <openssl/bio.h>, you need to install the openssl dev package. It is the same pattern. -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 15:42 ` Masahiro Yamada @ 2020-12-18 15:55 ` Jon Hunter 2020-12-18 16:53 ` Thierry Reding 1 sibling, 0 replies; 18+ messages in thread From: Jon Hunter @ 2020-12-18 15:55 UTC (permalink / raw) To: Masahiro Yamada Cc: Marek Szyprowski, Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Linus Torvalds, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List, linux-tegra On 18/12/2020 15:42, Masahiro Yamada wrote: ... >> However, if you are saying that this is a problem/bug with our builders, >> then of course we will have to get this fixed. >> > > > Yes, please do so. > > > Kconfig evaluates $(CC) capabilities, and > hides CONFIG options it cannot support. > > > In contrast, we do not do that for $(HOSTCC) > capabilities because it is just a matter of some > missing packages. > > > For example, if you enable CONFIG_SYSTEM_TRUSTED_KEYRING > and fail to build scripts/extrace-cert.c > due to missing <openssl/bio.h>, > you need to install the openssl dev package. > > It is the same pattern. OK, thanks for confirming. We will get this fixed. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 15:42 ` Masahiro Yamada 2020-12-18 15:55 ` Jon Hunter @ 2020-12-18 16:53 ` Thierry Reding 1 sibling, 0 replies; 18+ messages in thread From: Thierry Reding @ 2020-12-18 16:53 UTC (permalink / raw) To: Masahiro Yamada Cc: Jon Hunter, Marek Szyprowski, Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Linus Torvalds, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List, linux-tegra [-- Attachment #1: Type: text/plain, Size: 9521 bytes --] On Sat, Dec 19, 2020 at 12:42:51AM +0900, Masahiro Yamada wrote: > On Sat, Dec 19, 2020 at 12:33 AM Jon Hunter <jonathanh@nvidia.com> wrote: > > > > > > On 18/12/2020 15:12, Jon Hunter wrote: > > > > > > On 18/12/2020 15:09, Marek Szyprowski wrote: > > >> > > >> On 18.12.2020 16:03, Jon Hunter wrote: > > >>> On 18/12/2020 10:05, Marek Szyprowski wrote: > > >>>> On 18.12.2020 10:43, Masahiro Yamada wrote: > > >>>>> On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski > > >>>>> <m.szyprowski@samsung.com> wrote: > > >>>>>> On 03.12.2020 13:57, Masahiro Yamada wrote: > > >>>>>>> Linus pointed out a third of the time in the Kconfig parse stage comes > > >>>>>>> from the single invocation of cc1plus in scripts/gcc-plugin.sh [1], > > >>>>>>> and directly testing plugin-version.h for existence cuts down the > > >>>>>>> overhead a lot. [2] > > >>>>>>> > > >>>>>>> This commit takes one step further to kill the build test entirely. > > >>>>>>> > > >>>>>>> The small piece of code was probably intended to test the C++ designated > > >>>>>>> initializer, which was not supported until C++20. > > >>>>>>> > > >>>>>>> In fact, with -pedantic option given, both GCC and Clang emit a warning. > > >>>>>>> > > >>>>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only > > >>>>>>> <stdin>:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic] > > >>>>>>> $ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only > > >>>>>>> <stdin>:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator] > > >>>>>>> class test { public: int test; } test = { .test = 1 }; > > >>>>>>> ^ > > >>>>>>> 1 warning generated. > > >>>>>>> > > >>>>>>> Otherwise, modern C++ compilers should be able to build the code, and > > >>>>>>> hopefully skipping this test should not make any practical problem. > > >>>>>>> > > >>>>>>> Checking the existence of plugin-version.h is still needed to ensure > > >>>>>>> the plugin-dev package is installed. The test code is now small enough > > >>>>>>> to be embedded in scripts/gcc-plugins/Kconfig. > > >>>>>>> > > >>>>>>> [1] https://protect2.fireeye.com/v1/url?k=03db90e1-5c40a828-03da1bae-0cc47a336fae-4cc36f5830aeb78d&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ%40mail.gmail.com%2F > > >>>>>>> [2] https://protect2.fireeye.com/v1/url?k=965b670a-c9c05fc3-965aec45-0cc47a336fae-e34339513ff747c0&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAHk-%3DwhK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig%3D%2Bvnw%40mail.gmail.com%2F > > >>>>>>> > > >>>>>>> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> > > >>>>>>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > > >>>>>> This patch landed in linux next-20201217 as commit 1e860048c53e > > >>>>>> ("gcc-plugins: simplify GCC plugin-dev capability test"). > > >>>>>> > > >>>>>> It causes a build break with my tests setup, but I'm not sure weather it > > >>>>>> is really an issue of this commit or a toolchain I use. However I've > > >>>>>> checked various versions of the gcc cross-compilers released by Linaro > > >>>>>> at https://protect2.fireeye.com/v1/url?k=053727b6-5aac1f7f-0536acf9-0cc47a336fae-5bd799e7ce6b1b9b&q=1&e=dfdc1cf9-82d6-4ca5-b35d-1782e918bde3&u=https%3A%2F%2Freleases.linaro.org%2Fcomponents%2Ftoolchain%2Fbinaries%2F and all > > >>>>>> fails with the same error: > > >>>>>> > > >>>>>> $ make ARCH=arm > > >>>>>> CROSS_COMPILE=../../cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/arm-none-eabi- > > >>>>>> zImage > > >>>>>> HOSTCXX scripts/gcc-plugins/arm_ssp_per_task_plugin.so > > >>>>>> In file included from > > >>>>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/gcc-plugin.h:28:0, > > >>>>>> from scripts/gcc-plugins/gcc-common.h:7, > > >>>>>> from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3: > > >>>>>> /home/mszyprow/dev/cross/gcc-arm-10.2-2020.11-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/plugin/include/system.h:687:10: > > >>>>>> fatal error: gmp.h: No such file or directory > > >>>>>> #include <gmp.h> > > >>>>>> ^~~~~~~ > > >>>>>> compilation terminated. > > >>>>>> scripts/gcc-plugins/Makefile:47: recipe for target > > >>>>>> 'scripts/gcc-plugins/arm_ssp_per_task_plugin.so' failed > > >>>>>> make[2]: *** [scripts/gcc-plugins/arm_ssp_per_task_plugin.so] Error 1 > > >>>>>> scripts/Makefile.build:496: recipe for target 'scripts/gcc-plugins' failed > > >>>>>> make[1]: *** [scripts/gcc-plugins] Error 2 > > >>>>>> Makefile:1190: recipe for target 'scripts' failed > > >>>>>> make: *** [scripts] Error 2 > > >>>>>> > > >>>>>> Compilation works if I use the cross-gcc provided by > > >>>>>> gcc-7-arm-linux-gnueabi/gcc-arm-linux-gnueabi Ubuntu packages, which is: > > >>>>>> > > >>>>>> $ arm-linux-gnueabi-gcc --version > > >>>>>> arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 > > >>>>>> > > >>>>> I can compile gcc-plugins with Linaro toolchians. > > >>>>> > > >>>>> The version of mine is this: > > >>>>> > > >>>>> masahiro@oscar:~/ref/linux-next$ > > >>>>> ~/tools/arm-linaro-7.5/bin/arm-linux-gnueabihf-gcc --version > > >>>>> arm-linux-gnueabihf-gcc (Linaro GCC 7.5-2019.12) 7.5.0 > > >>>>> Copyright (C) 2017 Free Software Foundation, Inc. > > >>>>> This is free software; see the source for copying conditions. There is NO > > >>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> Maybe, it depends on the host environment? > > >>>>> > > >>>>> > > >>>>> Please try this: > > >>>>> > > >>>>> $ sudo apt install libgmp-dev > > >>>> Indeed, it was missing on my setup. Sorry for the noise. > > >>> > > >>> So this change also breaks the build on our farm build machines and > > >>> while we can request that packages are installed on these machines, it > > >>> takes time. Is there anyway to avoid this? > > >> > > >> You can temporarily revert 1e860048c53e (this patch). > > > > > > > > > Again that works locally, but these automated builders just pull the > > > latest -next branch and build. > > > > > > However, if you are saying that this is a problem/bug with our builders, > > then of course we will have to get this fixed. > > > > > Yes, please do so. > > > Kconfig evaluates $(CC) capabilities, and > hides CONFIG options it cannot support. > > > In contrast, we do not do that for $(HOSTCC) > capabilities because it is just a matter of some > missing packages. > > > For example, if you enable CONFIG_SYSTEM_TRUSTED_KEYRING > and fail to build scripts/extrace-cert.c > due to missing <openssl/bio.h>, > you need to install the openssl dev package. > > It is the same pattern. I did notice that your patch changes the original check from using $HOSTCC to try and build a test plugin using the gcc-plugin.h header found using $CC to just determining the the existence of the gcc-plugin.h header using $CC. So it's no longer trying to actually use the gcc-plugin.h header. I think that might be what's causing the builders to suddenly break. Where previously the check would fail (presumably producing a similar error to the one we're now seeing, i.e. $CC was built with plugins support, but the installation was broken, so it can't actually build plugins because some headers are missing) the same check now succeeds (i.e. $CC was built with plugins support, but we no longer check if the plugin support is also functional). That means after your change the builders will now by default try to build the plugins and fail, whereas previously they wouldn't attempt to do so because the dependency wasn't met. This is similar to what autotools does when it checks for headers. It does one pass that just checks if a header is present and another pass where it checks that the header can actually be used. Usually when the first pass succeeds and the latter fails, it indicates that something is wrong with your toolchain setup, or you didn't pass the proper arguments in CFLAGS and friends. So that makes the new check a bit less useful than the old one, because rather than defaulting to "no" when GCC plugins can't be built, we now default to "yes" when they should be able to get built but can't. Anyway, it's probably reasonable to expect the installation to be good and that plugins can be built if the gcc-plugin.h header can be found, so I'm not objecting to this patch. However, I'm curious as to whether installing libgmp-dev (and apparently libmpc-dev as well) is the right thing to do here. In case where CC != HOSTCC, it's possible that CC was not built against the same version of GMP/MPC as HOSTCC. And even HOSTCC might not necessarily have been built against the versions provided by libgmp-dev or libmpc-dev. I'm not overly familiar with GMP/MPC, so perhaps if these headers are reasonably stable, this is not all that important. But if it is, then which version of GMP/MPC do we need? The version that CC was built against, or the version that HOSTCC was built against? Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 15:33 ` Jon Hunter 2020-12-18 15:42 ` Masahiro Yamada @ 2020-12-18 17:54 ` Linus Torvalds 2020-12-18 20:33 ` Jon Hunter 1 sibling, 1 reply; 18+ messages in thread From: Linus Torvalds @ 2020-12-18 17:54 UTC (permalink / raw) To: Jon Hunter Cc: Marek Szyprowski, Masahiro Yamada, Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List, linux-tegra On Fri, Dec 18, 2020 at 7:33 AM Jon Hunter <jonathanh@nvidia.com> wrote: > > However, if you are saying that this is a problem/bug with our builders, > then of course we will have to get this fixed. This seems to be a package dependency problem with the gcc plugins - they clearly want libgmp, but apparently the package hasn't specified that dependency. If this turns out to be a big problem, I guess we can't simplify the plugin check after all. We historically just disabled gcc-plugins if that header didn't build, which obviously meant that it "worked" for people, but it also means that clearly the coverage can't have been as good as it could/should be. So if it's as simple as just installing the GNU multiprecision libraries ("gmp-devel" on most rpm-based systems, "libgmp-dev" on most debian systems), then I think that's the right thing to do. You'll get a working build again, and equally importantly, your build servers will actually do a better job of covering the different build options. Linus ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 17:54 ` Linus Torvalds @ 2020-12-18 20:33 ` Jon Hunter 2021-01-19 17:48 ` Thierry Reding 0 siblings, 1 reply; 18+ messages in thread From: Jon Hunter @ 2020-12-18 20:33 UTC (permalink / raw) To: Linus Torvalds Cc: Marek Szyprowski, Masahiro Yamada, Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List, linux-tegra On 18/12/2020 17:54, Linus Torvalds wrote: > On Fri, Dec 18, 2020 at 7:33 AM Jon Hunter <jonathanh@nvidia.com> wrote: >> >> However, if you are saying that this is a problem/bug with our builders, >> then of course we will have to get this fixed. > > This seems to be a package dependency problem with the gcc plugins - > they clearly want libgmp, but apparently the package hasn't specified > that dependency. > > If this turns out to be a big problem, I guess we can't simplify the > plugin check after all. > > We historically just disabled gcc-plugins if that header didn't build, > which obviously meant that it "worked" for people, but it also means > that clearly the coverage can't have been as good as it could/should > be. > > So if it's as simple as just installing the GNU multiprecision > libraries ("gmp-devel" on most rpm-based systems, "libgmp-dev" on most > debian systems), then I think that's the right thing to do. You'll get > a working build again, and equally importantly, your build servers > will actually do a better job of covering the different build options. Thanks. I have reported this issue to the team that administers the builders. So hopefully, they will install the necessary packages for us now. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2020-12-18 20:33 ` Jon Hunter @ 2021-01-19 17:48 ` Thierry Reding 2021-01-19 19:01 ` Masahiro Yamada 0 siblings, 1 reply; 18+ messages in thread From: Thierry Reding @ 2021-01-19 17:48 UTC (permalink / raw) To: Jon Hunter Cc: Linus Torvalds, Marek Szyprowski, Masahiro Yamada, Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List, linux-tegra [-- Attachment #1: Type: text/plain, Size: 1566 bytes --] On Fri, Dec 18, 2020 at 08:33:37PM +0000, Jon Hunter wrote: > > On 18/12/2020 17:54, Linus Torvalds wrote: > > On Fri, Dec 18, 2020 at 7:33 AM Jon Hunter <jonathanh@nvidia.com> wrote: > >> > >> However, if you are saying that this is a problem/bug with our builders, > >> then of course we will have to get this fixed. > > > > This seems to be a package dependency problem with the gcc plugins - > > they clearly want libgmp, but apparently the package hasn't specified > > that dependency. > > > > If this turns out to be a big problem, I guess we can't simplify the > > plugin check after all. > > > > We historically just disabled gcc-plugins if that header didn't build, > > which obviously meant that it "worked" for people, but it also means > > that clearly the coverage can't have been as good as it could/should > > be. > > > > So if it's as simple as just installing the GNU multiprecision > > libraries ("gmp-devel" on most rpm-based systems, "libgmp-dev" on most > > debian systems), then I think that's the right thing to do. You'll get > > a working build again, and equally importantly, your build servers > > will actually do a better job of covering the different build options. > > > Thanks. I have reported this issue to the team that administers the > builders. So hopefully, they will install the necessary packages for us > now. Just to close the loop on this, the builders now have libgmp-dev and libmpc-dev packages installed and the builds are passing without the workaround we had used. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test 2021-01-19 17:48 ` Thierry Reding @ 2021-01-19 19:01 ` Masahiro Yamada 0 siblings, 0 replies; 18+ messages in thread From: Masahiro Yamada @ 2021-01-19 19:01 UTC (permalink / raw) To: Thierry Reding Cc: Jon Hunter, Linus Torvalds, Marek Szyprowski, Linux Kbuild mailing list, Kees Cook, Emese Revfy, linux-hardening, Nathan Chancellor, Nick Desaulniers, clang-built-linux, Linux Kernel Mailing List, linux-tegra On Wed, Jan 20, 2021 at 2:48 AM Thierry Reding <thierry.reding@gmail.com> wrote: > > On Fri, Dec 18, 2020 at 08:33:37PM +0000, Jon Hunter wrote: > > > > On 18/12/2020 17:54, Linus Torvalds wrote: > > > On Fri, Dec 18, 2020 at 7:33 AM Jon Hunter <jonathanh@nvidia.com> wrote: > > >> > > >> However, if you are saying that this is a problem/bug with our builders, > > >> then of course we will have to get this fixed. > > > > > > This seems to be a package dependency problem with the gcc plugins - > > > they clearly want libgmp, but apparently the package hasn't specified > > > that dependency. > > > > > > If this turns out to be a big problem, I guess we can't simplify the > > > plugin check after all. > > > > > > We historically just disabled gcc-plugins if that header didn't build, > > > which obviously meant that it "worked" for people, but it also means > > > that clearly the coverage can't have been as good as it could/should > > > be. > > > > > > So if it's as simple as just installing the GNU multiprecision > > > libraries ("gmp-devel" on most rpm-based systems, "libgmp-dev" on most > > > debian systems), then I think that's the right thing to do. You'll get > > > a working build again, and equally importantly, your build servers > > > will actually do a better job of covering the different build options. > > > > > > Thanks. I have reported this issue to the team that administers the > > builders. So hopefully, they will install the necessary packages for us > > now. > > Just to close the loop on this, the builders now have libgmp-dev and > libmpc-dev packages installed and the builds are passing without the > workaround we had used. > > Thierry I was slightly concerned about your question: "In case where CC != HOSTCC, it's possible that CC was not built against the same version of GMP/MPC as HOSTCC. And even HOSTCC might not necessarily have been built against the versions provided by libgmp-dev or libmpc-dev. I'm not overly familiar with GMP/MPC, so perhaps if these headers are reasonably stable, this is not all that important. But if it is, then which version of GMP/MPC do we need? The version that CC was built against, or the version that HOSTCC was built against?" I do not have a good insight about this. I am not sure if it is perfectly OK to use gmp.h from HOSTCC when it was not bundled with CC. The version difference might not be a significant issue, though... -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-01-19 21:27 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-03 12:57 [PATCH] gcc-plugins: simplify GCC plugin-dev capability test Masahiro Yamada 2020-12-03 17:37 ` Linus Torvalds 2020-12-04 22:02 ` Kees Cook 2020-12-04 23:46 ` Kees Cook [not found] ` <CGME20201218075758eucas1p1605768803a5c9edce4fbe54b3e3b859a@eucas1p1.samsung.com> 2020-12-18 7:57 ` Marek Szyprowski 2020-12-18 9:43 ` Masahiro Yamada 2020-12-18 10:05 ` Marek Szyprowski 2020-12-18 15:03 ` Jon Hunter 2020-12-18 15:09 ` Marek Szyprowski 2020-12-18 15:12 ` Jon Hunter 2020-12-18 15:33 ` Jon Hunter 2020-12-18 15:42 ` Masahiro Yamada 2020-12-18 15:55 ` Jon Hunter 2020-12-18 16:53 ` Thierry Reding 2020-12-18 17:54 ` Linus Torvalds 2020-12-18 20:33 ` Jon Hunter 2021-01-19 17:48 ` Thierry Reding 2021-01-19 19:01 ` Masahiro Yamada
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.