This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] [MIPS] Ensure that local GOT entries accessed via a 16-bit index come first
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Kwok Cheung Yeung <kcy at codesourcery dot com>, <binutils at sourceware dot org>, <jack dot carter at imgtec dot com>, <hjl dot tools at gmail dot com>
- Date: Thu, 17 Apr 2014 07:19:37 +0100
- Subject: Re: [PATCH] [MIPS] Ensure that local GOT entries accessed via a 16-bit index come first
- Authentication-results: sourceware.org; auth=none
- References: <534E84C2 dot 9050505 at codesourcery dot com> <87y4z5hy4c dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1404162228520 dot 15259 at tp dot orcam dot me dot uk>
"Maciej W. Rozycki" <macro@codesourcery.com> 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).
Thanks,
Richard