fde-glibc.c bug
Jakub Jelinek
jakub@redhat.com
Tue Jul 3 11:46:00 GMT 2001
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
More information about the Libc-alpha
mailing list