This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Mips}Using DT tags for handling local ifuncs
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Jack Carter <Jack dot Carter at imgtec dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Date: Fri, 10 Jan 2014 20:06:11 +0000
- Subject: Re: [Mips}Using DT tags for handling local ifuncs
- Authentication-results: sourceware.org; auth=none
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DDC0F at BADAG02 dot ba dot imgtec dot org> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE59A at BADAG02 dot ba dot imgtec dot org> <alpine dot DEB dot 1 dot 10 dot 1312112311480 dot 19368 at tp dot orcam dot me dot uk> <87y53q4czx dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1312121406040 dot 19368 at tp dot orcam dot me dot uk> <87d2kz4uhi dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DF550 at BADAG02 dot ba dot imgtec dot org> <87ppot6gle dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DF9BE at BADAG02 dot ba dot imgtec dot org> <87txe5aw74 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DFD62 at BADAG02 dot ba dot imgtec dot org> <871u18c04i dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DFDA5 at BADAG02 dot ba dot imgtec dot org> <8761qk6045 dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DFFC2 at BADAG02 dot ba dot imgtec dot org> <871u185pgu dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6E022B at BADAG02 dot ba dot imgtec dot org> <87wqiy4ewa dot fsf at talisman dot default>
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