New powerpc vdso calling convention

[Rich Felker]

On Sun, Apr 26, 2020 at 08:58:19AM +1000, Nicholas Piggin wrote:
> Excerpts from Christophe Leroy's message of April 25, 2020 10:20 pm:
> > 
> > 
> > Le 25/04/2020 à 12:56, Nicholas Piggin a écrit :
> >> Excerpts from Christophe Leroy's message of April 25, 2020 5:47 pm:
> >>>
> >>>
> >>> Le 25/04/2020 à 07:22, Nicholas Piggin a écrit :
> >>>> As noted in the 'scv' thread, powerpc's vdso calling convention does not
> >>>> match the C ELF ABI calling convention (or the proposed scv convention).
> >>>> I think we could implement a new ABI by basically duplicating function
> >>>> entry points with different names.
> >>>
> >>> I think doing this is a real good idea.
> >>>
> >>> I've been working at porting powerpc VDSO to the GENERIC C VDSO, and the
> >>> main pitfall has been that our vdso calling convention is not compatible
> >>> with C calling convention, so we have go through an ASM entry/exit.
> >>>
> >>> See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=171469
> >>>
> >>> We should kill this error flag return through CR[SO] and get it the
> >>> "modern" way like other architectectures implementing the C VDSO: return
> >>> 0 when successfull, return -err when failed.
> >> 
> >> Agreed.
> >> 
> >>>> The ELF v2 ABI convention would suit it well, because the caller already
> >>>> requires the function address for ctr, so having it in r12 will
> >>>> eliminate the need for address calculation, which suits the vdso data
> >>>> page access.
> >>>>
> >>>> Is there a need for ELF v1 specific calls as well, or could those just be
> >>>> deprecated and remain on existing functions or required to use the ELF
> >>>> v2 calls using asm wrappers?
> >>>
> >>> What's ELF v1 and ELF v2 ? Is ELF v1 what PPC32 uses ? If so, I'd say
> >>> yes, it would be good to have it to avoid going through ASM in the middle.
> >> 
> >> I'm not sure about PPC32. On PPC64, ELFv2 functions must be called with
> >> their address in r12 if called at their global entry point. ELFv1 have a
> >> function descriptor with call address and TOC in it, caller has to load
> >> the TOC if it's global.
> >> 
> >> The vdso doesn't have TOC, it has one global address (the vdso data
> >> page) which it loads by calculating its own address.
> >> 
> >> The kernel doesn't change the vdso based on whether it's called by a v1
> >> or v2 userspace (it doesn't really know itself and would have to export
> >> different functions). glibc has a hack to create something:
> >> 
> >> # define VDSO_IFUNC_RET(value)                           \
> >>    ({                                                     \
> >>      static Elf64_FuncDesc vdso_opd = { .fd_toc = ~0x0 }; \
> >>      vdso_opd.fd_func = (Elf64_Addr)value;                \
> >>      &vdso_opd;                                           \
> >>    })
> >> 
> >> If we could make something which links more like any other dso with
> >> ELFv1, that would be good. Otherwise I think v2 is preferable so it
> >> doesn't have to calculate its own address.
> > 
> > I see the following in glibc. So looks like PPC32 is like PPC64 elfv1. 
> > By the way, they are talking about something not completely finished in 
> > the kernel. Can we finish it ?
> 
> Possibly can. It seems like a good idea to fix all loose ends if we are 
> going to add new versions. Will have to check with the toolchain people 
> to make sure we're doing the right thing.

"ELFv1" and "ELFv2" are PPC64-specific names for the old and new
version of the ELF psABI for PPC64. They have nothing at all to do
with PPC32 which is a completely different ABI from either.

Rich