mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] powerpc64le: Add single instruction math functions
Date: Thu, 29 Jun 2017 12:05:44 -0400	[thread overview]
Message-ID: <20170629160544.GE1627@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAGWvnykHSZkE3xpqQWu29-1-u7nXrcJ=vPpPaL=DmLypN_dCDg@mail.gmail.com>

On Thu, Jun 29, 2017 at 09:49:34AM -0400, David Edelsohn wrote:
> On Sat, Jun 24, 2017 at 8:10 PM, Rich Felker <dalias@libc.org> wrote:
> > On Sat, Jun 24, 2017 at 06:57:23PM -0500, A. Wilcox wrote:
> >> Except Adélie, Sabotage, and anyone who is creating their own
> >> environment without using a distribution.  Or are you saying that GCC
> >> assumes LE with ELFv2?
> >>
> >> That is the primary reason I haven't shipped any PPC64 image yet.  In
> >> addition to the usual badness of porting an entire distro worth of
> >> packages to a platform nobody has really used yet (had a similar time
> >> with musl on MIPS64 and 32-bit PowerPC), I'm a bit uneasy on the
> >> toolchain itself being able to understand what Rich has said.  Since
> >> ELFv2 says that Power8 is the minimum ISA, gcc can do whatever it
> >> wants, and I'm not sure if -mcpu=power6 (specific lower ISA) or
> >> - -mcpu=powerpc64 (generic) will affect its code output when it sees
> >> - -mabi=elfv2.  So I'm going to need to put any PPC64 image through a
> >> much more rigorous test than I did any other platform.
> >
> > I don't see any reason GCC would introduce a problem here. It should
> > always honor -march, and the default -march for the
> > powerpc64-linux-musl (elfv2 of course) toolchain I just built seems to
> > be POWER4 according to the predefined macros.
> >
> >> > I added the macro tests for portability and completeness.
> >> >
> >> > The only ports of Musl that will function on existing, supported,
> >> > big-endian PowerPC systems are the 32 bit "powerpc" port and an
> >> > unimplemented PPC64 BE ELFv1 port.
> >>
> >>
> >> Except Rich specifically said that he did not want an ELFv1 port for
> >> 64-bit PowerPC when I asked him, so I don't think that's going to happen
> >
> > To clarify, my view is that it does not make sense to add a new port
> > that differs only in ABI, unless it's an ABI variant that's actually
> > necessary for reasonable support of some actual hardware (like
> > softfloat, fdpic for nommu, etc.). That is not the case here.
> 
> A colleague of mine reminded me that ELFv2 ABI specifies POWER8 as the
> minimum hardware (not little-endian).

This is a gratuitous requirement and has nothing to do with the
meaning of ELFv2 we're using (and likewise not with the gcc
--with-abi=elfv2).

> The implementation of ELFv2 can
> operate on earlier hardware, but binaries may not be forward
> compatible because of VSX.  Because of the calling convention of VSX
> registers in ELFv2, the stack may be corrupted if an application built
> without VSX support is linked with a library that does support VSX.
> One cannot mix and match musl libc built for POWER4 or PPC970 and musl
> libc built for POWER7.

I don't think this is accurate. If it is then it's a serious bug we
need to fix, and it should have been discussed at the time the port
was added...

Can you provide a citation for the usage of VSX registers in the
calling convention, and how you think that affects the stack?

Rich


  reply	other threads:[~2017-06-29 16:05 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-21 14:53 David Edelsohn
2017-06-23 19:35 ` Rich Felker
2017-06-23 19:53   ` David Edelsohn
2017-06-24  0:46     ` A. Wilcox
2017-06-24  0:55       ` Rich Felker
2017-06-24  3:05       ` David Edelsohn
2017-06-24  3:32         ` Rich Felker
2017-06-24  3:38         ` A. Wilcox
2017-06-24 20:53           ` David Edelsohn
2017-06-24 22:44             ` Rich Felker
2017-06-24 23:57             ` A. Wilcox
2017-06-25  0:10               ` Rich Felker
2017-06-25  1:41                 ` Rich Felker
2017-06-29 13:49                 ` David Edelsohn
2017-06-29 16:05                   ` Rich Felker [this message]
2017-06-29 17:00                     ` David Edelsohn
2017-06-29 17:59                       ` Rich Felker
2017-06-30  1:07                         ` David Edelsohn
2017-06-30  2:11                           ` Rich Felker
2017-06-25  3:24               ` David Edelsohn
2017-06-25 14:28                 ` Rich Felker
2017-06-25 14:56                   ` David Edelsohn
2018-09-27 22:53                   ` A. Wilcox

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=20170629160544.GE1627@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.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).