Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Apr 2020 09:13:57 -0300
From: Adhemerval Zanella <>
To: Rich Felker <>, Nicholas Piggin <>
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

      __asm__ __volatile__ 
      ("mtctr %0\n\t"
       "mfcr  %0\n\t"
       : "+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.