[ Date Prev][ Date Next][ Thread Prev][ Thread Next][ Date Index][ Thread Index]
Re: [mips-tls] A couple of potential changes to the MIPS TLS ABI
- To: Daniel Jacobowitz <dan@xxxxxxxxxxxxxxxx>
- Subject: Re: [mips-tls] A couple of potential changes to the MIPS TLS ABI
- From: Dominic Sweetman <dom@xxxxxxxx>
- Date: Fri, 4 Feb 2005 10:13:44 +0000
Daniel Jacobowitz (dan@xxxxxxxxxxxxxxxx) writes:
> > > Why not re-write the spec to say "unless you generate this sequence
> > > exactly like this, you'll probably prevent any future linker
> > > optimization from working" - and then leave it to the compiler
> > > toolchain.
> > >
> > > My opinion is that linker optimizations could be very valuable, given
> > > a cheap way of accessing a thread pointer. But MIPS Technologies are
> > > very unlikely to do heroic work on the linker for the o32 ABI - but we
> > > do intend to at least try that out for our NUBI ABI.
> >
> > Fine by me; if no one else responds, I'll do this.
> >
> > Note that when I make this change, I'm also going to let the compiler
> > schedule the sequences; whoever implements the linker optimizations can
> > go back and undo that.
>
> Unfortunately, I've realized that we can't sit on this fence. Here's a
> somewhat contrived example...
A very devilishly cunning example, too.
> The only way to make this work is either to mandate that an
> ABI-conforming compiler can not optimize the TLS access sequences, or
> to define additional relaxation marker relocations to mark valid
> sequences. Some platforms do one, some do the other.
>
> My preference is to do the latter, which we can postpone until someone
> is ready to implement them.
I agree.
--
Dominic Sweetman
MIPS Technologies
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706205/fax +44 1223 706250/swbrd +44 1223 706200
http://www.mips.com
|