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


Unless this last argument below can convince you or at least give you pause
to consider "implicit, explicit, default" ordering, I will start on "explicit, implicit, 

I don't think it is the "right" thing to do, but what the heck, what is right and wrong
anyway? What you are proposing should be workable. I just need to get it correctly
written up before shipping.

Let me know and I will start coding,


> > DT_MIPS_LOCAL_GOTNO is a count, not an index. If one doesn't want
> > to include both the implicit and explicit partitions in this count then
> > it affects
> > how we locate both the local and global areas. If we assume both implicit and
> > explicit are local and make up DT_MIPS_LOCAL_GOTNO then the current
> > assumptions stay in place.
> Whether DT_MIPS_LOCAL_GOTNO is a count or an index is a semantic issue too.
> If it's a count, it counts from the start of the GOT, so includes the
> reserved entries at the beginning of the GOT as well as the local GOT
> entries themselves.

Maybe I should clarify that I am trying to follow this in the 64-bit ELF Object File
Specification. That may be an issue.

As defined in the document: "DT_MIPS_LOCAL_GOTNO:This member contains the
number of local GOT entries.". So it is a count of locals.

Are the explicit local or not? Are locals just STB_LOCAL or does it include INTERNAL and 

According to the same document: the local table "consists of local GOT  addresses, i.e.
non-preemptible (protected) addresses defined within the executable/DSO."

For whatever it is worth I don't think SGI (me) followed it strictly either. We must have
either pointed the DT_MIPS_GOTSYM at the beginning of the INTERNAL entries (we
ordered them INTERNAL, HIDDEN, PROTECTED, DEFAULT) or subtracted from it to 
point into the local got table. If needs be I have an elf dumper that is tuned to SGI MIPS
and can deconstruct the algorithm.

> Whichever way you look at it, the implicitly-relocated local GOT stops
> at index DT_MIPS_LOCAL_GOTNO.  What I'm proposing wouldn't change that.
> DT_MIPS_LOCAL_GOTNO isn't the number of entries that get R_MIPS_REL* treatment.

>> I think it would be fine to have explicit
>> relocations against global symbols here too in future, if the usual
>> R_MIPS_{32,64} isn't what we want for some reason.
> >
> > Fine, but we will probably need to make sure they follow the symbol to GOT
> > entry rules. That is why SGI had them in the global GOT partition. This will
> > mean that it would be best to have the explicit partition second so it can be
> > sequenced naturally with the global symbols along with the global GOT.
> I don't follow.  The global GOT has to be handled before processing
> the relocations (and of course the relocations against the GOT would
> follow the same rules as other dynamic relocations, like you say).
> If the ifunc region comes between the local GOT and the global GOT
> then the layout would be:
>    local GOT
>    ER GOT
>    global GOT
> but the processing order would be:
>    local GOT
>    global GOT
>    .rel.dyn (including ER GOT)

So what? It doesn't matter what the order is for processing. The locations matter
if we think that we might want to tap into the dynsym table later.

Once again, push comes to shove we could have another DT_MIPS_GOTSYM
variant that point to a different point in the .dynsym table.

> I don't see why having ER GOT after the local GOT is more logical than
> having it first from this point of view.  And the advantage of having it
> first is (d) from my earlier message.

You're right about d.

It is more logical to me because that is the way it use to be with SGI I suppose 
and you brought up the notion you may want to do that in the future - Symbol 
associated Internal, and Hidden got entries.

> If you think the ER region should come after the global GOT too, as in:
>    local GOT
>    global GOT
>    ER GOT

No, this is not what I suggest and it would be terrible idea.
> Thanks,
> Richard

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