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

> > Thus for GNU, to fixup the ifunc entries in the local got I need to
> > partition it from the other local got entries and have explicit
> > offsets to at least the old local got region, the new ifunc local got
> > region and maybe even the global got region in case there are future
> > got region shuffling and or additions.
> Personally I'd rather not define an ifunc region per se.  The idea behind
> making the start of the "ABI-defined" local GOT explicit was that the GOT
> entries before that could be relocated using normal relocations rather than
> the implicit scheme (as most other targets do).  The advantages of that
> to me are:

Okay, I thought you wanted one.

> (a) It means no other extensions are needed in future if we need a fourth
>     type of GOT relocation (on top of the implicit R_MIPS_REL* for
>     local entries, the implicit R_MIPS_{32,64} for global GOT entries
>     and the new R_MIPS_IRELATIVE).


I am all in favor of more generic solutions to make later extensions painless.

> (b) It preserves the current scheme in which the ABI-defined part of the
>     GOT is relocated first.  If we had an ABI-defined ifunc region we would
>     need to go back and relocate it after processing the explicit relocations,
>     so it would logically be a new step.

Wrong, but it doesn't matter because a and c are good enough arguments. The 
explicit relocation is just a tight loop. Having another loop before or after it is not
an issue. But a and c trump this anyway.

> (c) It means that the explicit GOT relocations can be sorted with
>     the other relocations.  This could be useful if priorities are
>     ever added to ifuncs (like how constructors and destructors
>     can have priorities).


> (d) It leaves open the possibility of reserving entry 2 in future,
>     in a similar way to entry 1 is reserved now.

I don't understand entry 2 well enough, but I take your word for it.

> I think it's less work too.  We need to get bfd to mark out the new
> region either way, so both schemes should have equal complexity there.
> But relocating the start of the GOT normally would be less work for
> other tools.  E.g. the dynamic linker change I mentioned in my earlier
> reply.  But...

Yes, it would be less work. I like less work.

> > Is there a preference for the ifunc local got to be before the regular
> > local got or after?
> seems like you're still rejecting that idea. :-)

No, just misunderstood where you were trying to lead me.

> OTOH, the same problem applied when TLS was added: the TLS GOT entries
> needed to be explicitly relocated.  What happened then was that the
> entries were added after the global GOT.  I suppose that avoided the
> new tag, but the disadvantage is that it can force multi-GOTs to be
> used unnecessarily.  Especially since the global GOT needs to contain
> all symbols that have relocations against them, even if there are no
> GOT accesses to them.  But I could live with irelative relocations
> being handled this way too if you prefer.

Unless we go the route of SGI and associate the GOT entries with dynamic symbols,
we should just continue to treat these as true locals and keep them in the local
GOT. To do otherwise at this point would be just gratuitous and like you said,
trip multigot more often.
> Thanks,
> Richard

I am not convinced that I am on the same wave length with you guys yet, so is the
following what you had in mind?

I believe the local GOT is to be segmented with a implicit and explicit region. The implicit
region will behave as it does today and just add the load time offset. The explicit region will
be fixed up through the relocation table process. 

There will be a dynamic tag that points to the offset of the explicitly relocated local GOT. 
It can't be DT_MIPS_LOCAL_GOTIDX because that refers to entries with symbols 
associated with them so I am assuming that a new tag needs to be defined 

The current loop in the dynamic linker will go from the beginning of the local GOT to just before
the explicit local GOT start. It would be tempting to apply the diff to all the local GOT since
the ifunc will have to do that too, but that may well hinder future relocation options.

The static linker will have to segregate the explicit local GOT entries from the implicit local
GOT entries with the explicit following the implicit. They will together make up 


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