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]

Re: [PATCH] ppc64 vdso


On Fri, 2004-11-05 at 19:13 -0800, Roland McGrath wrote:
> Your vDSO linker script should provide a version script to specify the
> exports of your DSO (which should be stripped).  See
> arch/i386/kernel/vsyscall.lds.S for an example (but you should not use
> LINUX_2.5, but instead LINUX_2.6.10 or whatever upstream release number
> your vDSO will first appear).

Ok, will do. Why should the vDSO be stripped ? can't gdb make good use
of whatever debug infos I end up adding in there ?

> > - _v_get_syscall_map(). the prototype of this is
> 
> We have nothing that would use this as yet.  It would not be a great deal
> of work, though a bit intricate, to make use of this for the various places
> where we now sometimes try system calls and fall back when they are
> missing.  But we won't have any motivation to do that until there are
> platforms using this to make useful distinctions not made now.

Well, I added that upon request from Ulrich who said it would be useful
to get rid of some heuristics to know what syscalls are actually
implemented. Anyway, it's here, so feel free to use it.

> > - _v_gettimeofday(), same prototype as gettimeofday(), that is:
> 
> Can you provide nanosecond (i.e. struct timespec) access as well?
> And to the CLOCK_MONOTONIC as well as the CLOCK_REALTIME clock, ideally.

I could, what prototype ? So far, I implemented the equivalent of the
syscall sys_gettimeofday() so that it could be replaced "as-is". Note
that my internal calibration units are in 1/2^20th of second, that is
closer to the usec than to the nsec (and gettimeofday() does provide
you with the usec). So it may not be worth it. I don't know the posix
timer stuff, it's quite new afaik, and doesn't hook into the arch code,
so I'm not sure what are the CLOCK_MONOTONIC and CLOCK_REALTIME at this
point. The clock source used is the CPU timebase, all CPUs are in sync,
and the values returned are monotonic unless settimeofday() is called.

> > - __v_get_datapage() is for internal use by the vdso (hence the 2 underscores),
> >    used to access the last page of the vDSO which is shared with the kernel
> >    and contains various things used by gettimeofday or other future routines
> >    that will end up in the vDSO.
> 
> Such a thing should not be exported and is not the business of userland at all.
> It's purely an internal implementation detail of the DSO.

It is indeed. The only reason it's exported is for my own testing &
experiments at this point. It will be gone. One thing is that we had so
far an horrible kludge on ppc64 where a page of data called "sysconfig"
was exported via /proc/ppc64 and mmap'ed into some processes like the
JVM or IBM compilers, to get some infos about the CPUs, the caches,
etc.. I was toying with the idea of providing some accessors to those
data via the vDSO eventually, though it wouldn't be much advertised,
solely to replace the existing kludge, but then, it may not be a great
idea, and putting some data in /sys might be a better solution.

> But out of curiosity, why do you need it?  Why aren't those just normal
> TOC-relative accesses like the C compiler would generate for you?

No. The vDSO has no TOC (and thus doesn't require toc switching
trampolines if we ever want to over-optimize the calls to it). This
isn't really a data page of the vDSO. It's a kernel page that exist
regardless of the vDSO at this point (it can be mmap'ed into userland
separately, as I wrote earlier, via /proc, though I want to hide all of
this in the long term).

Ben.



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