Re: enabling caching for dl_iterate_phdr()

[David Mosberger <davidm@napali.hpl.hp.com>]

>>>>> On Sat, 17 Jan 2004 00:29:31 +0100, Jakub Jelinek <jakub@redhat.com> said:

  Jakub> On Fri, Jan 16, 2004 at 04:57:26PM -0800, Roland McGrath wrote:
  >> > 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.

  Jakub> How about extending struct dl_phdr_info and passing an counter in it
  Jakub> to dl_iterate_phdr's callback?
  Jakub> The structure can be extended at the end, because dl_iterate_phdr
  Jakub> passes its size to the callback as well.
  Jakub> The callback is called with dl_load_lock held, so the counter doesn't
  Jakub> even have to be atomic.
  Jakub> libgcc_s would just see if size includes the additional field in the
  Jakub> first callback, if yes, it would record that counter and on subsequent
  Jakub> dl_iterate_phdr call it would first check whether the counter did not
  Jakub> change and if it is the same, it could use cached info.

Sounds good to me.  I assume it'd be OK to have separate "additions"
and "removals" counters?  Only the latter is needed for avoiding stale
values in a cache, but the former helps performance, because
dl_iterate_phdr() can be stopped early if we know that the list didn't
change.

I'd be happy to prototype the necessary code, but at the moment, glibc
doesn't build for me on ia64 (it crashes in rpcgen).  I assume that's
due to the stuff Uli is working on.

	--david