On Thu, Jun 4, 2020, at 23:10, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jun 04, 2020 at 10:39:30PM +0200, Daniel Kolesa wrote:
> > On Thu, Jun 4, 2020, at 19:33, Segher Boessenkool wrote:
> > > It is the ABI. If you think it should be different, make your own ABI,
> > > don't pretend the existing ABI is different than what it is. Thank you.
> >
> > Well then - in that case, what do you suggest that I do?
> >
> > Void currently ships an ELFv2 (or apparently not, I guess) 64-bit big
> > endian port that works on 970/G5 up. It is important to me that it stays
> > that way (a large amount of users are running 970s, so introducing a VSX
> > dependency means I might as well abandon the port entirely).
>
> You can just clearly document what ABI changes you use, and try to make
> sure that everyone who uses your distro / your tools / your ABI variant
> knows about it. Telling your users that it is ELFv2, without telling
> them it is not compliant, namely X Y Z are different, is a bit of a
> disservice to your users, and worse to everyone else involved.
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.
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.
>
> 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.
That's why I'm worried when you speak of introducing a new ABI. As it is, we
can benefit from having the compiler being generally the same (-mabi=elfv2
producing correct results even for 970) and retaining interoperability when
people compile their own code for modern targets that cover the ELFv2 ABI as a
whole. As I said, it's perfectly possible for somebody to run BE Void on their
POWER9 machine, then compile their software for POWER9, and still have it work
with the system packages built for 970 baseline. Pretty sure glibc will still
provide optimized stuff (e.g. memcpy and so on) for the modern targets based on
runtime detection, too.
So the "differences" in our case come down to "This is ELFv2, except you can't
strictly assume that all features are present. In general that means no quad
precision floating point for you if you want things to run on 970, since you
don't have VSX regs"
>
> > It currently works out of box - there are no changes required in glibc, and
> > nearly the entire userland builds and works (about ~11500 out of ~12000
> > software packages, those that don't work either don't work on ppc64le
> > either, or have issues related to endianness, or some other unrelated
> > reason).
>
> Very nice!
>
> > I'd like to eventually get this into a state where I don't have to worry
> > about glibc arbitrarily breaking it - which means it would be necessary to
> > stabilize it upstream. While I can probably maintain a downstream patchset
> > when it comes to it, I'd much prefer if I didn't have to - but this sounds
> > like an official ELFv2 glibc BE port would be impossible unless the VSX
> > requirement (and thus IEEE 128-bit long double and so on) was in place,
> > which would defeat the point of the port.
> >
> > Is there *any* way I can take that would make upstreams of all parts of the
> > toolchain happy? I explicitly don't want to go back to ELFv1.
>
> Oh absolutely, it sounds like things are in quite good shape already!
> It will safe a lot of grief on all sides if you make clear this is not
> "plain" ELFv2, and in what ways it differs.
See above.
>
> 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.
>
> > While at it, I'd like to transition to ld64 long double format, to match
> > musl and improve software compatibility, which I feel will raise more
> > objections from IBM side.
>
> I have no idea what "ld64 long double" is? Is that just IEEE DP float?
> Aka "long double is the same as double". That is likely easier for new
> ports than "double-double", yes, even if the eventual goal should be
> IEEE QP float -- a much smoother transition.
Yes, I mean double == long double (like musl, and glibc before 2.4). I don't
think there is any other viable way, since the IBM double-double format is
legacy/often broken and real QP is constrained by hardware in this case. We're
as much of a source distro as a binary distro, so a potential ppc64 build
doesn't have to have any vector requirements at all, even if the default binary
packages do.
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 } ...)
>
> Same goes here: document it! If your users know that the ELFv2 variant
> you give them is not *the* ELFv2, but it differs in some clear ways,
> everyone will be happier :-)
See above.
>
>
> Segher
>
Daniel
