Re: future libc6-sparcv9 and libc6-sparcv9b support
From: Jakub Jelinek <jakub@redhat.com>
Date: Thu, 18 Aug 2005 06:53:36 -0400
> Do you remember when we talked about how pre-v9 support could be done,
> including fast mutex support (for mutexes NPTL uses just 0/1/2 values
> of the futexes and does atomic ops on them, so sticking a ldstub lock
> in the MS byte would work).
Yes I do, but I've lost all time to work on this. And I see
no opportunity in the future.
> Do we need sparcv[78] NPTL programs being able to use process shared
> synchronization primitives with sparcv{9,64} NPTL programs, or is it
> enough when just sparcv[78] programs can talk together and sparcv{9,64}
> together?
I think the restriction is reasonable, and that's the way to go.
I was working on a way that would allow sharing, but the currently
layout of the glibc NPTL sources does not allow to override enough
of the implementation to pull it off. I was going to put a spinlock
into the semaphore structure, and stuff like that, for example. This
kind of approach would not have slowed down v9+/sparc64 much at all.
I really wanted to pursue things that way, just use ldstub for all
this stuff, but Ulrich would probably dislike it when he sees how much
stuff would need to be moved into sysdep/* overridable areas. Every
change to semaphores generically would require some sparc updates, for
example.
Lack of an atomic word compare and swap makes current glibc development
incredibly painful.
Reply to: