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: [Mips}Using DT tags for handling local ifuncs

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.

If it is off the table, I'll stop harping about it ;-)


On 01/12/2014 01:28 AM, Richard Sandiford wrote:> "Maciej W. Rozycki" <> writes:
>>   I'm not sure what to do about sections though -- they are not required in
>> final ELF binaries and not interpreted by, 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.
> Thanks,
> Richard

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