[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1587785455.59207xhucl.astroid@bobo.none>
Date: Sat, 25 Apr 2020 13:40:24 +1000
From: Nicholas Piggin <npiggin@...il.com>
To: Adhemerval Zanella <adhemerval.zanella@...aro.org>, Rich Felker
<dalias@...c.org>
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
Excerpts from Rich Felker's message of April 24, 2020 3:42 am:
> On Thu, Apr 23, 2020 at 02:15:58PM -0300, Adhemerval Zanella wrote:
>>
>>
>> On 23/04/2020 13:43, Rich Felker wrote:
>> > On Thu, Apr 23, 2020 at 01:35:01PM -0300, Adhemerval Zanella wrote:
>> >>
>> >>
>> >> On 23/04/2020 13:18, Rich Felker wrote:
>> >>> On Thu, Apr 23, 2020 at 09:13:57AM -0300, Adhemerval Zanella wrote:
>> >>>>
>> >>>>
>> >>>> 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.
>> >>>
>> >>> I think you mean "vsyscall", the old thing glibc used where there are
>> >>> in-userspace implementations of some syscalls with call interfaces
>> >>> roughly equivalent to a syscall. musl has never used this. It only
>> >>> uses the actual exported functions from the vdso which have normal
>> >>> external function call ABI.
>> >>
>> >> I wasn't thinking in vsyscall in fact, which afaik it is a x86 thing.
>> >> The issue is indeed when calling the powerpc provided functions in
>> >> vDSO, which musl might want to do eventually.
>> >
>> > AIUI (at least this is true for all other archs) the functions have
>> > normal external function call ABI and calling them has nothing to do
>> > with syscall mechanisms.
>>
>> My point is powerpc specifically does not follow it, since it issues a
>> syscall in fallback and its semantic follow kernel syscalls (error
>> signalled in cr0, r3 being always a positive value):
>
> Oh, then I think we'll just ignore these unless the kernel can make
> ones with a reasonable ABI. It's not worth having ppc-specific code
> for this... It would be really nice if ones that actually behave like
> functions could be added though.
Yeah this is an annoyance for me after making the scv ABI return -ve in
r3 for error and other things that more closely follow function calls,
we still have the vdso functions using the old style.
Maybe we should add function call style vdso too.
Thanks,
Nick
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.
