[uClibc] ldso bug in uclibc?

Joakim Tjernlund joakim.tjernlund at lumentis.se
Mon Nov 8 14:26:59 UTC 2004


> 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.

 Jocke




More information about the uClibc mailing list