mips address+symbol issue.

[cgd@broadcom.com]

At 23 Jan 2004 16:09:33 -0500, Ian Lance Taylor wrote:
> cgd@broadcom.com writes:
> 
> > I can think of several possible solutions here:
> > 
> >         (1) don't allow GCC to emit "dla sym+offset" for
> >         -mno-explicit-relocs, or maybe just for -mno-explicit-relocs
> >         and the ABIs which stuff 64-bit pointers into 32-bit object
> >         files.
> > 
> >         (2) make binutils emit long code sequences for sym + offset when
> >         assembling objects for an ABI which stuffs 64-bit pointers
> >         into 32-bit object files.
> > 
> >         (3) punt.  (maybe even xfail the test for some MIPS targets w/
> >         -mno-explicit-relocs.)
> > 
> > It seems to me that (2) is *probably* the right fix, but others'
> > opinions would be appreciated.  I think I'm OK with (3), too, but it
> > might bite others down the road...
> 
> I'm not really happy about (2), because for those people who stuff
> 64-bit pointers into 32-bit object files it pessimizes the ordinary
> case.

yes, exactly.  It's also harder than (3).  8-)


> Personally, I would just punt.  It's too bad that code like that
> doesn't work, but does anybody really write it?  Plus it's not
> supported by the C standard.

(I don't know what the C standard says about this... I thought it had
issues with accessing an array out of bounds, which this doesn't do.
the array ends up being accessed with index 0, but how that index is
calculated is fairly tortuous.)

I could easily believe that there are people who write code like this,
e.g. to turn kseg0 array accesses into kseg1 array accesses.  (IIRC,
there was something like that on a Linux port on another arch, right?
where bad array offsets were behaving unexpectedly.)  But that doesn't
mean it's a good thing to do (and the code generation would work out
OK in that case, since they wouldn't be moving between regions w/
differences in the 31st bit of the address).


(I think i'm fine w/ (3), but i'd like to hear others' opinions.)


chris