This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mips tls with -mlong64/-mgp32


Daniel Jacobowitz <drow@false.org> writes:
> On Fri, May 11, 2007 at 02:19:13PM +0100, Richard Sandiford wrote:
>> DJ Delorie <dj@redhat.com> writes:
>> > Hmmm... looking at it given what you've all said, I guess this isn't a
>> > GOT access at all, but a TLS data access?
>> 
>> Ah.  Yes, indeed. ;)
>> 
>> So there's nothing special about an offset of 4.  I think you should
>> just be able to make mips_symbolic_constant_p handle SYMBOL_DTPREL
>> and SYMBOL_TPREL like SYMBOL_GENERAL.
>
> Isn't there an overflow problem here?  If we use %tprel_hi(e1) and
> %tprel_lo(e1) nothing guarantees that %tprel_lo(e1+4) fits in the load.
> I don't think you can offset this at all.

The address is doubleword aligned, so it is OK.  But I'd just remembered
that the REL TLS relocs have no %hi/%lo addend pairing, so my suggestion
was indeed wrong on its own.  I suppose that even if we extended the
relocs, we'd still have to cope with old binutils.  Ugh.

We should already treat DImode %tprel addresses as non-offsettable,
so with any luck, the fix should simply be to change "m" to "o"
in the d<->m !TARGET_64BIT movdi patterns.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]