Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200602013643.GL31009@gate.crashing.org>
Date: Mon, 1 Jun 2020 20:36:43 -0500
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Daniel Kolesa <daniel@...aforge.org>
Cc: musl@...ts.openwall.com, Will Springer <skirmisher@...tonmail.com>,
        linuxppc-dev@...ts.ozlabs.org, libc-alpha@...rceware.org,
        eery@...erfox.es,
        Palmer Dabbelt via binutils <binutils@...rceware.org>,
        libc-dev@...ts.llvm.org
Subject: Re: Re: ppc64le and 32-bit LE userland compatibility

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.