This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Fw: Questions about VDSO
- From: Roland McGrath <roland at redhat dot com>
- To: Benjamin Herrenschmidt <benh at au1 dot ibm dot com>
- Cc: libc-alpha at sources dot redhat dot com,Steve Munroe <sjmunroe at us dot ibm dot com>,Alan Modra <amodra at bigpond dot net dot au>
- Date: Thu, 4 Nov 2004 20:02:30 -0800
- Subject: Re: Fw: Questions about VDSO
> I could ... I mean, yes, I could from the kernel, do the mprotect, fixup
> the OPD entries, thus triggering the COW, and mprotect back, yes, that's
> sort-of duplicating what ld.so already knows how to do tho ..
It is much more efficient to avoid the extra system calls, and the
relocation work itself can be quicker if done just for the special cases
needed.
> > What exactly do you mean here? The vDSO defines symbols and symbol
> > versions just like any other DSO.
>
> Yes, but I've been explained that they were "after" glibc in the symbol
> search path, that is, if the vdso defines gettimeofday(), the glibc
> version would override it anyway, but then, I don't know the details of
> how glibc & symbol versioning works.
You are the one who raised the issue, so I leave it to you to say what
issue you are actually talking about.
> Ok, that's just ignorance on my side
Yes. If you want to hack the dynamic linker, you should start by
understand its most basic implementation plan.