This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: ppc64 vDSO in mainline
- From: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- To: Steve Munroe <sjmunroe at us dot ibm dot com>
- Cc: Roland McGrath <roland at redhat dot com>, Alan Modra <amodra at bigpond dot net dot au>, libc-alpha at sources dot redhat dot com
- Date: Sat, 26 Mar 2005 09:45:09 +1100
- Subject: Re: ppc64 vDSO in mainline
- References: <OF67FFC1DE.71101B9F-ON86256FCE.006A59E6-86256FCE.007D7D95@us.ibm.com>
>
> Another way to elliminate .rela.dyn relocations is to build the vdso for a
> absolute address. I see no value in randomizing the load address of the
> vdso. The functions we are dicussing (so far) are syscall replacements and
> offer no more exposure than existing syscalls. If the vdso is linked for a
> specific address the linker performs all local relocations (no .rela.dyn
> entries).
>
> But if we really need to randomize the vdso load address the kernel can
> relocate a fixed number of the vdso images and ramdomly pick one for each
> process.
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.
Ben.