This is the mail archive of the mailing list for the binutils 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: [PATCH] [MIPS] Ensure that local GOT entries accessed via a 16-bit index come first

"Maciej W. Rozycki" <> writes:
> On Wed, 16 Apr 2014, Richard Sandiford wrote:
>> This looks really good, thanks.  Just for the record, in case anyone else
>> was thinking the same thing: I was a bit worried at first about using
>> unsigned int for assigned_high_gotno, since it's an "end - 1" value.
>> But of course it can never be negative because we always have at least
>> one reserved entry before the local area.
>  I've been wondering if we need to do anything special about compound 
> relocs, e.g. GOT_PAGE/HI16, GOT_PAGE/LO16, etc. (aka %hi(%got_page(foo)), 
> etc.) in the new ABIs, that obviously can go towards the end of the local 
> GOT area.  I don't know offhand if GCC produces them for e.g. `-mabi=64 
> -xgot', especially perhaps GOT_DISP/HI16 and GOT_DISP/LO16 as we shouldn't 
> normally exhaust the 16-bit space for GOT_PAGE, but the ABI supports them 
> in principle.

GCC doesn't produce them.  I agree using GOT_PAGE/HI16 seems unlikely,
especially since the sequence to load an address would then require 3
instructions.  I imagine in practice everyone just uses GOT_{HI,LO}16
for all ABIs.

I don't think this was your point, but just in case: even if something
did use those in future, the patch is still a strict improvement over
the current situation, in that it handles {GOT,CALL}_{HI,LO}16 better
without changing the allocation scheme for the others.  I don't think
we should add extra code for compound GOT relocs without a patch to make
GCC use them (which I'm not convinced is a good idea).


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