[RFC] ppc64 and calling conventions
Benjamin Herrenschmidt
benh at kernel.crashing.org
Thu Nov 11 15:09:52 EST 2004
On Wed, 2004-11-10 at 19:49 -0800, Roland McGrath wrote:
> Frankly I don't think we are ready to commit now to saying what is useful.
> There is significant work to be done and issues to be decided before glibc
> will ever actually call any of your entry points.
As far as the ppc vDSO is concerned, that is the issue that remains to
be decided... What are those issues that would block it on glibc side ?
x86_64 already calls the vDSO for gettimeofday(), though x86 uses hard
coded addresses outside of TASK_SIZE, we need something different.
> I would recommend that
> you start by getting a working vDSO in that has no interesting entry
> points, just the signal trampoline code (and it doesn't really matter
> whether you give that symbols or not, except perhaps to gdb). We have the
> support already there to make the trampoline unwind info available so that
> you can start using it and supporting nonexecutable stacks.
That is easy, I can just remove them... or leave them in and if we want
to expose thing differently, symbol versioning will make sure there is
no backward compatibility problem. One of the reasons here is that we
have a rather urgent need for the userland gettimeofday for the JVM
folks (though the JVM is such a special case, I may even end up adding a
couple of "jvm special" calls in the vDSO that they would get to
directly).
> I can't recommend right now that you do anything immediately to provide any
> entry points that you might feel compelled to stay compatible with later.
> We just haven't ironed out exactly how such things should be tied into
> libc, and until we do, all bets are off as to whether anything you choose
> now is something you'll want to stick with in the long run.
Ok, so can we start this discussion now then ? I'll separately commit a
version of the vDSO with only the signal tramps, and maybe
__kernel_gettimeofday.
Ben.
More information about the Linuxppc64-dev
mailing list