[PATCH v3 1/2] BZ #17645, fix slow DSO sorting behavior in dynamic loader

[Chung-Lin Tang]

On 2020/7/27 8:40 AM, Carlos O'Donell wrote:
> On 7/22/20 2:10 PM, Chung-Lin Tang wrote:
>> I only now notice that "permute" vs "permutate" is an issue :) I've corrected the
>> spelling as you've suggested.
>>
>> The v3 patch is attached, please see if this is now okay for committing.
> 
> I'm going to review this shortly, but it's too late in the release to add it to 2.32.

Sigh, okay. I respect the release manager's decision.

> My plan, if you agree, is as follows:
> 
> (a) Review this promptly this week.
> (b) Switch the sense of the default to just use the new DFS sort.
> (c) Open 2.33 for development and commit the changes.
> (d) Sync Fedora Rawhide and spend the next 5 months testing this in Rawhide.

Thanks, I assume this means I'm (mostly) approved to commit soon after 2.33 development opens.

> There are still a few more changes we need to make in the test generation,
> for example the tests don't use support/test-driver.c which means they could
> hang the entire testsuite and they don't support timeouts because of this.
> 
> We should follow generating the test such that the executable uses test-drive.c
> like all new tests should. This way we can catch tests that used to take 200s
> and now take 1s (default timeout at 20s).

I understand the need to support timeouts, but actually, because of the nature of
the ld.so sorting tests, where a lot of the action happens before/after main(),
making the testcase executables use support/test-driver.c isn't really that
meaningful. In terms of the relations, you would need to wrap the entire ld.so into
a testcase for that to work.

Do we already have some support program that embeds support/test-driver.c (like a testcase)
and allows forking of a generic program + command-line? That should allow running the entire
ld.so with a timeout I suppose. Another method would be to do something in the generated
shell script wrapper to implement a timeout.

Thanks,
Chung-Lin