Hi Carlos,
This is a newer updated version of the DSO sorting algorithm patch to fix BZ#17645.
Again there was a long delay since the last review round, sorry about that.
Since the 2.33 freeze is still tomorrow, hope this is still eligible to go in the release.

For reference, the last v3 version of this testing patch, and review thread:
https://sourceware.org/pipermail/libc-alpha/2020-July/116545.html

The main testing issues resolved in this v4 patch are:

(1) Supporting timeouts for DSO sorting tests:
     As we discussed in the last review round, using test-driver.c to support timeouts
     is essential, but the nature of the DSO sorting tests, where the action happens
     before/after main(), makes merely embedding a do_test() into test-driver.c not
     very useful.

     The attached v4 patch solves this by making a support/test-run-command utility,
     basically an adaptation of test-driver.c/support_test_main.c to execv() the
     command line arguments instead of running a linked function. Test runs show this
     performs as expected, timeout-ing the really big Redhat #1162810 test when sorted
     by the old algorithm (while the new one runs fast enough)

     (Side note: originally considered using coreutils timeout command to implement this,
     but wasn't really sure if I can assume its existence on the build machine, plus
     a test-driver.c based solution seemed to be a better integrated fit, even if using
     it a bit differently)

(2) Because timeout support is there, it makes sense to support XFAILing some of the tests.
     You can now use 'xfail_output' to specify a sorting output case that is assumed to fail.
     In the attached patch, we now XFAIL the Redhat #1162810 test when sorted by the old algorithm.
     (note that because both algorithm tests are collected under a single 'tst-redhat-1162810'
      testcase, it is summarized as a XFAIL at top-level, even though the new algorithm
      sub-test is a PASS, one has to look at the detailed output logs)

(3) Also something I overlooked in the last revision, new support for generally running all
     DSO sorting tests with both old/new algorithms using GLIBC_TUNABLES (the last revision
     only tested whatever was default). A new 'tunable_option' command in the test description
     files allows setting this.

Tested current master on x86_64-linux with no regressions, seeking approval
for getting this into 2.33.

Thanks,
Chung-Lin

2021-01-03  Chung-Lin Tang  <cltang@codesourcery.com>

	[BZ #17645]
	[BZ #15311]
	[BZ #15310]
	* elf/Makefile (include_dsosort_tests): New make function. Use
	to process dso-sort-tests-[12].def files.
	(single_dsosort_test): Likewise.
	* dso-sort-tests-1.def: New file with test descriptions.
	* dso-sort-tests-2.def: New file with test descriptions.
	* scripts/dso-ordering-test.py: New script.

	* support/Makefile: Add settings for building 'test-run-command' utility.
	* support/support_test_main.c (run_test_function): Use execv() to launch
	argv contents as command if in run-command-mode.
	* support/test-driver.h (struct test_config): Add char run_command_mode'
	field.
	* support/test-driver.c (main): Set test_config.run_command_mode = 1 if
	RUN_COMMAND_MODE macro defined.
	* support/test-run-command.c: New file, defines RUN_COMMAND_MODE macro
	and includes test-driver.c.