[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKwvOd=+-PEQXOZBG6rprWdOzHfcQq9ojkGo+Q28vfC4AU=Hwg@mail.gmail.com>
Date: Tue, 1 Oct 2019 09:59:43 -0700
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Will Deacon <will@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v3 1/5] arm64: vdso32: Introduce COMPAT_CC_IS_GCC
On Tue, Oct 1, 2019 at 9:47 AM Will Deacon <will@...nel.org> wrote:
>
> On Tue, Oct 01, 2019 at 04:30:56PM +0100, Catalin Marinas wrote:
> > In the long run, I wouldn't mandate CROSS_COMPILE_COMPAT to always be
> > set for the compat vDSO since with clang we could use the same compiler
> > binary for both native and compat (with different flags). That's once we
> > cleaned up the headers.
>
> But we'll still need it even with clang so that the relevant triple can be
> passed to the --target option. The top-level Makefile already does this:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Makefile#n544
That's not pulling the cross compiler out of a *config* (as this patch
is proposing); rather from an env var.
>
> so I think we should do the same thing for the compat vdso as well, which
> would allow us to remove this complexity by requiring that
> CROSS_COMPILE_COMPAT identifies the cross-compiler to use in exactly the
> same way as CROSS_COMPILE does.
>
> Am I missing something here?
I think the second paragraph you wrote shows we're all in agreement,
but I suspect you may be conflating *how* the toplevel Makefile knows
we're doing a cross compile. It doesn't read a config, this patch
would make it so a cross compiler is specified via config, Catalin
asked "please no," I agree with Catalin (and I suspect you do too).
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists