Re: MIPS local symbol GOT reservation w/o a reference relocation

[Richard Sandiford <rdsandiford at googlemail dot com>]

Jack Carter <Jack.Carter@imgtec.com> writes:
> I currently have things working if the ifunc entries are represented in
> the primary got. Ie. there were references to them in the dso/exe being
> linked.
>
> There are .iplt stubs created for each ifunc that load and jump to the
> address in the got, whether primary as I currently have for PIC/CPIC
> links or igotplt for static links.
>
> For each got (primary or not) I generate an R_MIPS_IRELATIVE relocation
> pointing to the got entry. The got entry has the address of the original
> ifunc routine and the start up routine runs that routine and replaces
> the original value with the result of the ifunc run.

This was the bit I was worried about.  Most targets use normal relocations
like R_386_RELATIVE to relocate the GOT.  That makes it natural to substitute
things like R_386_IRELATIVE, which is "R_386_RELATIVE + indirection".

But (primary) MIPS GOTs don't work like that.  They're relocated based
on dynamic tags like DT_MIPS_LOCAL_GOTNO and DT_MIPS_GOTSYM instead.
So if an entry in the local GOT has an R_MIPS_IRELATIVE against it,
it sounds like that entry is going to get the "RELATIVE" treatment twice:
once when the local GOT is relocated according to DT_MIPS_LOCAL_GOTNO
and once when the R_MIPS_IRELATIVE is applied.

One way out of that would be to add new dynamic tags to mark out an
IRELATIVE area, but I don't know whether that's the best approach.
In fact, it probably isn't, because the primary GOT is relocated first,
before normal relocations are applied...

> The concern about multi-got is something I have had all along. Isn't
> there the issue that if the dso/exe being created was large, that
> references to the ifunc routine could be spread across gots?

Right.

> If that is the case, each of those got entries in the different gots
> would have to be fixed at runtime with their own IRELATIVE
> relocation. If I allow the current linker operation create these
> entries, but exchange their relocation to IRELATIVE it should just
> work.

Yeah, normal GOT references should work pretty naturally.  It just
sounded like multigot might make it trickier to reuse GOT entries for IPLTs,
especially if you're creating entries that aren't referenced by input bfds.

> Maybe the best thing to do is to have a hybrid system with both a .got
> and an igot.plt where the latter would be populated with ifuncs that
> have no references/relocations in the input objects.

Yeah, that sounds good.  It should be easier (and in some cases more efficient)
than trying to force entries into the main GOT.

Thanks,
Richard