This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: PPC32 and state of the project
On Sunday 05 January 2003 20:32, Kevin B. Hendricks wrote:
> Hi,
>
> > > Can anything be done without an TLS register abi change?
> > > And is there a target register that we should be using to keep in sync
> > > with ppc64 or whatever?
> >
> > The main set of problems revolves around the thread register. Getting
> > LinuxThreads to run with a thread register is the first step. The next
> > step is designing and implementing ELF TLS (see
> > http://people.redhat.com/drepper/tls.pdf). Finally, the port of NPTL to
> > PPC awaits.
>
> Okay
>
> > > Who do we have to bug to get that register decision made and the abi
> > > changes made?
> >
> > Well, you'll now have to convince Franz. As far as I'm concerned he
> > makes now the PPC32 ABI decisions.
>
> Okay.
>
> > Well, I suggest to
> >
> > - start a discussion with interested parties about the thread register
> > decision;
>
> Okay, back in early November I asked about this on dev@linuxppc.org after
> reading Ulrich's posts to the Kernel mailing list about NPTL.
>
> Here is a short synopsis of what David Edelsohn and Andy Hernandez replied:
>
> ---snip--
> Kevin> Thread Library (NPTL) to add in support for ppc Linux? Has anyone
> Kevin> decided on what register will be used for Thread Local Storage on
> Kevin> PPC (32bit)? (Is this r13 on ppc64?). Have the necessary
> Kevin> modifications to the ABI/compiler been made to support a dedicated
> Kevin> thread local storage register?
>
> David> There still is a question of what the final version of thread
> David> support will look like in Glibc. TLS support has not been added to
> David> PowerPC GCC yet. GPR 13 is reserved for the thread ID. I do
> David> not know whether that also can be used as the TLS base pointer.
>
> Andy> Funny I was just talking to Richard Henderson on the plane about this
> Andy> last week.
>
> Andy> David, I was thinking on working on TLS for PPC (gcc side of things),
> Andy> but Kevin is right, we need to get a register and change the ABI,
> Andy> else things can get really spooky. I was thinking we could use
> Andy> r13 (?) like PPC64 does.
>
> Andy> I also vaguely recall that Geoff has a list of ABI changes pending.
> Andy> Perhaps we should do all these at the same time.
>
> So it looks like r13 was the choice and that Andy Hernandez, Richard
> Henderson, David Edelsohn, Franz and myself are the interested parties
>
> > - implement the LinuxThreads side. This won't need gcc support;
>
> Okay
>
> > - design ELF TLS; a prerequisite is a thread register;
>
> Okay I will grab http://people.redhat.com/drepper/tls.pdf
> and start reading up.
>
> > - implement ELF TLS in gcc and binutils. I do not know who will
> > volunteer to do this work.
> >
> > By the time all this is done there will most probably be a non-asm NPTL
> > port and porting NPTL to PPC32 should be easy. For the TLS design you
> > might want to consider talking to the PPC64 guys. I guess that perhaps
> > after substituting the thread register name the two ABIs can share the
> > same TLS design.
>
> Okay I will wait to hear from Franz about how he wants to attack this while
> I start reading the tls.pdf file and studying the linuxthreads code.
On PPC32 we can simply use R2 as the thread register, it's unused and
saved/restored by the kernel (in the kernel it's used for the 'current'
pointer) and doesn't require any changes to the ABI.
Besides the thread related stuff, there are a few less important things on my
TODO:
- *context functions need implementation
- control FPU via the prctl syscall instead of messing with a signal handler
Franz.