mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Rich Felker <dalias@libc.org>, Nicholas Piggin <npiggin@gmail.com>
Cc: libc-alpha@sourceware.org, Andy Lutomirski <luto@kernel.org>,
	musl@lists.openwall.com, binutils@sourceware.org,
	Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	libc-dev@lists.llvm.org, Thomas Gleixner <tglx@linutronix.de>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [musl] Re: New powerpc vdso calling convention
Date: Thu, 30 Apr 2020 12:51:56 +1000	[thread overview]
Message-ID: <87v9lheldf.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20200425162204.GJ11469@brightrain.aerifal.cx>

Rich Felker <dalias@libc.org> writes:
> On Sat, Apr 25, 2020 at 08:56:54PM +1000, Nicholas Piggin wrote:
>> >> 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.
>
> A function descriptor could be put in the VDSO data page, or as it's
> done now by glibc the vdso linkage code could create it. My leaning is
> to at least have a version of the code that's callable (with the right
> descriptor around it) by v1 binaries, but since musl does not use
> ELFv1 at all we really have no stake in this and I'm fine with
> whatever outcome users of v1 decide on.
>
>> 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:
>
> I'm pretty sure it does know because signal invocation has to know
> whether the function pointer points to a descriptor or code. At least
> for FDPIC archs (similar to PPC64 ELFv1 function descriptors) it knows
> and has to know.

It does know, see TIF_ELF2ABI which is tested by is_elf2_task(), and as
you say is used by the signal delivery code.

Currently the VDSO entry points are not functions, so they don't need to
change based on the ABI.

cheers

      parent reply	other threads:[~2020-04-30  3:42 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
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 [this message]

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=87v9lheldf.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=adhemerval.zanella@linaro.org \
    --cc=binutils@sourceware.org \
    --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=npiggin@gmail.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).