mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Daniel Kolesa <daniel@octaforge.org>
Cc: musl@lists.openwall.com, "Rich Felker" <dalias@libc.org>,
	"Michal Suchánek" <msuchanek@suse.de>,
	"Joseph Myers" <joseph@codesourcery.com>,
	libc-alpha@sourceware.org, eery@paperfox.es,
	"Will Springer" <skirmisher@protonmail.com>,
	"Palmer Dabbelt via binutils" <binutils@sourceware.org>,
	"via libc-dev" <libc-dev@lists.llvm.org>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [musl] Re: ppc64le and 32-bit LE userland compatibility
Date: Thu, 4 Jun 2020 18:35:16 -0500	[thread overview]
Message-ID: <20200604233516.GM31009@gate.crashing.org> (raw)
In-Reply-To: <60fa8bd7-2439-4403-a0eb-166a2fb49a4b@www.fastmail.com>

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

  parent reply	other threads:[~2020-06-04 23:35 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29 19:03 [musl] " Will Springer
2020-05-29 19:24 ` Rich Felker
2020-05-30 22:56   ` Will Springer
2020-05-30 15:37 ` [musl] " Christophe Leroy
2020-05-30 22:17   ` Will Springer
2020-06-05 23:54     ` Will Springer
2020-06-12  5:13       ` Christophe Leroy
2020-05-30 19:22 ` Segher Boessenkool
2020-05-31  0:57   ` Will Springer
2020-05-31 20:42     ` Segher Boessenkool
2020-05-31 22:29       ` Daniel Kolesa
2020-06-02  1:36         ` Segher Boessenkool
2020-06-01 21:28 ` Joseph Myers
2020-06-01 21:36   ` Rich Felker
2020-06-01 23:26   ` Daniel Kolesa
2020-06-01 23:45     ` Joseph Myers
2020-06-01 23:55       ` Joseph Myers
2020-06-02  0:13         ` Daniel Kolesa
2020-06-02  0:11       ` Daniel Kolesa
2020-06-02 13:40         ` Joseph Myers
2020-06-02 14:23           ` Michal Suchánek
2020-06-02 15:13             ` Daniel Kolesa
2020-06-02 15:27               ` Michal Suchánek
2020-06-02 15:40                 ` Daniel Kolesa
2020-06-02 15:56                   ` Michal Suchánek
2020-06-04 17:20                 ` Segher Boessenkool
2020-06-04 17:12               ` Segher Boessenkool
2020-06-04 17:18                 ` Rich Felker
2020-06-04 17:33                   ` Segher Boessenkool
2020-06-04 17:46                     ` Rich Felker
2020-06-04 19:00                       ` David Edelsohn
2020-06-04 19:37                         ` Rich Felker
2020-06-04 20:39                     ` Daniel Kolesa
2020-06-04 21:10                       ` Segher Boessenkool
2020-06-04 21:43                         ` Daniel Kolesa
2020-06-04 22:08                           ` Joseph Myers
2020-06-04 22:26                             ` Daniel Kolesa
2020-06-05  0:02                               ` Segher Boessenkool
2020-06-04 23:42                             ` Segher Boessenkool
2020-06-04 23:35                           ` Segher Boessenkool [this message]
2020-06-05  2:18                             ` Daniel Kolesa
2020-06-05 17:27                               ` Segher Boessenkool
2020-06-05 17:50                                 ` Rich Felker
2020-06-05 23:45                                   ` Segher Boessenkool
2020-06-05 21:59                                 ` Daniel Kolesa
2020-06-06  0:12                                   ` Segher Boessenkool
2020-06-06  2:13                                     ` Daniel Kolesa
2020-06-02 14:52           ` Daniel Kolesa
2020-06-02  2:12       ` Segher Boessenkool
2020-06-02  2:17         ` Daniel Kolesa
2020-06-02 13:50         ` Joseph Myers
2020-06-02 17:47           ` Segher Boessenkool
2020-06-02  1:58     ` Segher Boessenkool
2020-06-02  2:09       ` Jeffrey Walton
2020-06-02  2:12       ` Daniel Kolesa
2020-06-02  2:36         ` Segher Boessenkool
2020-06-02  2:55           ` Daniel Kolesa
2020-06-02  1:42   ` Segher Boessenkool
2020-06-02  2:03     ` Daniel Kolesa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200604233516.GM31009@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=binutils@sourceware.org \
    --cc=dalias@libc.org \
    --cc=daniel@octaforge.org \
    --cc=eery@paperfox.es \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=libc-dev@lists.llvm.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=msuchanek@suse.de \
    --cc=musl@lists.openwall.com \
    --cc=skirmisher@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).