From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 14305 invoked from network); 6 May 2020 09:39:13 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 May 2020 09:39:13 -0000 Received: (qmail 20451 invoked by uid 550); 6 May 2020 09:38:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26125 invoked from network); 5 May 2020 21:56:54 -0000 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 5 May 2020 16:56:24 -0500 From: Segher Boessenkool To: Nicholas Piggin Cc: Adhemerval Zanella , Rich Felker , libc-alpha@sourceware.org, musl@lists.openwall.com, binutils@sourceware.org, Andy Lutomirski , libc-dev@lists.llvm.org, Thomas Gleixner , Vincenzo Frascino , linuxppc-dev@lists.ozlabs.org Message-ID: <20200505215624.GP31009@gate.crashing.org> References: <1587790194.w180xsw5be.astroid@bobo.none> <9371cac5-20bb-0552-2609-0d537f41fecd@c-s.fr> <1587810370.tg8ym9yjpc.astroid@bobo.none> <976551e8-229e-54c1-8fb2-c5df94b979c3@c-s.fr> <1587855423.jug0f1n0b8.astroid@bobo.none> <20200425231119.GM11469@brightrain.aerifal.cx> <1587872025.rtx2ygrmn0.astroid@bobo.none> <1588126678.zjwj4d1d90.astroid@bobo.none> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1588126678.zjwj4d1d90.astroid@bobo.none> User-Agent: Mutt/1.4.2.3i Subject: [musl] Re: New powerpc vdso calling convention Hi! On Wed, Apr 29, 2020 at 12:39:22PM +1000, Nicholas Piggin wrote: > Excerpts from Adhemerval Zanella's message of April 27, 2020 11:09 pm: > >> 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. An OPD ("official procedure descriptor") is required for every function, to have proper C semantics, so that pointers to functions (which are pointers to descriptors, in fact) are unique. You can "manually" make descriptors just fine, and use those to call functions -- but you cannot (in general) use a pointer to such a "fake" descriptor as the "id" of the function. The way the ABIs define the OPDs makes them guaranteed unique. Segher