[uClibc] ldso bug in uclibc?

[Joakim Tjernlund]

> > On Monday 08 Nov 2004 14:11, Andrew de Quincey wrote:
> > > On Monday 08 Nov 2004 13:51, Joakim Tjernlund wrote:
> > > > > On Monday 08 Nov 2004 13:39, Andrew de Quincey wrote:
> > > > > > > > Correct. m_handle = dlopen(dllName, RTLD_LAZY);
> > > > > > > >
> > > > > > > > Is this not just a matter of having the "struct elf_resolve
> > > > > > > > *tpnt" structures store the RTLD_GLOBAL/RTLD_LOCAL state (if they
> > > > > > > > don't already). _dl_find_hash then doesn't search a non-local and
> > > > > > > > non-global symbol table if it doesn't have RTLD_GLOBAL set. This
> > > > > > > > assumes our "implementation defined behaviour" for when neither
> > > > > > > > is set is to pretend RTLD_LOCAL was passed.
> > > > > > >
> > > > > > > No, not that easy. You must also consider the NEEDED libs when
> > > > > > > dlopening a lib. All NEEDED libs(that aren't already opened) will
> > > > > > > belong to the same RTLD_LOCAL group. Any libs relocation in the
> > > > > > > same RTLD_LOCAL group can relocate against any other lib in the
> > > > > > > group.
> > > > > > >
> > > > > > > You search all libs in load order, starting with the exe.
> > > > > > > To search a lib for symbols that lib must either have
> > > > > > > RTLD_GLOBAL set or that lib must belong to the same RTLD_LOCAL
> > > > > > > group.
> > > > > > >
> > > > > > > This is how I read the spec, I might be wrong though.
> > > > > >
> > > > > > Yeah - this is how I read it. But I must be missing something - what
> > > > > > do you mean by an RTLD_LOCAL group? I don't see anything like that on
> > > > > > that opengroup page. My reading is that syms in a library are either
> > > > > > all local or all global... I don't see any way of grouping libraries
> > > > > > together.
> > > > >
> > > > > Duh - ignore that. I see what you mean. Someone I missed the point of
> > > > > your first paragraph.
> > > >
> > > > Too late :)
> > > > If you have any ideas on how to impl. this, I am intressted. To start
> > > > with one must add the tpnt argument to dl_find_hash(like you did), but
> > > > then the hard part starts.
> > >
> > > Heh :)
> > >
> > > I thought about having a global group id - when you load a library for the
> > > first time, it, and any dependencies all get the current value of the group
> > > id. The group id is then incremented for the next dlopen(). The problem
> > > with this is libraries can belong to multiple groups... This could happen
> > > if it is a sublibrary used by multiple RTLD_LOCAL dlopen()ed objects.
> > >
> > > It sounds like each toplevel tpnt (i.e. one opened directly by dlopen())
> > > needs a list of pointers to the tpnts in its group. Then during the symbol
> > > resolution, you just check each library is GLOBAL, or in the list before
> > > checking its symbols.
> > 
> > Crap. that doesn't work either.
> > 
> > Actually doesn't this group thing mean there are unsolvable problems:
> > 
> > Say libsub.so is as described above - a sublibrary used by two RTLD_LOCAL 
> > dlopened() objects - and it requires a symbol. How does it know which group 
> > to resolve against?
> 
> The first matching group in load order, I think. This is the way it works
> for multiple symbols in the GLOBAL list.

hmm, that may simplify thing. libsub.so will/must relocate agaist the first
group. Not sure how though, I just realized this property.

 Jocke