[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190820124033.GQ31406@gate.crashing.org>
Date: Tue, 20 Aug 2019 07:40:33 -0500
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Nathan Chancellor <natechancellor@...il.com>
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Michael Ellerman <mpe@...erman.id.au>,
clang-built-linux@...glegroups.com, linuxppc-dev@...ts.ozlabs.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] powerpc: Don't add -mabi= flags when building with Clang
On Mon, Aug 19, 2019 at 08:15:38PM -0700, Nathan Chancellor wrote:
> On Mon, Aug 19, 2019 at 04:19:31AM -0500, Segher Boessenkool wrote:
> > On Sun, Aug 18, 2019 at 12:13:21PM -0700, Nathan Chancellor wrote:
> > > When building pseries_defconfig, building vdso32 errors out:
> > >
> > > error: unknown target ABI 'elfv1'
> > >
> > > Commit 4dc831aa8813 ("powerpc: Fix compiling a BE kernel with a
> > > powerpc64le toolchain") added these flags to fix building GCC but
> > > clang is multitargeted and does not need these flags. The ABI is
> > > properly set based on the target triple, which is derived from
> > > CROSS_COMPILE.
> >
> > You mean that LLVM does not *allow* you to select a different ABI, or
> > different ABI options, you always have to use the default. (Everything
> > else you say is true for GCC as well).
>
> I need to improve the wording of the commit message as it is really that
> clang does not allow a different ABI to be selected for 32-bit PowerPC,
> as the setABI function is not overridden and it defaults to false.
> GCC appears to just silently ignores this flag (I think it is the
> SUBSUBTARGET_OVERRIDE_OPTIONS macro in gcc/config/rs6000/linux64.h).
What flag? -mabi=elfv[12]?
(Only irrelevant things are ever ignored; otherwise, please do a bug
report).
> It can be changed for 64-bit PowerPC it seems but it doesn't need to be
> with clang because everything is set properly internally (I'll find a
> better way to clearly word that as I am sure I'm not quite getting that
> subtlety right).
You can have elfv2 on BE, and e.g. the sysv ABI on LE. Neither of those
is tested a lot.
> > (-mabi= does not set a "target ABI", fwiw, it is more subtle; please see
> > the documentation. Unless LLVM is incompatible in that respect as well?)
>
> Are you referring to the error message?
Yup.
> I suppose I could file an LLVM
> bug report on that but that message applies to all of the '-mabi='
> options, which may refer to a target ABI.
That depends on what you call "an ABI", I guess. You can call any ABI
variant a separate ABI: you'll have to rebuild all of userland. You can
also says ELFv1 and ELFv2 are pretty much the same thing, which is true
as well. The way -mabi= is defined is the latter:
'-mabi=ABI-TYPE'
Extend the current ABI with a particular extension, or remove such
extension. Valid values are 'altivec', 'no-altivec',
'ibmlongdouble', 'ieeelongdouble', 'elfv1', 'elfv2'.
Segher
Powered by blists - more mailing lists