From: Segher Boessenkool <segher@kernel.crashing.org>
To: Daniel Kolesa <daniel@octaforge.org>
Cc: libc-alpha@sourceware.org, eery@paperfox.es,
musl@lists.openwall.com,
Will Springer <skirmisher@protonmail.com>,
Palmer Dabbelt via binutils <binutils@sourceware.org>,
libc-dev@lists.llvm.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [musl] Re: ppc64le and 32-bit LE userland compatibility
Date: Mon, 1 Jun 2020 20:36:43 -0500 [thread overview]
Message-ID: <20200602013643.GL31009@gate.crashing.org> (raw)
In-Reply-To: <4205b197-b964-451e-bc41-59b35d1dd233@www.fastmail.com>
On Mon, Jun 01, 2020 at 12:29:56AM +0200, Daniel Kolesa wrote:
> On Sun, May 31, 2020, at 22:42, Segher Boessenkool wrote:
> > > There was just an assumption that LE == powerpc64le in libgo, spotted by
> > > q66 (daniel@ on the CC). I just pushed the patch to [1].
> >
> > Please send GCC patches to gcc-patches@ ?
>
> FWIW, that patch alone is not very useful, we'd need to otherwise patch libgo to recognize a new GOARCH (as right now it's likely to just use 'ppc' which is wrong).
Gotcha.
> That said, we'll get back to you with any patches we have. One I can already think of - we will need to update the dynamic linker name so that it uses ld-musl-powerpcle.so instead of powerpc (musl needs to be updated the same way by adding the subarch variable for the 'le' prefix).
Thanks! That would be good progress.
> > > > Almost no project that used 32-bit PowerPC in LE mode has sent patches
> > > > to the upstreams.
> > >
> > > Right, but I have heard concerns from at least one person familiar with
> > > the ppc kernel about breaking existing users of this arch-endianness
> > > combo, if any. It seems likely that none of those use upstream, though ^^;
> >
> > So we don't care, because we *cannot* care.
>
> Well, that's the reason this thread was opened in the first place - to call out to any potential users, and synchronize with upstreams on a single way forward that all upstreams can agree on, since this effort requires changes in various parts of the stack. We don't want to hog changes locally or otherwise do any changes that would be in conflict with upstream projects, as that would mean needlessly diverging, which only means trouble later on.
Much appreciated!
I don't actually foresee any huge problems -- just lots of hard work ;-)
Segher
next prev parent reply other threads:[~2020-06-02 1:37 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 19:03 ppc64le and 32-bit LE userland compatibility Will Springer via Libc-alpha
2020-05-29 19:24 ` [musl] " Rich Felker
2020-05-30 22:56 ` Will Springer via Libc-alpha
2020-05-30 15:37 ` Christophe Leroy
2020-05-30 22:17 ` Will Springer via Libc-alpha
2020-06-05 23:54 ` Will Springer via Libc-alpha
2020-06-12 5:13 ` Christophe Leroy
2020-05-30 19:22 ` Segher Boessenkool
2020-05-31 0:57 ` Will Springer via Libc-alpha
2020-05-31 20:42 ` Segher Boessenkool
2020-05-31 22:29 ` [musl] " Daniel Kolesa
2020-06-02 1:36 ` Segher Boessenkool [this message]
2020-06-01 21:28 ` Joseph Myers
2020-06-01 21:36 ` [musl] " 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 ` [musl] " Rich Felker
2020-06-04 17:33 ` Segher Boessenkool
2020-06-04 17:46 ` Rich Felker
2020-06-04 19:00 ` David Edelsohn via Libc-alpha
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-04 21:55 ` Phil Blundell via Libc-alpha
2020-06-04 22:06 ` Daniel Kolesa
2020-06-04 23:06 ` Segher Boessenkool
2020-06-04 23:43 ` Phil Blundell via Libc-alpha
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 ` [musl] " Jeffrey Walton via Libc-alpha
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
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200602013643.GL31009@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=binutils@sourceware.org \
--cc=daniel@octaforge.org \
--cc=eery@paperfox.es \
--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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).