After a recent change in clang to stop consuming all instances of '-S'
and '-c' [1], the stack protector scripts break due to the kernel's use
of -Werror=unused-command-line-argument to catch cases where flags are
not being properly consumed by the compiler driver:

  $ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument
  clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]

This results in CONFIG_STACKPROTECTOR getting disabled because
CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set.

'-c' and '-S' both instruct the compiler to stop at different stages of
the pipeline ('-S' after compiling, '-c' after assembling), so having
them present together in the same command makes little sense. In this
case, the test wants to stop before assembling because it is looking at
the textual assembly output of the compiler for either '%fs' or '%gs',
so remove '-c' from the list of arguments to resolve the error.

All versions of GCC continue to work after this change, along with
versions of clang that do or do not contain the change mentioned above.

Cc: stable@vger.kernel.org
Fixes: 4f7fd4d7a791 ("[PATCH] Add the -fstack-protector option to the CFLAGS")
Fixes: 60a5317ff0f4 ("x86: implement x86_32 stack protector")
Link: https://github.com/llvm/llvm-project/commit/6461e537815f7fa68cef06842505353cf5600e9c [1]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
I think this could go via either -tip or Kbuild?

Perhaps this is an issue in the clang commit mentioned in the message
above since it deviates from GCC (Fangrui is on CC here) but I think the
combination of these options is a little dubious to begin with, hence
this change.
---
 scripts/gcc-x86_32-has-stack-protector.sh | 2 +-
 scripts/gcc-x86_64-has-stack-protector.sh | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/gcc-x86_32-has-stack-protector.sh b/scripts/gcc-x86_32-has-stack-protector.sh
index 825c75c5b715..9459ca4f0f11 100755
--- a/scripts/gcc-x86_32-has-stack-protector.sh
+++ b/scripts/gcc-x86_32-has-stack-protector.sh
@@ -5,4 +5,4 @@
 # -mstack-protector-guard-reg, added by
 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
 
-echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m32 -O0 -fstack-protector -mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard - -o - 2> /dev/null | grep -q "%fs"
+echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -m32 -O0 -fstack-protector -mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard - -o - 2> /dev/null | grep -q "%fs"
diff --git a/scripts/gcc-x86_64-has-stack-protector.sh b/scripts/gcc-x86_64-has-stack-protector.sh
index 75e4e22b986a..f680bb01aeeb 100755
--- a/scripts/gcc-x86_64-has-stack-protector.sh
+++ b/scripts/gcc-x86_64-has-stack-protector.sh
@@ -1,4 +1,4 @@
 #!/bin/sh
 # SPDX-License-Identifier: GPL-2.0
 
-echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m64 -O0 -mcmodel=kernel -fno-PIE -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
+echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -m64 -O0 -mcmodel=kernel -fno-PIE -fstack-protector - -o - 2> /dev/null | grep -q "%gs"

---
base-commit: 1722389b0d863056d78287a120a1d6cadb8d4f7b
change-id: 20240726-fix-x86-stack-protector-tests-b542b1b9416b

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>

On Sat, Jul 27, 2024 at 3:05 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> After a recent change in clang to stop consuming all instances of '-S'
> and '-c' [1], the stack protector scripts break due to the kernel's use
> of -Werror=unused-command-line-argument to catch cases where flags are
> not being properly consumed by the compiler driver:
>
>   $ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument
>   clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]
>
> This results in CONFIG_STACKPROTECTOR getting disabled because
> CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set.
>
> '-c' and '-S' both instruct the compiler to stop at different stages of
> the pipeline ('-S' after compiling, '-c' after assembling), so having
> them present together in the same command makes little sense. In this
> case, the test wants to stop before assembling because it is looking at
> the textual assembly output of the compiler for either '%fs' or '%gs',
> so remove '-c' from the list of arguments to resolve the error.
>
> All versions of GCC continue to work after this change, along with
> versions of clang that do or do not contain the change mentioned above.
>
> Cc: stable@vger.kernel.org
> Fixes: 4f7fd4d7a791 ("[PATCH] Add the -fstack-protector option to the CFLAGS")
> Fixes: 60a5317ff0f4 ("x86: implement x86_32 stack protector")
> Link: https://github.com/llvm/llvm-project/commit/6461e537815f7fa68cef06842505353cf5600e9c [1]
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> I think this could go via either -tip or Kbuild?


Applied to linux-kbuild/fixes, and included in the pull request.
Thanks!



-- 
Best Regards
Masahiro Yamada

On Sat, Jul 27, 2024 at 3:05 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> After a recent change in clang to stop consuming all instances of '-S'
> and '-c' [1], the stack protector scripts break due to the kernel's use
> of -Werror=unused-command-line-argument to catch cases where flags are
> not being properly consumed by the compiler driver:
>
>   $ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument
>   clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]
>
> This results in CONFIG_STACKPROTECTOR getting disabled because
> CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set.
>
> '-c' and '-S' both instruct the compiler to stop at different stages of
> the pipeline ('-S' after compiling, '-c' after assembling), so having
> them present together in the same command makes little sense. In this
> case, the test wants to stop before assembling because it is looking at
> the textual assembly output of the compiler for either '%fs' or '%gs',
> so remove '-c' from the list of arguments to resolve the error.
>
> All versions of GCC continue to work after this change, along with
> versions of clang that do or do not contain the change mentioned above.
>
> Cc: stable@vger.kernel.org
> Fixes: 4f7fd4d7a791 ("[PATCH] Add the -fstack-protector option to the CFLAGS")
> Fixes: 60a5317ff0f4 ("x86: implement x86_32 stack protector")
> Link: https://github.com/llvm/llvm-project/commit/6461e537815f7fa68cef06842505353cf5600e9c [1]
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> I think this could go via either -tip or Kbuild?
>
> Perhaps this is an issue in the clang commit mentioned in the message
> above since it deviates from GCC (Fangrui is on CC here) but I think the
> combination of these options is a little dubious to begin with, hence
> this change.


I agree.

I can offer to pick up this to kbuild/fixes.


If this goes somewhere else,
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>


> ---
>  scripts/gcc-x86_32-has-stack-protector.sh | 2 +-
>  scripts/gcc-x86_64-has-stack-protector.sh | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/gcc-x86_32-has-stack-protector.sh b/scripts/gcc-x86_32-has-stack-protector.sh
> index 825c75c5b715..9459ca4f0f11 100755
> --- a/scripts/gcc-x86_32-has-stack-protector.sh
> +++ b/scripts/gcc-x86_32-has-stack-protector.sh
> @@ -5,4 +5,4 @@
>  # -mstack-protector-guard-reg, added by
>  # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
>
> -echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m32 -O0 -fstack-protector -mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard - -o - 2> /dev/null | grep -q "%fs"
> +echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -m32 -O0 -fstack-protector -mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard - -o - 2> /dev/null | grep -q "%fs"
> diff --git a/scripts/gcc-x86_64-has-stack-protector.sh b/scripts/gcc-x86_64-has-stack-protector.sh
> index 75e4e22b986a..f680bb01aeeb 100755
> --- a/scripts/gcc-x86_64-has-stack-protector.sh
> +++ b/scripts/gcc-x86_64-has-stack-protector.sh
> @@ -1,4 +1,4 @@
>  #!/bin/sh
>  # SPDX-License-Identifier: GPL-2.0
>
> -echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m64 -O0 -mcmodel=kernel -fno-PIE -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
> +echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -m64 -O0 -mcmodel=kernel -fno-PIE -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
>
> ---
> base-commit: 1722389b0d863056d78287a120a1d6cadb8d4f7b
> change-id: 20240726-fix-x86-stack-protector-tests-b542b1b9416b
>
> Best regards,
> --
> Nathan Chancellor <nathan@kernel.org>
>
>


-- 
Best Regards
Masahiro Yamada

On Fri, Jul 26, 2024 at 2:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> After a recent change in clang to stop consuming all instances of '-S'
> and '-c' [1], the stack protector scripts break due to the kernel's use
> of -Werror=unused-command-line-argument to catch cases where flags are
> not being properly consumed by the compiler driver:
>
>   $ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument
>   clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]
>
> This results in CONFIG_STACKPROTECTOR getting disabled because
> CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set.
>
> '-c' and '-S' both instruct the compiler to stop at different stages of
> the pipeline ('-S' after compiling, '-c' after assembling), so having
> them present together in the same command makes little sense. In this
> case, the test wants to stop before assembling because it is looking at
> the textual assembly output of the compiler for either '%fs' or '%gs',
> so remove '-c' from the list of arguments to resolve the error.
>
> All versions of GCC continue to work after this change, along with
> versions of clang that do or do not contain the change mentioned above.
>
> Cc: stable@vger.kernel.org
> Fixes: 4f7fd4d7a791 ("[PATCH] Add the -fstack-protector option to the CFLAGS")
> Fixes: 60a5317ff0f4 ("x86: implement x86_32 stack protector")
> Link: https://github.com/llvm/llvm-project/commit/6461e537815f7fa68cef06842505353cf5600e9c [1]
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> I think this could go via either -tip or Kbuild?
>
> Perhaps this is an issue in the clang commit mentioned in the message
> above since it deviates from GCC (Fangrui is on CC here) but I think the
> combination of these options is a little dubious to begin with, hence
> this change.

As part of my stack protector cleanup series, I found that these
scripts can simply be removed.  I can repost those patches as a
standalone cleanup.

https://lore.kernel.org/lkml/20240322165233.71698-1-brgerst@gmail.com/

Brian Gerst

On Sun, Jul 28, 2024 at 5:43 AM Brian Gerst <brgerst@gmail.com> wrote:
>
> On Fri, Jul 26, 2024 at 2:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > After a recent change in clang to stop consuming all instances of '-S'
> > and '-c' [1], the stack protector scripts break due to the kernel's use
> > of -Werror=unused-command-line-argument to catch cases where flags are
> > not being properly consumed by the compiler driver:
> >
> >   $ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument
> >   clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]
> >
> > This results in CONFIG_STACKPROTECTOR getting disabled because
> > CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set.
> >
> > '-c' and '-S' both instruct the compiler to stop at different stages of
> > the pipeline ('-S' after compiling, '-c' after assembling), so having
> > them present together in the same command makes little sense. In this
> > case, the test wants to stop before assembling because it is looking at
> > the textual assembly output of the compiler for either '%fs' or '%gs',
> > so remove '-c' from the list of arguments to resolve the error.
> >
> > All versions of GCC continue to work after this change, along with
> > versions of clang that do or do not contain the change mentioned above.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: 4f7fd4d7a791 ("[PATCH] Add the -fstack-protector option to the CFLAGS")
> > Fixes: 60a5317ff0f4 ("x86: implement x86_32 stack protector")
> > Link: https://github.com/llvm/llvm-project/commit/6461e537815f7fa68cef06842505353cf5600e9c [1]
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> > I think this could go via either -tip or Kbuild?
> >
> > Perhaps this is an issue in the clang commit mentioned in the message
> > above since it deviates from GCC (Fangrui is on CC here) but I think the
> > combination of these options is a little dubious to begin with, hence
> > this change.
>
> As part of my stack protector cleanup series, I found that these
> scripts can simply be removed.  I can repost those patches as a
> standalone cleanup.
>
> https://lore.kernel.org/lkml/20240322165233.71698-1-brgerst@gmail.com/
>
> Brian Gerst

Judging from the Fixes tags, Nathan meant this patch is
a back-port candidate so that the latest LLVM can be used for stable kernels.

You are making big changes, and do you mean they can be back-ported?



-- 
Best Regards
Masahiro Yamada

On Sat, Jul 27, 2024 at 10:36 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Sun, Jul 28, 2024 at 5:43 AM Brian Gerst <brgerst@gmail.com> wrote:
> >
> > On Fri, Jul 26, 2024 at 2:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > After a recent change in clang to stop consuming all instances of '-S'
> > > and '-c' [1], the stack protector scripts break due to the kernel's use
> > > of -Werror=unused-command-line-argument to catch cases where flags are
> > > not being properly consumed by the compiler driver:
> > >
> > >   $ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument
> > >   clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]
> > >
> > > This results in CONFIG_STACKPROTECTOR getting disabled because
> > > CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set.
> > >
> > > '-c' and '-S' both instruct the compiler to stop at different stages of
> > > the pipeline ('-S' after compiling, '-c' after assembling), so having
> > > them present together in the same command makes little sense. In this
> > > case, the test wants to stop before assembling because it is looking at
> > > the textual assembly output of the compiler for either '%fs' or '%gs',
> > > so remove '-c' from the list of arguments to resolve the error.
> > >
> > > All versions of GCC continue to work after this change, along with
> > > versions of clang that do or do not contain the change mentioned above.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: 4f7fd4d7a791 ("[PATCH] Add the -fstack-protector option to the CFLAGS")
> > > Fixes: 60a5317ff0f4 ("x86: implement x86_32 stack protector")
> > > Link: https://github.com/llvm/llvm-project/commit/6461e537815f7fa68cef06842505353cf5600e9c [1]
> > > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > > ---
> > > I think this could go via either -tip or Kbuild?
> > >
> > > Perhaps this is an issue in the clang commit mentioned in the message
> > > above since it deviates from GCC (Fangrui is on CC here) but I think the
> > > combination of these options is a little dubious to begin with, hence
> > > this change.
> >
> > As part of my stack protector cleanup series, I found that these
> > scripts can simply be removed.  I can repost those patches as a
> > standalone cleanup.
> >
> > https://lore.kernel.org/lkml/20240322165233.71698-1-brgerst@gmail.com/
> >
> > Brian Gerst
>
> Judging from the Fixes tags, Nathan meant this patch is
> a back-port candidate so that the latest LLVM can be used for stable kernels.
>
> You are making big changes, and do you mean they can be back-ported?

I was referring to just the first two patches of that series.  That
said, it would be simpler to take Nathan's fix for backporting.

Brian Gerst

On Sun, Jul 28, 2024 at 12:13 PM Brian Gerst <brgerst@gmail.com> wrote:
>
> On Sat, Jul 27, 2024 at 10:36 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Sun, Jul 28, 2024 at 5:43 AM Brian Gerst <brgerst@gmail.com> wrote:
> > >
> > > On Fri, Jul 26, 2024 at 2:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > > >
> > > > After a recent change in clang to stop consuming all instances of '-S'
> > > > and '-c' [1], the stack protector scripts break due to the kernel's use
> > > > of -Werror=unused-command-line-argument to catch cases where flags are
> > > > not being properly consumed by the compiler driver:
> > > >
> > > >   $ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument
> > > >   clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]
> > > >
> > > > This results in CONFIG_STACKPROTECTOR getting disabled because
> > > > CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set.
> > > >
> > > > '-c' and '-S' both instruct the compiler to stop at different stages of
> > > > the pipeline ('-S' after compiling, '-c' after assembling), so having
> > > > them present together in the same command makes little sense. In this
> > > > case, the test wants to stop before assembling because it is looking at
> > > > the textual assembly output of the compiler for either '%fs' or '%gs',
> > > > so remove '-c' from the list of arguments to resolve the error.
> > > >
> > > > All versions of GCC continue to work after this change, along with
> > > > versions of clang that do or do not contain the change mentioned above.
> > > >
> > > > Cc: stable@vger.kernel.org
> > > > Fixes: 4f7fd4d7a791 ("[PATCH] Add the -fstack-protector option to the CFLAGS")
> > > > Fixes: 60a5317ff0f4 ("x86: implement x86_32 stack protector")
> > > > Link: https://github.com/llvm/llvm-project/commit/6461e537815f7fa68cef06842505353cf5600e9c [1]
> > > > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > > > ---
> > > > I think this could go via either -tip or Kbuild?
> > > >
> > > > Perhaps this is an issue in the clang commit mentioned in the message
> > > > above since it deviates from GCC (Fangrui is on CC here) but I think the
> > > > combination of these options is a little dubious to begin with, hence
> > > > this change.
> > >
> > > As part of my stack protector cleanup series, I found that these
> > > scripts can simply be removed.  I can repost those patches as a
> > > standalone cleanup.
> > >
> > > https://lore.kernel.org/lkml/20240322165233.71698-1-brgerst@gmail.com/
> > >
> > > Brian Gerst
> >
> > Judging from the Fixes tags, Nathan meant this patch is
> > a back-port candidate so that the latest LLVM can be used for stable kernels.
> >
> > You are making big changes, and do you mean they can be back-ported?
>
> I was referring to just the first two patches of that series.  That
> said, it would be simpler to take Nathan's fix for backporting.



Even the first two patches are not trivial.

The second patch 02/16:
https://lore.kernel.org/lkml/20240322165233.71698-3-brgerst@gmail.com/

is completely removing scripts/gcc-x86_64-has-stack-protector.sh,


In fact, I also noticed it was a workaround for old buggy compilers.
I attempted to do the equivalent clean up, then it was rejected.
https://lore.kernel.org/lkml/1541992013-18657-1-git-send-email-yamada.masahiro@socionext.com/

It was 6 years ago, so the situation might have changed.
Good luck.








--
Best Regards
Masahiro Yamada

On Sun, Jul 28, 2024 at 2:24 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Sun, Jul 28, 2024 at 12:13 PM Brian Gerst <brgerst@gmail.com> wrote:
> >
> > On Sat, Jul 27, 2024 at 10:36 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > On Sun, Jul 28, 2024 at 5:43 AM Brian Gerst <brgerst@gmail.com> wrote:
> > > >
> > > > On Fri, Jul 26, 2024 at 2:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > > > >
> > > > > After a recent change in clang to stop consuming all instances of '-S'
> > > > > and '-c' [1], the stack protector scripts break due to the kernel's use
> > > > > of -Werror=unused-command-line-argument to catch cases where flags are
> > > > > not being properly consumed by the compiler driver:
> > > > >
> > > > >   $ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument
> > > > >   clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]
> > > > >
> > > > > This results in CONFIG_STACKPROTECTOR getting disabled because
> > > > > CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set.
> > > > >
> > > > > '-c' and '-S' both instruct the compiler to stop at different stages of
> > > > > the pipeline ('-S' after compiling, '-c' after assembling), so having
> > > > > them present together in the same command makes little sense. In this
> > > > > case, the test wants to stop before assembling because it is looking at
> > > > > the textual assembly output of the compiler for either '%fs' or '%gs',
> > > > > so remove '-c' from the list of arguments to resolve the error.
> > > > >
> > > > > All versions of GCC continue to work after this change, along with
> > > > > versions of clang that do or do not contain the change mentioned above.
> > > > >
> > > > > Cc: stable@vger.kernel.org
> > > > > Fixes: 4f7fd4d7a791 ("[PATCH] Add the -fstack-protector option to the CFLAGS")
> > > > > Fixes: 60a5317ff0f4 ("x86: implement x86_32 stack protector")
> > > > > Link: https://github.com/llvm/llvm-project/commit/6461e537815f7fa68cef06842505353cf5600e9c [1]
> > > > > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > > > > ---
> > > > > I think this could go via either -tip or Kbuild?
> > > > >
> > > > > Perhaps this is an issue in the clang commit mentioned in the message
> > > > > above since it deviates from GCC (Fangrui is on CC here) but I think the
> > > > > combination of these options is a little dubious to begin with, hence
> > > > > this change.
> > > >
> > > > As part of my stack protector cleanup series, I found that these
> > > > scripts can simply be removed.  I can repost those patches as a
> > > > standalone cleanup.
> > > >
> > > > https://lore.kernel.org/lkml/20240322165233.71698-1-brgerst@gmail.com/
> > > >
> > > > Brian Gerst
> > >
> > > Judging from the Fixes tags, Nathan meant this patch is
> > > a back-port candidate so that the latest LLVM can be used for stable kernels.
> > >
> > > You are making big changes, and do you mean they can be back-ported?
> >
> > I was referring to just the first two patches of that series.  That
> > said, it would be simpler to take Nathan's fix for backporting.
>
>
>
> Even the first two patches are not trivial.
>
> The second patch 02/16:
> https://lore.kernel.org/lkml/20240322165233.71698-3-brgerst@gmail.com/
>
> is completely removing scripts/gcc-x86_64-has-stack-protector.sh,
>
>
> In fact, I also noticed it was a workaround for old buggy compilers.
> I attempted to do the equivalent clean up, then it was rejected.
> https://lore.kernel.org/lkml/1541992013-18657-1-git-send-email-yamada.masahiro@socionext.com/
>
> It was 6 years ago, so the situation might have changed.
> Good luck.

It's a workaround for an old buggy compiler that isn't even supported
by the kernel anymore.

Brian Gerst
>
>
>
>
>
>
>
> --
> Best Regards
> Masahiro Yamada