Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751215AbaFOSk3 (ORCPT ); Sun, 15 Jun 2014 14:40:29 -0400 Received: from terminus.zytor.com ([198.137.202.10]:41300 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750749AbaFOSkZ (ORCPT ); Sun, 15 Jun 2014 14:40:25 -0400 User-Agent: K-9 Mail for Android In-Reply-To: References: <21405.44257.742122.786960@gargle.gargle.HOWL> <20140615143500.GP179@brightrain.aerifal.cx> <539DD26B.3060709@zytor.com> <539DDE9C.3010903@zytor.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [RFC 0/2] __vdso_findsym From: "H. Peter Anvin" Date: Sun, 15 Jun 2014 11:39:54 -0700 To: Andy Lutomirski , Andi Kleen CC: Rich Felker , Mikael Pettersson , Russ Cox , Linux API , Ian Taylor , "linux-kernel@vger.kernel.org" , X86 ML Message-ID: <4ab91a07-c46c-485b-895d-b074d36624d6@email.android.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Symbol versioning so we can rev the ABI and still provide backwards compatibility. Weak symbols so the libc can override symbols if it considers it appropriate. This is a good thing. On June 15, 2014 11:20:41 AM PDT, Andy Lutomirski wrote: >cc: Andi Kleen, who designed the vdso > >On Sun, Jun 15, 2014 at 10:57 AM, H. Peter Anvin wrote: >> On 06/15/2014 10:40 AM, Andy Lutomirski wrote: >>> >>> To be clear, I have no desire whatsoever to give the vdso an actual >>> ELF parser or anything else that userspace should be providing >itself. >>> I think that a special-purpose vdso parser in the vdso makes some >>> sense, though, since userspace might otherwise provide one for the >>> sole purpose of parsing the vdso. >>> >>> And there's plenty of reasons that having the vdso be an ELF image >is >>> useful. For one thing, gdb can take advantage of it. For another, >>> CRIU is parsing it for a rather different reason, and something like >>> __vdso_findsym won't fill that need. >>> >>> Also, given the general lack of a comprehensible specification of >what >>> the GNU flavor of the ELF format actually is [1], there's something >to >>> be said for reducing the proliferation of ELF parsers. glibc and >>> binutils are quite unlikely to become incompatible with each other, >>> but I sincerely doubt that anyone from binutils land is likely to >>> review (and maintain!) my ELF parser, Go's, or a hypothetical future >>> ELF parser from any of the other glibc-less things. If those things >>> use one that's in the kernel, then it's easy for the kernel to >>> guarantee that each vdso image can successfully parse itself. >>> >>> [1] The only comprehensible description of the GNU hash extension >that >>> I could find is on Oracle's blog (!) >>> >> >> Yes, but that is why we provide the standard SysV hash. The GNU hash >is >> not too bad, but you're absolutely right the documentation stinks. >> >> Providing a simple symbol lookup is an opportunistic thing, and might >be >> useful that way, and only because (as you say) the version in the >vdso >> would only need to be guaranteed to parse a single data structure -- >> that same vdso. >> >> On the other hand, it better work, correctly, in every version of the >> kernel, so I believe it will need to be done such that it is either >> correct by construction or gets self-tested during the build process >so >> it errors out on failure. > >I was thinking of adding something to selftests that would check that >__vdso_findsym can find every exported symbol, check that it can't >find the ones it shouldn't find, and call it on a bunch of garbage >strings to make sure it rejects them. > > >> One simple way to do correct by construction >> would be to do the "vdso entry point by index" -- a new kind of >system >> call numbers, in effect, as much as it has shades of Windows DLL with >> their "ordinal numbers". > >It's certainly easy. It's a little gross, and I sort of feel bad >about having two parallel ways of referring to a vdso function -- one >used by ELF parsers and one used by the new thing. Using an array >also wins on speed and code size. *sigh* -- I'm torn on this one. > >Do you know why the vdso uses symbol versioning and weak symbols in >the first place? This seems to date back all the way to the beginning >(2aae950b21e4bc789d1fc6668faf67e8748300b7). If we're going to add a >new way to find vdso symbols, I would like to at least drop support >for versions. > >--Andy -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/