From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) by sourceware.org (Postfix) with ESMTPS id 157F13851C04 for ; Sat, 30 May 2020 22:56:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 157F13851C04 Date: Sat, 30 May 2020 22:56:47 +0000 To: Rich Felker , linuxppc-dev@lists.ozlabs.org From: Will Springer Cc: binutils@sourceware.org, libc-dev@lists.llvm.org, libc-alpha@sourceware.org, musl@lists.openwall.com, daniel@octaforge.org, eery@paperfox.es Reply-To: Will Springer Subject: Re: [musl] ppc64le and 32-bit LE userland compatibility Message-ID: <14083731.JCcGWNJJiE@sheen> In-Reply-To: <20200529192426.GM1079@brightrain.aerifal.cx> References: <2047231.C4sosBPzcN@sheen> <20200529192426.GM1079@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2020 22:56:57 -0000 On Friday, May 29, 2020 12:24:27 PM PDT Rich Felker wrote: > The argument passing for pread/pwrite is historically a mess and > differs between archs. musl has a dedicated macro that archs can > define to override it. But it looks like it should match regardless of > BE vs LE, and musl already defines it for powerpc with the default > definition, adding a zero arg to start on an even arg-slot index, > which is an odd register (since ppc32 args start with an odd one, r3). >=20 > > [6]: > > https://gist.github.com/Skirmisher/02891c1a8cafa0ff18b2460933ef4f3c > I don't think this is correct, but I'm confused about where it's > getting messed up because it looks like it should already be right. Hmm, interesting. Will have to go back to it I guess... > > This was enough to fix up the `file` bug. I'm no seasoned kernel > > hacker, though, and there is still concern over the right way to > > approach this, whether it should live in the kernel or libc, etc. > > Frankly, I don't know the ABI structure enough to understand why the > > register padding has to be different in this case, or what > > lower-level component is responsible for it.. For comparison, I had a > > look at the mips tree, since it's bi-endian and has a similar 32/64 > > situation. There is a macro conditional upon endianness that is > > responsible for munging long longs; it uses __MIPSEB__ and __MIPSEL__ > > instead of an if/else on the generic __LITTLE_ENDIAN__. Not sure what > > to make of that. (It also simply swaps registers for LE, unlike what > > I did for ppc.) > Indeed the problem is probably that you need to swap registers for LE, > not remove the padding slot. Did you check what happens if you pass a > value larger than 32 bits? >=20 > If so, the right way to fix this on the kernel side would be to > construct the value as a union rather than by bitwise ops so it's > endian-agnostic: >=20 > =09(union { u32 parts[2]; u64 val; }){{ arg1, arg2 }}.val >=20 > But the kernel folks might prefer endian ifdefs for some odd reason... You are right, this does seem odd considering what the other archs do.=20 It's quite possible I made a silly mistake, of course... I haven't tested with values outside the 32-bit range yet; again, this is= =20 new territory for me, so I haven't exactly done exhaustive tests on=20 everything. I'll give it a closer look. > > Also worth noting is the one other outstanding bug, where the > > time-related syscalls in the 32-bit vDSO seem to return garbage. It > > doesn't look like an endian bug to me, and it doesn't affect standard > > syscalls (which is why if you run `date` on musl it prints the > > correct time, unlike on glibc). The vDSO time functions are > > implemented in ppc asm (arch/powerpc/kernel/vdso32/ gettimeofday.S), > > and I've never touched the stuff, so if anyone has a clue I'm all > > ears. > Not sure about this. Worst-case, just leave it disabled until someone > finds a fix. Apparently these asm implementations are being replaced by the generic C=20 ones [1], so it may be this fixes itself on its own. Thanks, Will [she/her] [1]: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=3D17323= 1