mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	Rich Felker <dalias@libc.org>
Cc: binutils@sourceware.org,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	libc-alpha@sourceware.org, libc-dev@lists.llvm.org,
	linuxppc-dev@lists.ozlabs.org, Andy Lutomirski <luto@kernel.org>,
	musl@lists.openwall.com, Thomas Gleixner <tglx@linutronix.de>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>
Subject: [musl] Re: New powerpc vdso calling convention
Date: Wed, 29 Apr 2020 12:39:22 +1000	[thread overview]
Message-ID: <1588126678.zjwj4d1d90.astroid@bobo.none> (raw)
In-Reply-To: <e8a9d3d9-18a7-2cb9-db70-74f7b107f744@linaro.org>

Excerpts from Adhemerval Zanella's message of April 27, 2020 11:09 pm:
> 
> 
> On 26/04/2020 00:41, Nicholas Piggin wrote:
>> Excerpts from Rich Felker's message of April 26, 2020 9:11 am:
>>> 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.
>> 
>> Right, I'm just talking about those comments -- it seems like the kernel 
>> vdso should contain an .opd section with function descriptors in it for
>> elfv1 calls, rather than the hack it has now of creating one in the 
>> caller's .data section.
>> 
>> But all that function descriptor code is gated by
>> 
>> #if (defined(__PPC64__) || defined(__powerpc64__)) && _CALL_ELF != 2
>> 
>> So it seems PPC32 does not use function descriptors but a direct pointer 
>> to the entry point like PPC64 with ELFv2.
> 
> Yes, this hack is only for ELFv1.  The missing ODP has not been an issue 
> or glibc because it has been using the inline assembly to emulate the 
> functions call since initial vDSO support (INTERNAL_VSYSCALL_CALL_TYPE).
> It just has become an issue when I added a ifunc optimization to 
> gettimeofday so it can bypass the libc.so and make plt branch to vDSO 
> directly.

I can't understand if it's actually a problem for you or not.

Regardless if you can hack around it, it seems to me that if we're going 
to add sane calling conventions to the vdso, then we should also just 
have a .opd section for it as well, whether or not a particular libc 
requires it.

> Recently on some y2038 refactoring it was suggested to get rid of this 
> and make gettimeofday call clock_gettime regardless.  But some felt that 
> the performance degradation was not worth for a symbol that is still used
> extensibility, so we stuck with the hack.
> 
> And I think having this synthetic opd entry is not an issue, since for 
> full relro the program's will be used and correctly set as read-only.

I'm not quite sure what this means, I don't really know how glibc ifunc 
works. How do you set r2 if you have no opd?

> The issue is more for glibc itself, and I wouldn't mind to just remove the
> gettimeofday and time optimizations and use the default vDSO support
> (which might increase in function latency though).
> 
> As Rich has put, it would be simpler to just have powerpc vDSO symbols
> to have a default function call semantic so we could issue a function
> call directly.  But for powerpc64, we glibc will need to continue to 
> support this non-standard call on older kernels and I am not sure if
> adding new symbols with a different semantic will help much.

Yeah, we will add entry points with default function call semantics.
At which point we make the things look like any other dso unless there 
is good reason otherwise.

> GLibc already hides this powerpc semantic on INTERNAL_VSYSCALL_CALL_TYPE,
> so internally all syscalls are assumed to have the new semantic (-errno
> on error, 0 on success). Adding another ELFv1 would require to add
> more logic to handle multiple symbol version for vDSO setup
> (sysdeps/unix/sysv/linux/dl-vdso-setup.h), which would mostly likely to
> require an arch-specific implementation to handle it.

Is it not a build-time choice? The arch can set its own vdso symbol 
names AFAIKS.

Thanks,
Nick

  reply	other threads:[~2020-04-29  2:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-25  5:22 [musl] " Nicholas Piggin
2020-04-25  5:40 ` Rich Felker
2020-04-25  7:47 ` [musl] " Christophe Leroy
2020-04-25 10:56   ` Nicholas Piggin
2020-04-25 12:20     ` Christophe Leroy
2020-04-25 22:58       ` Nicholas Piggin
2020-04-25 23:11         ` Rich Felker
2020-04-26  3:41           ` Nicholas Piggin
2020-04-27 13:09             ` Adhemerval Zanella
2020-04-29  2:39               ` Nicholas Piggin [this message]
2020-04-29 12:15                 ` Adhemerval Zanella
2020-05-05 21:56                 ` Segher Boessenkool
2020-04-25 16:22     ` Rich Felker
2020-04-25 23:07       ` Nicholas Piggin
2020-04-30  2:51       ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1588126678.zjwj4d1d90.astroid@bobo.none \
    --to=npiggin@gmail.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=binutils@sourceware.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=dalias@libc.org \
    --cc=libc-alpha@sourceware.org \
    --cc=libc-dev@lists.llvm.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@kernel.org \
    --cc=musl@lists.openwall.com \
    --cc=tglx@linutronix.de \
    --cc=vincenzo.frascino@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).