This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PowerPC64 TLS ABI
On Fri, Jan 17, 2003 at 02:11:41PM -0800, Richard Henderson wrote:
> I notice that your relaxation is predicated on the instructions
> appearing in sequence. For GD and LD this is no big deal, since
> there's a call involved. But for IE it's probably more important
> to allow the ld/add pair to be scheduled independently.
Hi Richard,
Thanks for reviewing! Getting things right at this point saves
pain later. :)
> There are several ways you can address this.
Hmm, maybe I should tag the add or load instruction with a new reloc,
and possibly cheat in the linker by only relaxing inside 32k
initially. I had been planning to do instruction scanning, thinking
that it was reasonably safe. What can go amiss? Is there a
possibility that
ld 9,x@got@tprel(2)
add 9,9,13
might become
ld 9,x@got@tprel(2)
mr 30,9
add 9,30,13
or something similar? Hmm, code motion over branches might even be a
little tricky for the reloc tag scheme.
> I also think you should explicitly list all the relaxation
> forms you'll accept. You listed the immediate forms, but
> not the indexed load forms.
Yeah, I suppose. lbzx, lhzx, lwzx, ldx, lhax, lwax, and the update
forms too.
> Oh, another question. Why variant II data structures?
> I happen to think they're not as conceptually clean as
> variant I, and there's no reason to adopt them for a
> target not trying to be compatible with Sun.
My original reason for choosing type II was to make use of "the thread
pointer points to a Thread Control Block of unspecified size and
content", and actually offset tp from the TCB base in order to
maximize the useful range of one-instruction tprel addressing. I then
decided not to bother with an offset tp. I suppose there's really no
reason we couldn't use an offset tp with variant I, and what's more,
the offset would be the same as for dtv. ie. r13 - 0x8000 would point
at TCB. I like it!
--
Alan Modra
IBM OzLabs - Linux Technology Centre