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

On Thu, 19 Dec 2013, Richard Sandiford wrote:

> > Dealing with the ifunc "local" entries implicitly will save a
> > relocation lookup, a tiny blip of time in relation to the other costs
> > of calling the resolver. So I am arguing about how many angels can
> > dance on a pin.
> Yeah, maybe this is one we'll have to agree to disagree on.  I think the
> benefit of having an implicitly-relocated irelative region is small at best.
> I like the generality of including the GOT R_MIPS_IRELATIVE GOT
> relocations in the general .rel.dyn pool and sorting them accordingly,
> because it feels more future-proof.  I also think an implicit region is
> harder to handle in a backward-compatible way, since if we just add new
> tags, older ld.sos would ignore them and not flag an error.
> If someone else has any opinions about implicit irelative relocs vs.
> explicit irelative relocs though, please shout.

 I do, I think that while looking smart at first the concept of implicit 
GOT relocation on the MIPS target proved inflexible and difficult to 
maintain over the years (see e.g. the troubles with the __ehdr_start 
special symbol we had recently).  By using explicit relocs the 
inflexibility is removed and the likelihood of the need to add another 
special region in the GOT in the future minimised.  I haven't analysed any 
program startup performance implications this may have though.

 NB as far as's backwards compatiblity is concerned I think we can 
sort it out in either case, e.g. we could poison binaries with a dummy 
relocation old would choke upon.  Or there might be another, 
prettier way possible too, to be found by examining and seeing its 
abnormal termination conditions.


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