Date: Sat, 06 Jun 2020 04:13:18 +0200 From: "Daniel Kolesa" <daniel@...aforge.org> To: "Segher Boessenkool" <segher@...nel.crashing.org>, musl@...ts.openwall.com Cc: "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 On Sat, Jun 6, 2020, at 02:12, Segher Boessenkool wrote: > On Fri, Jun 05, 2020 at 11:59:32PM +0200, Daniel Kolesa wrote: > > On Fri, Jun 5, 2020, at 19:27, Segher Boessenkool wrote: > > > > Third party precompiled stuff doesn't really need to concern us, since none really exists. > > > > > > ... Yet. And if you claim you support ELFv2, not mentioning the ways > > > your implementation deviates from it, users will be unhappy. > > > > Will they? > > Yes; not only *your* users, but also users of the "actual" ELFv2 (for > BE), if anything starts using that: the ABI is defined, and at least at > some point it worked, it is not unreasonable to think someone might > want to start using it). I guess you mean like, if third party software starts shipping builds using ELFv2 and people suddenly find these things don't work because $reasons. The ABI itself wouldn't cause issues here as at binary interface level we're still compatible, but problems may actually arise in case glibc has a modern HW targeting ELFv2 port with IEEE quad float at some point. (not to mention that would be 100% incompatible at binary level because symvers, so i want to resolve this until then either way) > > Just don't pretend X and Y are the same if they are not, people do not > like to be misled. Just be clear upfront what the differences are, and > everyone will be happy. Confusing people and wasting their time won't > make you very popular though ;-) > > > The system explicitly mentions that the minimum target in the binary packages is 970. Users can't be expecting features that the hardware we support doesn't support :) > > But you are not the only user of ELFv2. Sure, the point was more like "ELFv2 + 970 minimum", both of which are explicitly mentioned, cannot really mean anything else than what it already does. > > > Also, we're not the only ones that do this - there's musl of course, but there's also the BSDs. FreeBSD 13 uses ELFv2, and supports all the old hardware including processors without VMX, let alone VSX. OpenBSD is likely to take the same path. But I'm not opposed to making this explicit, if that's what it takes to make other people happy with it. > > Yeah, please do :-) > > > > > It's also still an upgrade over ELFv1 regardless (I mean, the same things apply there). > > > > > > Yeah, in mostly minor ways, but it all adds up for sure. > > > > It's made my life simpler on numerous occasions, > > Great to hear that! > > > and allowed us to bring in software that'd otherwise take significant patching (no software is complete until it has its own assembly implementation of coroutines or something like that :P), > > .. but does it have a mail client? Probably some ad-hoc, informally specified, bug-ridden implementations of half of Common Lisp as well... > > > > That depends on what you call the average case. Code that is control > > > and memory-bound will not benefit much from *anything* :-) > > > > Average case is, quite literally, an average case - i.e. the average of all the software packages shipped in a distro :) > > Ah, mostly boring stuff :-) > > > > Yeah, but it helps quite a bit if your system (shared) libraries get all > > > improvements they can as well. > > > > Well, glibc will still benefit automatically to a degree even if not built for a modern baseline, since it has runtime checks in place already; as for other things... well, at least for Void, I already mentioned before we're as much of a source distro as a binary one - people can easily rebuild things that bottleneck them, with modern CFLAGS, and still have things be interoperable. > > Yeah, good point there. > > > > I'm not trying to dissuade you from not requiring VSX and 2.07 -- this > > > sounds like your best option, given the constraints. I'm just saying > > > the cost is not trivial (even ignoring the ABI divergence). > > > > Of course the cost is there - it's just not something I can do anything about. I generally recommend that people who can run LE should run LE. We're a bi-endian distribution, so there is a complete, fully functional, ISA-2.07-baseline ppc64le variant (in fact, it's our best-supported port, with greatest repo coverage and testing), as well as the 970-targeting ppc64 variant. > > Ah, so your BE target is mostly for legacy hardware? That took a while > to sink in, sorry! :-) That's what the average user on BE is expected to be. I'm not opinionated enough to force BE on an average modern hardware user, there's just too many drawbacks nowadays, some of them inherent, like limited graphics hardware support (the choice of HW is limited, modern GPUs don't work at all, older GPUs are limited to OpenGL 3.2 even if they support newer API, and even if newer GPUs *were* working, they'd be crippled performance-wise as modern GPUs are always LE these days - as a gamedev person I need my graphics stuff working, and I expect my RX 5700 XT to be more than a paperweight), nevertheless, if someone is opinionated enough to use BE despite everything when they don't have to, they're welcome and so are their patches. > > > I know about the biarch case as well, and there is also multilib, as an even more elaborate form of that. That's not directly related to what I originally said, though > > Biarch is why -m32 and -m64 can work at all (for building user binaries). > My point is that this does *not* work for most finer ABI (or OS) -related > points -- you really do need a toolchain built specifically for that > config. Indeed. But target triples don't give you the necessary distinctions. This is why I find that the "we're an everything-compiler" approach of Clang that's supposedly meant to simplify things to the user actually complicates them; with gcc, you can configure your toolchain for the target env when building it, with clang you are not given this option, all you can do is patch its source code, as the ideas of targeting everything and of configuring the compiler details for a target are inherently in conflict. And when cross-building the real complexity for the user lies in setting up the sysroot anyway, at least for complex things with actual dependencies. > > > Segher > Daniel
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.