From: Rich Felker <dalias@libc.org>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Will Springer <skirmisher@protonmail.com>,
linuxppc-dev@lists.ozlabs.org, libc-alpha@sourceware.org,
eery@paperfox.es, daniel@octaforge.org, musl@lists.openwall.com,
binutils@sourceware.org, libc-dev@lists.llvm.org
Subject: Re: [musl] Re: ppc64le and 32-bit LE userland compatibility
Date: Mon, 1 Jun 2020 17:36:40 -0400 [thread overview]
Message-ID: <20200601213639.GX1079@brightrain.aerifal.cx> (raw)
In-Reply-To: <alpine.DEB.2.21.2006012119010.11121@digraph.polyomino.org.uk>
On Mon, Jun 01, 2020 at 09:28:25PM +0000, Joseph Myers wrote:
> On Fri, 29 May 2020, Will Springer via Binutils wrote:
>
> > Hey all, a couple of us over in #talos-workstation on freenode have been
> > working on an effort to bring up a Linux PowerPC userland that runs in 32-bit
> > little-endian mode, aka ppcle. As far as we can tell, no ABI has ever been
> > designated for this (unless you count the patchset from a decade ago [1]), so
> > it's pretty much uncharted territory as far as Linux is concerned. We want to
> > sync up with libc and the relevant kernel folks to establish the best path
> > forward.
>
> As a general comment on the glibc side of things, if this is considered
> like a new port, and it probably is, the same principles that apply to new
> ports apply here.
>
> There's a general discussion at
> <https://sourceware.org/glibc/wiki/NewPorts>, although much of that is
> only applicable when adding new CPU architecture support. More specific
> points include that new 32-bit ports should default to 64-bit time and
> file offsets from the start, with no support for 32-bit time or offsets
> (meaning that if you want to use this with some kind of library call
> translation, the library call translation will need to deal with
> corresponding type size conversions). And a new port should not be added
> that uses the IBM long double format. You can use IEEE binary128 long
> double, possibly with an ABI similar to that used on powerpc64le, or can
> use long double = double, but should not support IBM long double, and
> preferably should only have one long double format rather than using the
> glibc support for building with different options resulting in functions
> for different long double formats being called.
Thanks, these are great points, and the same applies for musl I think.
We always have 64-bit off_t anyway, but new ports should have 64-bit
time_t to begin with rather than defining _REDIR_TIME64.
It's a little bit complicated by the fact that powerpcle would be a
"subarch" for powerpc, and we don't yet have any like that where the
subarchs' time64 statuses differ, but it doesn't look like that should
be hard to do. The arch-specific alltypes.h.in already has access to
endianness knowledge. src/ldso/powerpc/dlsym_time64.S would also need
added preprocessor conditionals.
Exemption from this would be open to discussion if there are existing
non-upstream users of powerpcle musl that otherwise complies with ABI
policy except for time64, but I'm not aware of any that aren't
experimental.
Rich
next prev parent reply other threads:[~2020-06-01 21:36 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 [this message]
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
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=20200601213639.GX1079@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=binutils@sourceware.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=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).