[uClibc] ldso bug in uclibc?

[Andrew de Quincey]

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?