[Patch] Fix cycle detection and initialization order in dynamic loader

[Jeff Law]

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