This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: fde-glibc.c bug
- To: Ulrich Drepper <drepper at cygnus dot com>
- Subject: Re: fde-glibc.c bug
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Tue, 3 Jul 2001 14:42:21 -0400
- Cc: Richard Henderson <rth 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> <m34rst7tpt.fsf@otr.mynet>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jul 03, 2001 at 11:28:30AM -0700, Ulrich Drepper wrote:
> 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).
Not passing link_map around has also another advantage:
glibc can pass info for the static binary that way as well.
On ia64, the statically linked binary can figure out its headers using the
__ia64_app_header like trick, but on other machines it would need kernel
help probably (AT_PHDR), so it would have to return error on older kernels
for statically linked binaries.
The tricky part would be if static binary dlopens a C++ library how would
glibc which was dlopened get the phdr/phnum pair from the static binary.
Jakub