This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] ppc64 vdso


Ok, here it is. I don't know the policy of this list regarding patches
sizes, so I've put it online at:

http://gate.crashing.org/~benh/ppc64-vdso-20041105.diff

Let me know if it's ok to inline a 75k patch in a mail next time.

This implements the basis support for a vDSO on 32 and 64 bits userland
running the ppc64 kernel, patch against current linus bk tree. Only
AT_SYSINFO_EHDR is passed down. The vDSO also exports 2 more things: a
map of implemented syscalls (that was asked, I think by Uli to make
things easier for glibc to know what the kernel supports) and a userland
version of gettimeofday() that we can use as a basis to implement
support for the vDSO-provided functions.

Of course, none of the above will do anything if glibc don't use them,
except for the signal trampoline which will be automatically used by the
kernel when the vDSO is present.

With the current patch, the vDSO is "linked" at 1Mb in process space and
mapped at 0x100000 virtual. There is no difference so there is no
relocation issue. I suppose the best solution is for me to implement
in-kernel COW of the OPDs & relocation if we want to add randomizing or
a PHDR specifying to locate the vDSO elsewhere, as Roland suggested.

Now remains to decide how we want to "link" those vDSO provided routines
with applications, if apps will link directly to the vDSO, in which
case, how do we make sure those symbols are preferred to glibc versions,
provided glibc doesn't explicitely wants to override them, I admit here
that I could use some education on ld.so behaviour & design here, any
pointers appreciated.

Regards,
Ben.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]