RE: [Mips}Using DT tags for handling local ifuncs

[Jack Carter <Jack dot Carter at imgtec dot com>]

> > Too bad we are not in the same room. I keep reading that I am not
> > understanding stuff that I understand and visa versa ;-)
> 
> Don't think I accussed you of not understand things :-)

I was just bemoaning my lack of clarity. You guys are doing fine and I
appreciate the conversation.

> I just thought that you were saying that:
> 
> (A)
> > 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.

Yes I do have an issue with "LOCAL". I look at any tag with NO as a count and the table
this tag refers to locals which for gcc means HIDDEN and under. I keep looking at the special
entries at the end as exceptions.

> 
> and:
> 
> (B)
> > According to the same document: the local table "consists of local
> > GOT addresses, i.e.  non-preemptible (protected) addresses defined
> > within the executable/DSO."
> 
> together meant that there are DT_MIPS_LOCAL_GOTNO local GOT entries,
> all pointing to "non-preemptible (protected) addresses defined within
> the executable/DSO".  But that was never the case, even in the original
> 32-bit psABI.  The GOT has always started with entries that didn't
> fit the description in (B), even though those entries are included
> in DT_MIPS_LOCAL_GOTNO.  (At first it was just the dynamic resolver.
> The GNU extension added the link map too.)  So I don't feel too guilty
> about adding even more entries of this type.

Fine, we just need to redefine these tables word wise and set specific tags so we can add
more regions come what may.

By the way, being able to dump the GOT and see the symbolic name for the function
the entry represents is really nice for the extremely small set of folks that have to 
work on this stuff. I cannot come up with a good business case for its support, but
when I had it at SGI it really made it easier to debug GOT related issues. Just saying.

The downside is that you are putting stuff in the dynsym which are hidden and thus do
not need to be there. I don't think it is useful for the common man and thus should not
be implemented for those reasons. 

> 
> > Is it fair to say that i can start on the reserved entries (3?),
> > explicit non-preemptable,
> > implicit non-preemptable, global-preemptable. Or are there still
> > apparent issues?
> 
> It's 2 reserved entries at the moment (we're not changing that here).
> What I meant in (d) was that, by having the tag to specify the index
> of the first implicitly-relocated GOT entry, it would be possible to
> reserve more entries in future, if the need arose.  We wouldn't need
> it for ifuncs, but we might for some future feature.

I knew that, but wanted to demonstrate that I had no problem with extending the special
entries in the front or between any other of the GOT tables. They just need to be 
described in documentation (lord I will try) and not depend on magic ordering.

> 
> The other point I was trying to make is that I don't think we should
> view the new area as "explicit non-preemptable".  It's "explicitly-
> relocated" full stop.  It would be perfectly valid to have relocations
> against global preemptable symbols in there too, if a normal R_MIPS_{32,64}
> relocation wasn't what we wanted.
> 
> I.e.: the ABI-defined local GOT entries are effectively relocated by
> R_MIPS_REL32 (or R_MIPS_REL32+R_MIPS_64 on n64).  The ABI-defined global
> GOT entries are effectively relocated by R_MIPS_32 (or R_MIPS_64 on n64).
> The new area is for cases where these relocation types are not the ones
> we need.

I am good with this. I will just want it not to be included withing the range of anything
stating LOCAL if possible. 

> 
> E.g. if TLS support had been defined this way, we could have put TLS
> relocs in the new area too, even though some TLS relocs are against
> default-visibility globals.  I doubt we'll do that for compatibiility
> reasons, but it would still have been a valid use of the new area.

We can retrofit this later and have it work with the current scheme in glibc.

> 
> Thanks,
> Richard