[1/2] Attach to test in container from debugglibc.sh
Commit Message
From: "Gabriel F. T. Gomes" <gabrielftg@linux.ibm.com>
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
---
Makefile | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
Comments
On 12/3/19 9:36 PM, Gabriel F. T. Gomes wrote:
> From: "Gabriel F. T. Gomes" <gabrielftg@linux.ibm.com>
This is much better than what we have, thank you for implementing this!
We can always improve this as time goes on.
LGTM.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
> 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
> ---
> Makefile | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index fae71aa287..924fdb6c0f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -181,6 +181,11 @@ case "$$toolname" in
> valgrind)
> exec env $(run-program-env) valgrind $(test-via-rtld-prefix) $${1+"$$@"}
> ;;
> + container)
> + exec env $(run-program-env) $(test-via-rtld-prefix) \
> + $(common-objdir)/support/test-container \
> + env $(run-program-env) $(test-via-rtld-prefix) $${1+"$$@"}
OK.
> + ;;
> *)
> usage
> ;;
> @@ -202,6 +207,7 @@ define debugglibc
> SOURCE_DIR="$(CURDIR)"
> BUILD_DIR="$(common-objpfx)"
> CMD_FILE="$(common-objpfx)debugglibc.gdb"
> +CONTAINER=false
> DIRECT=true
> SYMBOLSFILE=true
> unset TESTCASE
> @@ -235,6 +241,9 @@ Options:
>
> The following options do not take arguments:
>
> + -c, --in-container
> + Run the test case inside a container and automatically attach
> + GDB to it.
OK.
> -i, --no-direct
> Selects whether to pass the --direct flag to the program.
> --direct is useful when debugging glibc test cases. It inhibits the
> @@ -263,6 +272,9 @@ do
> ENVVARS="$$2 $$ENVVARS"
> shift
> ;;
> + -c|--in-container)
> + CONTAINER=true
> + ;;
OK.
> -i|--no-direct)
> DIRECT=false
> ;;
> @@ -348,6 +360,13 @@ echo "GDB Commands : $$CMD_FILE"
> echo "Env vars : $$ENVVARS"
> echo
>
> +if [ "$$CONTAINER" == true ]
> +then
> +# Use testrun.sh to start the test case with WAIT_FOR_DEBUGGER=1, then
> +# automatically attach GDB to it.
> +WAIT_FOR_DEBUGGER=1 $(common-objpfx)testrun.sh --tool=container $${TESTCASE} &
> +gdb -x $${TESTCASE}.gdb
OK. Good use of this infrastructure.
> +else
> # Start the test case debugging in two steps:
> # 1. the following command invokes gdb to run the loader;
> # 2. the commands file tells the loader to run the test case.
> @@ -355,6 +374,7 @@ gdb -q \
> -x $${CMD_FILE} \
> -d $${SOURCE_DIR} \
> $${BUILD_DIR}/elf/ld.so
> +fi
OK.
> endef
>
> # This is another handy script for debugging dynamically linked program
>
@@ -181,6 +181,11 @@ case "$$toolname" in
valgrind)
exec env $(run-program-env) valgrind $(test-via-rtld-prefix) $${1+"$$@"}
;;
+ container)
+ exec env $(run-program-env) $(test-via-rtld-prefix) \
+ $(common-objdir)/support/test-container \
+ env $(run-program-env) $(test-via-rtld-prefix) $${1+"$$@"}
+ ;;
*)
usage
;;
@@ -202,6 +207,7 @@ define debugglibc
SOURCE_DIR="$(CURDIR)"
BUILD_DIR="$(common-objpfx)"
CMD_FILE="$(common-objpfx)debugglibc.gdb"
+CONTAINER=false
DIRECT=true
SYMBOLSFILE=true
unset TESTCASE
@@ -235,6 +241,9 @@ Options:
The following options do not take arguments:
+ -c, --in-container
+ Run the test case inside a container and automatically attach
+ GDB to it.
-i, --no-direct
Selects whether to pass the --direct flag to the program.
--direct is useful when debugging glibc test cases. It inhibits the
@@ -263,6 +272,9 @@ do
ENVVARS="$$2 $$ENVVARS"
shift
;;
+ -c|--in-container)
+ CONTAINER=true
+ ;;
-i|--no-direct)
DIRECT=false
;;
@@ -348,6 +360,13 @@ echo "GDB Commands : $$CMD_FILE"
echo "Env vars : $$ENVVARS"
echo
+if [ "$$CONTAINER" == true ]
+then
+# Use testrun.sh to start the test case with WAIT_FOR_DEBUGGER=1, then
+# automatically attach GDB to it.
+WAIT_FOR_DEBUGGER=1 $(common-objpfx)testrun.sh --tool=container $${TESTCASE} &
+gdb -x $${TESTCASE}.gdb
+else
# Start the test case debugging in two steps:
# 1. the following command invokes gdb to run the loader;
# 2. the commands file tells the loader to run the test case.
@@ -355,6 +374,7 @@ gdb -q \
-x $${CMD_FILE} \
-d $${SOURCE_DIR} \
$${BUILD_DIR}/elf/ld.so
+fi
endef
# This is another handy script for debugging dynamically linked program