[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <842b718f-8207-1565-3373-61098a4c2d33@intel.com>
Date: Wed, 6 Jul 2022 15:25:51 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Nathan Chancellor <nathan@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org
Cc: "H. Peter Anvin" <hpa@...or.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Tom Rix <trix@...hat.com>,
Daniel Kolesa <daniel@...aforge.org>,
linux-kernel@...r.kernel.org, patches@...ts.linux.dev,
llvm@...ts.linux.dev, stable@...r.kernel.org
Subject: Re: [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when
cross compiling with clang
On 6/17/22 11:08, Nathan Chancellor wrote:
> When clang is invoked without a '--target' flag, code is generated for
> the default target, which is usually the host (it is configurable via
> cmake). As a result, the has-stack-protector scripts will generate code
> for the default target but check for x86 specific segment registers,
> which cannot succeed if the default target is not x86.
I guess the real root cause here is the direct use of '$(CC)' without
any other flags. Adding '$(CLANG_FLAGS)' seems like a pretty normal
fix, like in scripts/Kconfig.include.
I suspect there's another one of these here:
arch/x86/um/vdso/Makefile: cmd_vdso = $(CC) -nostdlib -o $@
but I wouldn't be surprised if UML doesn't work with clang in the first
place.
Powered by blists - more mailing lists