[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200604233516.GM31009@gate.crashing.org>
Date: Thu, 4 Jun 2020 18:35:16 -0500
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Daniel Kolesa <daniel@...aforge.org>
Cc: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
Michal Suchánek <msuchanek@...e.de>,
Joseph Myers <joseph@...esourcery.com>, libc-alpha@...rceware.org,
eery@...erfox.es, Will Springer <skirmisher@...tonmail.com>,
Palmer Dabbelt via binutils <binutils@...rceware.org>,
via libc-dev <libc-dev@...ts.llvm.org>, linuxppc-dev@...ts.ozlabs.org
Subject: Re: Re: ppc64le and 32-bit LE userland compatibility
Hi!
On Thu, Jun 04, 2020 at 11:43:53PM +0200, Daniel Kolesa wrote:
> The thing is, I've yet to see in which way the ELFv2 ABI *actually* requires VSX - I don't think compiling for 970 introduces any actual differences. There will be omissions, yes - but then the more accurate thing would be to say that a subset of ELFv2 is used, rather than it being a different ABI per se.
Two big things are that binaries that someone else made are supposed to
work for you as well -- including binaries using VSX registers, or any
instructions that require ISA 2.07 (or some older ISA after 970). This
includes DSOs (shared libraries). So for a distribution this means that
they will not use VSX *anywhere*, or only in very specialised things.
That is a many-years setback, for people/situations where it could be
used.
> The ELFv2 document specifies things like passing of quadruple precision floats. Indeed, VSX is needed there, but that's not a concern if you *don't* use quadruple precision floats.
As Joseph says, QP float is passed in the VRs, so that works just fine
*if* you have AltiVec. If not, you probably should pass such values in
the GPRs, or however a struct of 16 bytes is passed in whatever ABI you
use (this is a much more general problem than just BE ELFv2 ;-) ) And
then you have some kind of "partial soft float". Fun! (Or not...)
> > If you always use -mcpu=970 (or similar), then not very much is
> > different for you most likely -- except of course there is no promise
> > to the user that they can use VSX and all instructions in ISA 2.07,
> > which is a very useful promise to have normally.
>
> Yes, -mcpu=970 is used for default packages. *However*, it is possible that the user compiles their own packages with -mcpu=power9 or something similar, and then it'll be possible to utilize VSX and all, and it should still work with the existing userland. When speaking of ABI, what matters is... well, the binary interface, which is the same - so I believe this is still ELFv2. A subset is always compliant with the whole.
The same calling convention will probably work, yes. An ABI is more
than that though.
> > Btw, if you use GCC, *please* send in testresults? :-)
>
> Yes, it's all gcc (we do have clang, but compiling repo packages with clang is generally frowned upon in the project, as we have vast majority of packages cross-compilable, and our cross-compiling infrastructure is gcc-centric, plus we enable certain things by default such as hardening flags that clang does not support). I'll try to remember next time I'm running tests.
Thanks in advance!
> I have a feeling that glibc would object to such port, since it means it would have to exist in parallel with a potential different ELFv2 port that does have a POWER8 minimal requirement; gcc would need a way to tell them apart, too (based on what would they be told apart? the simplest way would probably be something like, if --with-abi=elfv2 { if --with-cpu < power8 -> use glibc-novsx else use glibc-vsx } ...)
The target name allows to make such distinctions: this could for example
be powerpc64-*-linux-void (maybe I put the distinction in the wrong
part of the name here? The glibc people will know better, and "void" is
probably not a great name anyway).
Segher
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
