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: Sat, 24 Jun 2017 20:10:24 -0400	[thread overview]
Message-ID: <20170625001024.GA1627@brightrain.aerifal.cx> (raw)
In-Reply-To: <594EFC63.3000707@adelielinux.org>

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.

Also, note that it's not like glibc-linked elfv1 ppc64 binaries would
be safe to use with musl even if we did have such a port; at the very
least the representation of long double would have to mismatch (just
like it does on 32-bit powerpc).

> Again, do you have a _technical_ reason that I cannot spend next
> weekend making a PPC64 BE image using musl + ELFv2 ABI?  Or is this
> political / community in nature?

I think it's mostly just a misunderstanding. It may have started out
from political decisions, but I don't think people are _trying_ to be
political about it at this point.

Rich


  reply	other threads:[~2017-06-25  0:10 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 [this message]
2017-06-25  1:41                 ` Rich Felker
2017-06-29 13:49                 ` David Edelsohn
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=20170625001024.GA1627@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).