[Mips}Using DT tags for handling local ifuncs
Maciej W. Rozycki
macro@codesourcery.com
Fri Jan 10 20:06:00 GMT 2014
On Sat, 21 Dec 2013, Richard Sandiford wrote:
> But I agree completely about having an explicit start for the local area.
> That's what the new tag I was suggesting was. So going back to the new
> GOT region, I was really thinking about the current:
>
> +------------------+
> | reserved entries |
> +------------------+
> | local entries |
> +------------------+ <-- T2
> | global entries |
> +------------------+
>
> becoming (with a new name for the new region):
>
> +------------------+
> | reserved entries |
> +------------------+
> | general GOT data |
> +------------------+ <-- T1
> | local entries |
> +------------------+ <-- T2
> | global entries |
> +------------------+
>
> It's entirely up to the static linker what goes in the new region.
> In our case it would be R_MIPS_IRELATIVE-relocated entries, but it could
> be anything really (including .lit4, .lit8, or whatever). I.e. this region
> would be handled like GOTs are on other targets.
I like this idea, especially given the desire to have small-data (i.e.
non-zero -G GAS option setting) in MIPS SVR4 binaries has been raised
several times. This would make the SHF_MIPS_GPREL section flag work as
intended and you can still keep the GGA_RELOC_ONLY region at the end as we
do now even though it does not require being reachable with GP-relative
addressing.
I'm not sure what to do about sections though -- they are not required in
final ELF binaries and not interpreted by ld.so, but we keep them and
therefore have to decide how to handle them. We could merge all the
original sections into .got, but that could be confusing to some. We
could keep original .lit4, .sdata, etc. section names, keeping .got for
the legacy GOT part and choosing a new name for the explicitly relocated
GOT part. But then the reserved entries wouldn't fit anywhere.
Also what about .sbss? Because of the way ELF segments work that must
come last in one or in a separate segment; the alternative is converting
it to all-zero initialised data.
These issues need not be resolved for ifunc support, I just thought they
might be worth mentioning so that they can taken into account when making
design decisions.
Maciej
More information about the Binutils
mailing list