Attach to test in container from debugglibc.sh
Some test cases are meant to be ran inside the container infrastructure
and make check automatically runs them as such. However, running a
single test case in a container without make check is useful.
This patch adds a new --tool option to testrun.sh that makes this easy,
as well as it adds a new option (-c or --in-container) to debugglibc.sh,
which causes the program under test to be ran in a container (with
WAIT_FOR_DEBUGGER=1), then automatically attaches GDB to it.
Automatically detecting if a test case is supposed to be ran inside a
container is harder (if not impossible), as Carlos pointed out [1],
however, this patch makes it easier to do it manually:
Using testrun.sh with containerized test:
$ ./testrun.sh --tool=container /absolute/path/to/program
Using debugglibc.sh with containerized test:
$ ./debugglibc.sh -c /absolute/path/to/program
Note: running these commands with relative paths causes error and
warning messages to be displayed, although the test case might succeed.
For example, with relative path:
$ ./testrun.sh --tool=container elf/tst-ldconfig-bad-aux-cache
error: subprocess failed: execv
error: unexpected error output from subprocess
/sbin/ldconfig: Warning: ignoring configuration file that cannot be opened: /etc/ld.so.conf: No such file or directory
info: f 0 1064 /var/cache/ldconfig/aux-cache 20 aux-cache
[...]
Whereas with absolute paths, the errors and warnings are gone:
$ ./testrun.sh --tool=container $PWD/elf/tst-ldconfig-bad-aux-cache
info: f 0 1064 /var/cache/ldconfig/aux-cache 20 aux-cache
[...]
[1] https://sourceware.org/ml/libc-alpha/2019-11/msg00873.html
Reviewed-by: Carlos O'Donell <carlos@redhat.com>