This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: fde-glibc.c bug
- To: Richard Henderson <rth at redhat dot com>
- Subject: Re: fde-glibc.c bug
- From: Ulrich Drepper <drepper at redhat dot com>
- Date: 03 Jul 2001 11:28:30 -0700
- Cc: Jakub Jelinek <jakub at redhat dot com>, hjl at lucon dot org, jes at sunsite dot dk, David Mosberger <davidm at hpl dot hp dot com>, gcc at gcc dot gnu dot org, libc-alpha at sources dot redhat dot com
- References: <d3pubkfymm.fsf@lxplus015.cern.ch><200107020854.f628sOS01676@jeswick.caldera.de><20010702055546.I32061@devserv.devel.redhat.com><d3ofr3uj0v.fsf@lxplus015.cern.ch> <m3g0cf81ne.fsf@otr.mynet><20010702175906.O32061@devserv.devel.redhat.com><m38zi77zrc.fsf@otr.mynet><20010703052922.Q32061@devserv.devel.redhat.com><20010703094940.A25128@redhat.com>
- Reply-To: drepper at cygnus dot com (Ulrich Drepper)
Richard Henderson <rth@redhat.com> writes:
> How about a for_each_dso type function that took a callback, takes
> care of the locking, passes the link_map and mapping bounds? The
> callback returns 0 to keep searching, non-zero is passed back to
> the caller.
That's more reasonable but passing the link_map is still too
dangerous. The callbacks mustn't change anything.
Therefore it is necessary in such a situation to define a new data
structure which contains the needed information and pass a pointer to
this structure to the callback. The data structure is an automatic
variable in the iterator and therefore changing it has no effect.
And yes, such a solution is the only way to ensure proper locking
(means, getting the load/unload mutex of ld.so).
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------