This is the mail archive of the
mailing list for the binutils project.
RE: [Mips}Using DT tags for handling local ifuncs
- From: Jack Carter <Jack dot Carter at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "Maciej W. Rozycki" <macro at codesourcery dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Date: Mon, 13 Jan 2014 18:40:00 +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> <alpine dot DEB dot 1 dot 10 dot 1401101942340 dot 27272 at tp dot orcam dot me dot uk> <87bnzhpn0t dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6EE5F6 at BADAG02 dot ba dot imgtec dot org>,<874n57pwu3 dot fsf at talisman dot default>
On 01/13/2014 10:20 AM, Richard Sandiford wrote:> Jack Carter<Jack.Carter@imgtec.com> writes:
>> >So, does this mean that following the SGI implementation of GP regions
>> >for multigot is off the table? We bundled all the GP relative sections
>> >into the equation with each GP region having parts of each. That is,
>> >there would be multiple .got, .sbss, .sdata, .litxx sections in the
>> >final dso/exe, but only one per GP region.
>> >We solved the problem. It was well described in the .dynamic table(s) and
>> >straight forward for the dynamic linker and dumpers to decipher. Unfortunately
>> >it never made it in the ABI documentation.
> I don't follow. Whether we use the SGI implementation or not wouldn't
> affect things here. Whether sections keep their original names or are
> merged into .got isn't a question for the dynamic linker (which doesn't
> care about sections), so it's independent of whether we use dynamic
> relocs or multiple .dynamics to handle secondary GOTs. The question
> instead was how to implement this in the static linker. As bfd works
> now, it would be difficult to express the idea of secondary GOTs having
> secondary .lit4 output sections, etc., in the linker script. So we
> would need to fiddle with or ignore the linker script if we want
> separate (and perhaps multiple) .lit4 output sections. That's why I
> thought putting everything in .got would be easiest. (As it stands now,
> the single .got output section in the linker script is used for both primary
> and secondary GOTs.)
> And both the SGI and binutils implementation would describe the result
> perfectly well. The new tag I'm suggesting would allow this to work
> with no further changes to the dynamic linker.
I am really ready to let this go. I had to redo the guts of the SGI linker to implement
our multigot. I am not in the mood to take on binutils/ld. As you stated, input obj order
is important and needs to be honored. Everything was split up based on that. The GP
regions were build as the input objects were processed for combining. I had to do this
up to 3 times in a static link if there was to be multigot. The first time was to try to
have standard single got. The next 2 were to create the multigot. For the life of me I
can't remember why 2 final passes instead on 1, but for some reason it was needed.
For clarification sake:
What I mean by "describing" is that even though technically there are no
sections in an executable, many mortals like myself dump section headers
to see what is where and also to dump the isolated sections.
If they are all stuffed into .got, this is lost.
And yes, I did also mean the .dynamic descriptions of the multi-GP regions.
It did make my life easier then. But we are not working on the SGI linker.
Please let me surrender on this issue ;-)
> As for splitting up .sbss and .sdata: the point is that users are
> allowed to assume that sections are concatenated in the order specified
> by the linker script, which is usually command-line order. So for example
> an object could be split across several input .sdata sections, a bit like
> .init_array is really a single array formed from many input .init_arrays.
> We would need to define a new section if we want something that the static
> linker is free to reorder.
>> >On 01/12/2014 01:28 AM, Richard Sandiford wrote:> "Maciej W. Rozycki"
>> ><firstname.lastname@example.org> writes:
>>>> >>> 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.
>>> >>Yeah, I was wondering this too. Things like .lit4 could be handled even
>>> >>in a multigot object, since there's no ODR problem with duplicating the
>>> >>contents in each GOT that needs them (i.e. it's not valid to rely on
>>> >>address equality for .lit4 entries). So for those I think we could
>>> >>end up with the contents being spread across several GOTs. And in
>>> >>that case just putting them in .got might be easiest.
>>> >>Obviously that isn't possible for .sdata and .sbss: we need to keep
>>> >>the original link order. But in principle we could still put .sdata
>>> >>in a single secondary GOT.
>>> >>It wouldn't be trivial to do any of this and to make it coexist with
>>> >>linker scripts though. I'm not sure it's worth spending too much time
>>> >>thinking about it unless someone's actually ready to implement it.
>>> >>And I'm not sure whether .sdata and .sbss would be much of a win in
>>> >>practice. It would only help with PIEs and DSOs that make relatively
>>> >>heavy use of a small amount of global state. How many modern DSOs have
>>> >>that pattern?
>>>> >>> 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.
>>> >>Yeah, it would mean doing the latter. That comes pretty much for free though:
>>> >>it happens whenever a bss-like section gets stuck behind something else.