All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Arnd Bergmann <arnd@kernel.org>,
	Fangrui Song <maskray@google.com>,
	Nathan Chancellor <nathan@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com
Subject: Re: [PATCH] arm64: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1
Date: Fri, 2 Jul 2021 10:50:27 -0700	[thread overview]
Message-ID: <CAKwvOdk4GLDVrOJsxPBVM+g4sBiYW-64M3rNN6hsBgHP0eYqGg@mail.gmail.com> (raw)
In-Reply-To: <20210702112210.GA11084@willie-the-truck>

On Fri, Jul 2, 2021 at 4:22 AM Will Deacon <will@kernel.org> wrote:
>
> On Thu, Jul 01, 2021 at 04:55:05PM -0700, Nick Desaulniers wrote:
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index 7bc37d0a1b68..016873fddcc3 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -34,6 +34,17 @@ $(warning LSE atomics not supported by binutils)
> >    endif
> >  endif
> >
> > +ifneq ($(LLVM),)
> > +ifneq ($(LLVM_IAS),)
> > +ifeq ($(CROSS_COMPILE),)
> > +CLANG_TARGET :=--target=aarch64-linux
> > +CLANG_FLAGS  += $(CLANG_TARGET)
> > +KBUILD_CFLAGS        += $(CLANG_TARGET)
> > +KBUILD_AFLAGS        += $(CLANG_TARGET)
>
> Do we need to do anything extra for the linker here? I can't see how we
> avoid picking up the host copy.

That's handled by the top level Makefile when LLVM=1 is set.

There is $KBUILD_LDFLAGS, but we don't do anything with it at the
moment in terms of which linker we select; $LD controls which linker
we use.

LLD can figure out the target based on the object files it's given as
input, so it doesn't need any `--target=` flag. When clang is invoked
as the compiler or assembler, it does need --target.

> Have you tested the compat vDSO with this change? I think we'll just end
> up passing two --target options, which is hopefully ok, but thought I'd
> better check.

Good catch.  We don't reuse KBUILD_CFLAGS or KBUILD_AFLAGS for the
compat vdso for this very reason. In arch/arm64/kernel/vdso32/Makefile
you'll see no references to KBUILD_CFLAGS or KBUILD_AFLAGS; instead we
use VDSO_CFLAGS and VDSO_AFLAGS in their stead.

But, we could (and should) make this same change for the compat vdso,
and drop the need for CROSS_COMPILE_COMPAT for LLVM.

Let me play around with the changes Arnd suggested and see if I can
get that working.  I'm a bit nervous about making this depend on
something from the top level Makefile on initial glance; these changes
start to become tree wide rather than isolated per arch/, but let's
see.  Maybe at that point we carry a series in the kbuild tree with
acks for the arch/ specific changes from the respective maintainers?

Either way, I'll send a v2 that nixes CROSS_COMPILE_COMPAT for LLVM.
-- 
Thanks,
~Nick Desaulniers

WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	 Arnd Bergmann <arnd@kernel.org>,
	Fangrui Song <maskray@google.com>,
	 Nathan Chancellor <nathan@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	 linux-kernel@vger.kernel.org,
	clang-built-linux@googlegroups.com
Subject: Re: [PATCH] arm64: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1
Date: Fri, 2 Jul 2021 10:50:27 -0700	[thread overview]
Message-ID: <CAKwvOdk4GLDVrOJsxPBVM+g4sBiYW-64M3rNN6hsBgHP0eYqGg@mail.gmail.com> (raw)
In-Reply-To: <20210702112210.GA11084@willie-the-truck>

On Fri, Jul 2, 2021 at 4:22 AM Will Deacon <will@kernel.org> wrote:
>
> On Thu, Jul 01, 2021 at 04:55:05PM -0700, Nick Desaulniers wrote:
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index 7bc37d0a1b68..016873fddcc3 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -34,6 +34,17 @@ $(warning LSE atomics not supported by binutils)
> >    endif
> >  endif
> >
> > +ifneq ($(LLVM),)
> > +ifneq ($(LLVM_IAS),)
> > +ifeq ($(CROSS_COMPILE),)
> > +CLANG_TARGET :=--target=aarch64-linux
> > +CLANG_FLAGS  += $(CLANG_TARGET)
> > +KBUILD_CFLAGS        += $(CLANG_TARGET)
> > +KBUILD_AFLAGS        += $(CLANG_TARGET)
>
> Do we need to do anything extra for the linker here? I can't see how we
> avoid picking up the host copy.

That's handled by the top level Makefile when LLVM=1 is set.

There is $KBUILD_LDFLAGS, but we don't do anything with it at the
moment in terms of which linker we select; $LD controls which linker
we use.

LLD can figure out the target based on the object files it's given as
input, so it doesn't need any `--target=` flag. When clang is invoked
as the compiler or assembler, it does need --target.

> Have you tested the compat vDSO with this change? I think we'll just end
> up passing two --target options, which is hopefully ok, but thought I'd
> better check.

Good catch.  We don't reuse KBUILD_CFLAGS or KBUILD_AFLAGS for the
compat vdso for this very reason. In arch/arm64/kernel/vdso32/Makefile
you'll see no references to KBUILD_CFLAGS or KBUILD_AFLAGS; instead we
use VDSO_CFLAGS and VDSO_AFLAGS in their stead.

But, we could (and should) make this same change for the compat vdso,
and drop the need for CROSS_COMPILE_COMPAT for LLVM.

Let me play around with the changes Arnd suggested and see if I can
get that working.  I'm a bit nervous about making this depend on
something from the top level Makefile on initial glance; these changes
start to become tree wide rather than isolated per arch/, but let's
see.  Maybe at that point we carry a series in the kbuild tree with
acks for the arch/ specific changes from the respective maintainers?

Either way, I'll send a v2 that nixes CROSS_COMPILE_COMPAT for LLVM.
-- 
Thanks,
~Nick Desaulniers

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-02 17:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01 23:55 [PATCH] arm64: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1 Nick Desaulniers
2021-07-01 23:55 ` Nick Desaulniers
2021-07-02  1:05 ` Tom Stellard
2021-07-02  1:05   ` Tom Stellard
2021-07-02 17:37   ` Nick Desaulniers
2021-07-02 17:37     ` Nick Desaulniers
2021-07-02 11:22 ` Will Deacon
2021-07-02 11:22   ` Will Deacon
2021-07-02 17:50   ` Nick Desaulniers [this message]
2021-07-02 17:50     ` Nick Desaulniers
2021-07-02 11:59 ` Arnd Bergmann
2021-07-02 11:59   ` Arnd Bergmann
2021-07-02 18:29   ` Nick Desaulniers
2021-07-02 18:29     ` Nick Desaulniers
2021-07-04  0:47     ` Nathan Chancellor
2021-07-04  0:47       ` Nathan Chancellor
2021-07-07 19:04       ` Nick Desaulniers
2021-07-07 19:04         ` Nick Desaulniers
2021-07-07 19:08         ` Nathan Chancellor
2021-07-07 19:08           ` Nathan Chancellor
2021-07-07 22:44           ` Nick Desaulniers
2021-07-07 22:44             ` Nick Desaulniers

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=CAKwvOdk4GLDVrOJsxPBVM+g4sBiYW-64M3rNN6hsBgHP0eYqGg@mail.gmail.com \
    --to=ndesaulniers@google.com \
    --cc=arnd@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=maskray@google.com \
    --cc=nathan@kernel.org \
    --cc=will@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 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.