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 <luto@xxxxxxxxxxxxxx> wrote: >cc: Andi Kleen, who designed the vdso > >On Sun, Jun 15, 2014 at 10:57 AM, H. Peter Anvin <hpa@xxxxxxxxx> 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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
