From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) by sourceware.org (Postfix) with ESMTPS id D37EF396ECAF; Sat, 25 Apr 2020 23:11:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D37EF396ECAF Received: by mail-pl1-x642.google.com with SMTP id v2so5311232plp.9; Sat, 25 Apr 2020 16:11:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=b1I5VhmS8YlY121R50I9dZXRP0z5VOB+6nzHXeobRZ4=; b=FgURG6kACmRCf09d/kY19ku8rj60domSHLBSDO5Pidy3hp5FJRDPnZQpGC5cUVpkKr G2aPKn6JXiaZi3D7LJun6vpDe2FSC4Ek7Q6StpwGW16UI3DgIdb8aj2OYSaKBWQLqOAQ hoWAOWoyvYfG2fn4aeqFtAtTkQMj/cwRK54+VrC3g7K7psqGPSCqv4QhzGU7fzLLsT2D apPx9HfpwA/h98vq+fvAi3yQdG1RYY8Kxzpfhvrt3fnRjU3YLM3f+lwS5Lefhbs5vEeM JU2RugOW3iqwb/8TErdRcZR93h4MX7xS928MIUrEAodytVFKty5vO6CoooJOxnxQN2HF FV6g== X-Gm-Message-State: AGi0PubrHIfjeUdIEc0nFamvOe4C94lzjiWag6QXkSXwfNXrFV09eirq LJlmgRQR054ts4QO3Q/SztA= X-Google-Smtp-Source: APiQypL9z+lErGO3Wv2xONslRLBtES/YBKacmV2UyBDfRuMs50K/d/6Z/lqEOzMwQ8lxDl7Id7383A== X-Received: by 2002:a17:90a:cb88:: with SMTP id a8mr3584852pju.82.1587856293025; Sat, 25 Apr 2020 16:11:33 -0700 (PDT) Received: from localhost ([203.220.177.17]) by smtp.gmail.com with ESMTPSA id b75sm7598803pjc.23.2020.04.25.16.11.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Apr 2020 16:11:32 -0700 (PDT) Date: Sun, 26 Apr 2020 09:07:57 +1000 From: Nicholas Piggin Subject: Re: [musl] Re: New powerpc vdso calling convention To: Rich Felker Cc: Adhemerval Zanella , binutils@sourceware.org, Christophe Leroy , libc-alpha@sourceware.org, libc-dev@lists.llvm.org, linuxppc-dev@lists.ozlabs.org, Andy Lutomirski , musl@lists.openwall.com, Thomas Gleixner , Vincenzo Frascino References: <1587790194.w180xsw5be.astroid@bobo.none> <9371cac5-20bb-0552-2609-0d537f41fecd@c-s.fr> <1587810370.tg8ym9yjpc.astroid@bobo.none> <20200425162204.GJ11469@brightrain.aerifal.cx> In-Reply-To: <20200425162204.GJ11469@brightrain.aerifal.cx> MIME-Version: 1.0 Message-Id: <1587855503.8grsasuwof.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 23:11:35 -0000 Excerpts from Rich Felker's message of April 26, 2020 2:22 am: > 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 alre= ady >> >> 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. >> >>=20 >> >> Is there a need for ELF v1 specific calls as well, or could those jus= t be >> >> deprecated and remain on existing functions or required to use the EL= F >> >> v2 calls using asm wrappers? >> >=20 >> > What's ELF v1 and ELF v2 ? Is ELF v1 what PPC32 uses ? If so, I'd say=20 >> > yes, it would be good to have it to avoid going through ASM in the mid= dle.. >>=20 >> I'm not sure about PPC32. On PPC64, ELFv2 functions must be called with=20 >> their address in r12 if called at their global entry point. ELFv1 have a= =20 >> function descriptor with call address and TOC in it, caller has to load=20 >> the TOC if it's global. >>=20 >> The vdso doesn't have TOC, it has one global address (the vdso data=20 >> page) which it loads by calculating its own address. >=20 > 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. I agree, I think it would be good to make it look as much like a normal function as possible. >> The kernel doesn't change the vdso based on whether it's called by a v1=20 >> or v2 userspace (it doesn't really know itself and would have to export=20 >> different functions). glibc has a hack to create something: >=20 > 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 knows on a per-executable basis (by looking at the ELF header). It=20 doesn't know per-system though so we can't patch the vdso accordingly.=20 But we could include both sets of entry points and map in the=20 appropriate one at exec time I think. >> >> Is there a good reason for the system call fallback to go in the vdso >> >> function rather than have the caller handle it? >> >=20 >> > I've seen at least one while porting powerpc to the C VDSO: arguments=20 >> > toward VDSO functions are in volatile registers. If the caller has to=20 >> > call the fallback by itself, it has to save them before calling the=20 >> > VDSO, allthought in 99% of cases it won't use them again. With the=20 >> > fallback called by the VDSO itself, the arguments are still hot in=20 >> > volatile registers and ready for calling the fallback. That make it ve= ry=20 >> > easy to call them, see patch 5 in the series=20 >> > (https://patchwork.ozlabs.org/project/linuxppc-dev/patch/59bea35725ab4= cefc67a678577da8b3ab7771af5.1587401492.git.christophe.leroy@c-s.fr/) >=20 > This is actually a good reason not to spuriously fail and fallback. At > present musl wouldn't take advantage of it because musl uses the > fallback path for lazy initialization of the vdso function pointer and > doesn't special-case the MIPS badness, but if it made a big difference > we probably could shuffle things around to only do the fallback on > archs that need it and avoid saving the input arg registers across the > vdso call. It's a point for it yes. I don't know if any libc or app would want to=20 instrument it or do special accounting or something for system calls. Thanks, Nick