Re: enabling caching for dl_iterate_phdr()

[Roland McGrath <roland at redhat dot com>]

>   >> Would it be possible to add two atomic counters,
>   >> dl_load_additions and dl_load_removals, which would get
>   >> incremented whenever something is a phdr is added to/removed from
>   >> the list that is traversed by dl_iterate_phdr()?
> 
>   Roland> What interface do you propose for exposing such counters?
>   Roland> We won't be adding any published interfaces using variables.
> 
> I think that's OK.  Do you think it would be OK to add a function
> which returns the address of one of several "atomic counter" variables?

That is a reasonable kind of interface in general.  The trouble here is
that glibc does not have any exported interfaces using atomic counters.
The right type to use for these is machine-dependent; `int' is not the
proper thing to be using in the interface.  The types used in atomic.h are
fine, but that is not an exported interface.  We don't want to export it in
that form.  Unless you want to wait for that, this seems like a blocker for
that style of interface.

>   enum {
> 	AC_DL_LOAD_ADDITIONS,
> 	AC_DL_LOAD_REMOVALS
>   } libc_atomic_counter_t;

For an exported interface using a parameter like this does not seem like
the best plan to me.  If new flavors are added, this is not well-expressed
for ABI compatibility.  To me, the simplest way to do compatibility issues
right is to use single-purpose entrypoints with separate names so symbol
versioning will just take care of it.  So, add a single entrypoint
specifically for these two counters now.  If you change it in the future,
you can add entrypoints or change the old entrypoint signature under the
same name using symbol versioning.

> In any case, if a callback-based approach is preferred, I can live
> with that, too.

I don't claim it's the best interface.  But that is the approach that
doesn't have other blocking issues right now.