This is the mail archive of the
mailing list for the glibc project.
Re: ppc64 vDSO in mainline
- From: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- To: Roland McGrath <roland at redhat dot com>
- 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: Tue, 29 Mar 2005 08:29:27 +1000
- Subject: Re: ppc64 vDSO in mainline
- References: <200503282051.j2SKppW8004673@magilla.sf.frob.com>
On Mon, 2005-03-28 at 12:51 -0800, Roland McGrath wrote:
> > 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.
It's currently not using get_unmapped_area() but that could/should be
fixed. The problem is that a the current implementation maps the vDSO in
before the program. This is due to an historical fact with the initial
implementation which I did make sit above the stack, and thus required
to be setup before the stack. This is no longer the case though, so I
suppose I should move that bit and fix things up.
> 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.
Yup. I definitely need to revisit that part of the implementation.