Re: [Patch] Fix cycle detection and initialization order in dynamicloader

[Jeff Law <law at redhat dot com>]

On 06/13/2012 11:07 AM, Mike Frysinger wrote:
> On Wednesday 13 June 2012 12:32:10 Jeff Law wrote:
> > On 06/12/2012 11:44 AM, Roland McGrath wrote:
> > > > http://sourceware.org/bugzilla/show_bug.cgi?id=13882 - contains a
> > > > patch.
> > >
> > > In fact it contains pointers to archives of this list, where Jeff
> > > posted patches.
> > >
> > > > Last time we discussed the bugs on the mailing list, Roland
> > > > mentioned that he wanted to review this later. Roland, could you do
> > > > this now, please? Or anybody else volunteering to review this bug
> > > > in the dynamic linker?
> > >
> > > I don't recall saying that and I don't think I have especially great
> > > context on this stuff.  I think Jeff should just restart the review
> > > by posting the minimal patch he wants to get in.
> >
> > When sorting objects to ensure proper initialization order we terminate
> > the sort too early resulting in incorrect initialization order for DSOs.
> >
> > Additionally, the sorting code is limited in the number of DSOs it can
> > properly handle because it using an array of chars for counts.
>
> nice work.  so by going to uint16_t, the new ldso limit is 65536 rather than
> 127 ?  should we add a pathological assert when that limit is hit ?
I certainly could if that's the consensus.  Right now we're at a point 
where seeing ~200 DSOs referenced by an executable is the high end and 
they're rarely in pathological order.  I suspect that we'd need to make 
algorithmic changes to keep the cost of the sort reasonable as we got 
into tens of thousands of DSOs.


> is it possible to add the tests to the tree to keep things from regressing ?
> seems like a corner case that is easy to break again :(.
I'm still quite the novice as far as the glibc testing harness and build 
system are concerned.  It'd probably be a whole lot more efficient for 
someone else to tackle that.

Jeff