[PATCH][gdb/testsuite] Capture many-headers.exp progress and output in gdb.log

[PATCH][gdb/testsuite] Capture many-headers.exp progress and output in gdb.log

[Tom de Vries]

Hi,

When running test-case gdb.base/many-headers.exp, we have test output on
stdout/stderr:
...
Running src/gdb/testsuite/gdb.base/many-headers.exp ...
[New LWP 759]
Core was generated by `outputs/gdb.base/many-headers/many'.
Program terminated with signal SIGSEGV, Segmentation fault.
\#0  0x0000000000400688 in ?? ()

                === gdb Summary ===

nr of expected passes            1
...

Furthermore, the only trace in gdb.log that we have of the gdb command issued
is:
...
PASS: gdb.base/many-headers.exp: read core file
...

Fix this by echoing the gdb command in gdb.log, and capturing the
command output and pasting it into gdb.log:
...
( ulimit -s 4096; \
  gdb -nw -nx -data-directory data-directory -batch -core=many-headers.core )
[New LWP 1542]
Core was generated by `many'.
Program terminated with signal SIGSEGV, Segmentation fault.
\#0  0x0000000000400688 in ?? ()
PASS: gdb.base/many-headers.exp: read core file
...

Tested on x86_64-linux.

OK for trunk?

Thanks,
- Tom

[gdb/testsuite] Capture many-headers.exp progress and output in gdb.log

gdb/testsuite/ChangeLog:

2020-02-06  Tom de Vries  <tdevries@suse.de>

	* gdb.base/many-headers.exp: Echo gdb command to gdb.log.  Capture gdb
	command output and paste it into gdb.log.  If any, paste catch message
	to gdb.log.

---
 gdb/testsuite/gdb.base/many-headers.exp | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/gdb/testsuite/gdb.base/many-headers.exp b/gdb/testsuite/gdb.base/many-headers.exp
index dc7f8675b8..3c2a4dc91b 100644
--- a/gdb/testsuite/gdb.base/many-headers.exp
+++ b/gdb/testsuite/gdb.base/many-headers.exp
@@ -51,17 +51,24 @@ if { "$msg" != "" } {
     return -1
 }
 
+set cmd \
+    [concat \
+	 "(" \
+	 "ulimit -s $stack_limit;" \
+	 "$GDB $INTERNAL_GDBFLAGS $GDBFLAGS -batch -core=$corefile" \
+	 ")"]
+verbose -log $cmd
+
 # Run gdb with stack limit
 catch {
-    system [concat \
-		"(" \
-		"ulimit -s $stack_limit;" \
-		"$GDB $INTERNAL_GDBFLAGS $GDBFLAGS -batch -core=$corefile" \
-		")"]
+    system "$cmd > OUTPUT 2>&1"
 } msg
+verbose -log [exec cat OUTPUT]
+
 set test "read core file"
 if { "$msg" == "" } {
     pass "$test"
 } else {
+    verbose -log $msg
     fail "$test"
 }

Re: [PATCH][gdb/testsuite] Capture many-headers.exp progress and output in gdb.log

[Simon Marchi]

On 2020-02-06 3:52 a.m., Tom de Vries wrote:
> Hi,
> 
> When running test-case gdb.base/many-headers.exp, we have test output on
> stdout/stderr:
> ...
> Running src/gdb/testsuite/gdb.base/many-headers.exp ...
> [New LWP 759]
> Core was generated by `outputs/gdb.base/many-headers/many'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> \#0  0x0000000000400688 in ?? ()
> 
>                 === gdb Summary ===
> 
> nr of expected passes            1
> ...
> 
> Furthermore, the only trace in gdb.log that we have of the gdb command issued
> is:
> ...
> PASS: gdb.base/many-headers.exp: read core file
> ...
> 
> Fix this by echoing the gdb command in gdb.log, and capturing the
> command output and pasting it into gdb.log:
> ...
> ( ulimit -s 4096; \
>   gdb -nw -nx -data-directory data-directory -batch -core=many-headers.core )
> [New LWP 1542]
> Core was generated by `many'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> \#0  0x0000000000400688 in ?? ()
> PASS: gdb.base/many-headers.exp: read core file
> ...
> 
> Tested on x86_64-linux.
> 
> OK for trunk?
> 
> Thanks,
> - Tom
> 
> [gdb/testsuite] Capture many-headers.exp progress and output in gdb.log
> 
> gdb/testsuite/ChangeLog:
> 
> 2020-02-06  Tom de Vries  <tdevries@suse.de>
> 
> 	* gdb.base/many-headers.exp: Echo gdb command to gdb.log.  Capture gdb
> 	command output and paste it into gdb.log.  If any, paste catch message
> 	to gdb.log.
> 
> ---
>  gdb/testsuite/gdb.base/many-headers.exp | 17 ++++++++++++-----
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/many-headers.exp b/gdb/testsuite/gdb.base/many-headers.exp
> index dc7f8675b8..3c2a4dc91b 100644
> --- a/gdb/testsuite/gdb.base/many-headers.exp
> +++ b/gdb/testsuite/gdb.base/many-headers.exp
> @@ -51,17 +51,24 @@ if { "$msg" != "" } {
>      return -1
>  }
>  
> +set cmd \
> +    [concat \
> +	 "(" \
> +	 "ulimit -s $stack_limit;" \
> +	 "$GDB $INTERNAL_GDBFLAGS $GDBFLAGS -batch -core=$corefile" \
> +	 ")"]
> +verbose -log $cmd
> +
>  # Run gdb with stack limit
>  catch {
> -    system [concat \
> -		"(" \
> -		"ulimit -s $stack_limit;" \
> -		"$GDB $INTERNAL_GDBFLAGS $GDBFLAGS -batch -core=$corefile" \
> -		")"]
> +    system "$cmd > OUTPUT 2>&1"
>  } msg
> +verbose -log [exec cat OUTPUT]
> +
>  set test "read core file"
>  if { "$msg" == "" } {
>      pass "$test"
>  } else {
> +    verbose -log $msg
>      fail "$test"
>  }
> 

This leaves a stray OUTPUT file in the build/gdb/testsuite directory.  I am fine
with the technique used, but maybe just create some file using standard_output_file?

Simon

Re: [PATCH][gdb/testsuite] Capture many-headers.exp progress and output in gdb.log

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]

> This leaves a stray OUTPUT file in the build/gdb/testsuite directory.

Removed in updated version.

> I am fine
> with the technique used, but maybe just create some file using standard_output_file?

Done.

Thanks,
- Tom



[-- Attachment #2: 0001-gdb-testsuite-Capture-many-headers.exp-progress-and-output-in-gdb.log.patch --]
[-- Type: text/x-patch, Size: 2260 bytes --]

[gdb/testsuite] Capture many-headers.exp progress and output in gdb.log

When running test-case gdb.base/many-headers.exp, we have test output on
stdout/stderr:
...
Running src/gdb/testsuite/gdb.base/many-headers.exp ...
[New LWP 759]
Core was generated by `outputs/gdb.base/many-headers/many'.
Program terminated with signal SIGSEGV, Segmentation fault.
\#0  0x0000000000400688 in ?? ()

                === gdb Summary ===

nr of expected passes            1
...

Furthermore, the only trace in gdb.log that we have of the gdb command issued
is:
...
PASS: gdb.base/many-headers.exp: read core file
...

Fix this by echoing the gdb command in gdb.log, and capturing the
command output and pasting it into gdb.log:
...
( ulimit -s 4096; \
  gdb -nw -nx -data-directory data-directory -batch -core=many-headers.core )
[New LWP 1542]
Core was generated by `many'.
Program terminated with signal SIGSEGV, Segmentation fault.
\#0  0x0000000000400688 in ?? ()
PASS: gdb.base/many-headers.exp: read core file
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-02-06  Tom de Vries  <tdevries@suse.de>

	* gdb.base/many-headers.exp: Echo gdb command to gdb.log.  Capture gdb
	command output and paste it into gdb.log.  If any, paste catch message
	to gdb.log.

---
 gdb/testsuite/gdb.base/many-headers.exp | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/gdb/testsuite/gdb.base/many-headers.exp b/gdb/testsuite/gdb.base/many-headers.exp
index dc7f8675b8..eb177d1d82 100644
--- a/gdb/testsuite/gdb.base/many-headers.exp
+++ b/gdb/testsuite/gdb.base/many-headers.exp
@@ -51,17 +51,26 @@ if { "$msg" != "" } {
     return -1
 }
 
+set cmd \
+    [concat \
+	 "(" \
+	 "ulimit -s $stack_limit;" \
+	 "$GDB $INTERNAL_GDBFLAGS $GDBFLAGS -batch -core=$corefile" \
+	 ")"]
+verbose -log $cmd
+
 # Run gdb with stack limit
+set output [standard_output_file OUTPUT]
 catch {
-    system [concat \
-		"(" \
-		"ulimit -s $stack_limit;" \
-		"$GDB $INTERNAL_GDBFLAGS $GDBFLAGS -batch -core=$corefile" \
-		")"]
+    system "$cmd > $output 2>&1"
 } msg
+verbose -log [exec cat $output]
+file delete $output
+
 set test "read core file"
 if { "$msg" == "" } {
     pass "$test"
 } else {
+    verbose -log $msg
     fail "$test"
 }

Re: [PATCH][gdb/testsuite] Capture many-headers.exp progress and output in gdb.log

[Simon Marchi]

On 2020-02-09 7:07 a.m., Tom de Vries wrote:
>> This leaves a stray OUTPUT file in the build/gdb/testsuite directory.
> 
> Removed in updated version.
> 
>> I am fine
>> with the technique used, but maybe just create some file using standard_output_file?
> 
> Done.
> 
> Thanks,
> - Tom
> 
> 

Thanks, that LGTM.

Simon