From: Nathan Chancellor <nathan@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Tom Rix <trix@redhat.com>, Daniel Kolesa <daniel@octaforge.org>,
linux-kernel@vger.kernel.org, patches@lists.linux.dev,
llvm@lists.linux.dev, stable@vger.kernel.org
Subject: Re: [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
Date: Thu, 7 Jul 2022 10:17:04 -0700 [thread overview]
Message-ID: <YscVEIBtyoX2jrBV@dev-arch.thelio-3990X> (raw)
In-Reply-To: <842b718f-8207-1565-3373-61098a4c2d33@intel.com>
On Wed, Jul 06, 2022 at 03:25:51PM -0700, Dave Hansen wrote:
> 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.
Right, also see the following commits for other areas where this was
addressed.
58d746c119df ("efi/libstub: Add $(CLANG_FLAGS) to x86 flags")
d5cbd80e302d ("x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS")
8abe7fc26ad8 ("x86/build: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS)")
> 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.
We have started testing UML with clang and it does work but I suspect
there is little value to cross compiling a UML kernel, as it has to run
in an x86 userland anyways, rather than through QEMU or other
virtualization solutions. That is not something I plan to do anyways.
If someone does and a fix similar to this one is needed, it can be done
at that time.
Thank you for picking up this change!
Cheers,
Nathan
prev parent reply other threads:[~2022-07-07 17:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 18:08 [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang Nathan Chancellor
2022-07-01 22:17 ` Nathan Chancellor
2022-07-06 22:25 ` Dave Hansen
2022-07-07 17:17 ` Nathan Chancellor [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YscVEIBtyoX2jrBV@dev-arch.thelio-3990X \
--to=nathan@kernel.org \
--cc=bp@alien8.de \
--cc=daniel@octaforge.org \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mingo@redhat.com \
--cc=ndesaulniers@google.com \
--cc=patches@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=trix@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).