[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a972a0e4-25bd-9cf5-75ec-2eb993ef1b6a@linaro.org>
Date: Thu, 23 Apr 2020 09:13:57 -0300
From: Adhemerval Zanella <adhemerval.zanella@...aro.org>
To: Rich Felker <dalias@...c.org>, Nicholas Piggin <npiggin@...il.com>
Cc: libc-alpha@...rceware.org, libc-dev@...ts.llvm.org,
linuxppc-dev@...ts.ozlabs.org, musl@...ts.openwall.com
Subject: Re: Powerpc Linux 'scv' system call ABI proposal take 2
On 22/04/2020 23:36, Rich Felker wrote:
> On Wed, Apr 22, 2020 at 04:18:36PM +1000, Nicholas Piggin wrote:
>> Yeah I had a bit of a play around with musl (which is very nice code I
>> must say). The powerpc64 syscall asm is missing ctr clobber by the way.
>> Fortunately adding it doesn't change code generation for me, but it
>> should be fixed. glibc had the same bug at one point I think (probably
>> due to syscall ABI documentation not existing -- something now lives in
>> linux/Documentation/powerpc/syscall64-abi.rst).
>
> Do you know anywhere I can read about the ctr issue, possibly the
> relevant glibc bug report? I'm not particularly familiar with ppc
> register file (at least I have to refamiliarize myself every time I
> work on this stuff) so it'd be nice to understand what's
> potentially-wrong now.
My understanding is the ctr issue only happens for vDSO calls where it
fallback to a syscall in case an error (invalid argument, etc. and
assuming if vDSO does not fallback to a syscall it always succeed).
This makes the vDSO call on powerpc to have same same ABI constraint
as a syscall, where it clobbers CR0.
On glibc we handle by simulating a function call and analysing the CR0
result:
__asm__ __volatile__
("mtctr %0\n\t"
"bctrl\n\t"
"mfcr %0\n\t"
"0:"
: "+r" (r0), "+r" (r3), "+r" (r4), "+r" (r5), "+r" (r6),
"+r" (r7), "+r" (r8)
: : "r9", "r10", "r11", "r12", "cr0", "ctr", "lr", "memory");
__asm__ __volatile__ ("" : "=r" (rval) : "r" (r3));
On musl you don't have this issue because it does not enable vDSO
support on powerpc. And if it eventually does it with the VDSO_*
macros the only issue I see is on when vDSO fallbacks to the syscall
and it also fails (the return code won't be negated since on musl it
uses a default C function pointer issue which does not model the CR0
kernel abi).
So I think the extra ctr constraint on glibc powerpc syscall code is
not really required. I think I have some patches to optimize this a
bit based on previous discussions.
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.
