This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: fde-glibc.c bug


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]