This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: ppc64 vDSO in mainline
- From: Roland McGrath <roland at redhat dot com>
- To: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- Cc: Steve Munroe <sjmunroe at us dot ibm dot com>,Alan Modra <amodra at bigpond dot net dot au>, libc-alpha at sources dot redhat dot com
- Date: Mon, 28 Mar 2005 12:51:51 -0800
- Subject: Re: ppc64 vDSO in mainline
> Ok, but there was another reason in the back of my mind for wanting to
> keep the vDSO virtual address flexible: The current choice of the map
> address for it was done rather arbitrarily (+1Mb). It appears that
> pretty much nobody uses that space currently. However, it removes some
> flexibility from userland programs over the layout of their address
> space (things like emulators etc... may want greater control). So I had
> in mind the possibility in the future of defining some sort of ELF
> program header enter that would force the kernel to map the vDSO at a
> different address for a given binary.
This is already covered adequately by the spec. A program has to give
phdrs covering any space it wants reserved for its own use, and anything
else is up for grabs by the OS. If the vdso mapping just does the normal
thing (get_unmapped_area with or without a hint address, but no MAP_FIXED),
it will do all the right things. If you give a hint, that will usually be
the address, but not if there is a conflict with the executable's segments.
If you don't give a hint, the address assigned will be predictable
(i.e. repeat the same on a given installation), or else be randomized when
that is done for other mappings, just like normal DSO mappings are.