mailing list of musl libc
 help / color / mirror / code / Atom feed
From: David Edelsohn <dje.gcc@gmail.com>
To: musl@lists.openwall.com
Subject: Re: [PATCH] powerpc64le: Add single instruction math functions
Date: Thu, 29 Jun 2017 09:49:34 -0400	[thread overview]
Message-ID: <CAGWvnykHSZkE3xpqQWu29-1-u7nXrcJ=vPpPaL=DmLypN_dCDg@mail.gmail.com> (raw)
In-Reply-To: <20170625001024.GA1627@brightrain.aerifal.cx>

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).  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.

Thanks, David


  parent reply	other threads:[~2017-06-29 13:49 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 [this message]
2017-06-29 16:05                   ` Rich Felker
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='CAGWvnykHSZkE3xpqQWu29-1-u7nXrcJ=vPpPaL=DmLypN_dCDg@mail.gmail.com' \
    --to=dje.gcc@gmail.com \
    --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).