[PATCH][gdb/testsuite] Fix corefile-buildid.exp with check-read1

[PATCH][gdb/testsuite] Fix corefile-buildid.exp with check-read1

[Tom de Vries]

Hi,

When running gdb.base/corefile-buildid.exp using check-read1, I run into:
...
FAIL: gdb.base/corefile-buildid.exp: shared: info files (timeout)
FAIL: gdb.base/corefile-buildid.exp: symlink shared: info files (timeout)
FAIL: gdb.base/corefile-buildid.exp: shared sepdebug: info files (timeout)
FAIL: gdb.base/corefile-buildid.exp: symlink shared sepdebug: info files \
  (timeout)
...

This is caused by attempting to match the output of an "info files" command
using a single gdb_test in check_exec_file.

Fix this by doing line-by-line matching in check_exec_file.

Tested on x86_64-linux, using make targets check and check-read1.

OK for trunk?

Thanks,
- Tom

[gdb/testsuite] Fix corefile-buildid.exp with check-read1

gdb/testsuite/ChangeLog:

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

	* gdb.base/corefile-buildid.exp (check_exec_file): Match info files
	output line-by-line.

---
 gdb/testsuite/gdb.base/corefile-buildid.exp | 49 ++++++++++++++++++++++++++++-
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/corefile-buildid.exp b/gdb/testsuite/gdb.base/corefile-buildid.exp
index 158cbb6dc6..b9844ee354 100644
--- a/gdb/testsuite/gdb.base/corefile-buildid.exp
+++ b/gdb/testsuite/gdb.base/corefile-buildid.exp
@@ -108,8 +108,55 @@ proc append_debug_dir {debugdir} {
 # FILE.
 
 proc check_exec_file {file} {
+    global gdb_prompt
     send_log "expecting exec file \"$file\"\n"
-    gdb_test "info files" "Local exec file:\[\r\n\t\ \]+`[string_to_regexp $file]'.*"
+
+    # Get line with "Local exec file:".
+    set ok 0
+    gdb_test_multiple "info files" "" {
+	-re "^Local exec file:\r\n" {
+	    set test_name $gdb_test_name
+	    set ok 1
+	}
+	-re "^$gdb_prompt $" {
+	    fail $gdb_test_name
+	}
+	-re "^\[^\r\n\]*\r\n" {
+	    exp_continue
+	}
+    }
+
+    if { $ok == 0 } {
+	return
+    }
+
+    # Get subsequent line with $file.
+    set ok 0
+    gdb_test_multiple "" $test_name {
+	-re "^\[\t\ \]+`[string_to_regexp $file]'\[^\r\n\]*\r\n" {
+	    set ok 1
+	}
+	-re "^$gdb_prompt $" {
+	    fail $gdb_test_name
+	}
+	-re "^\[^\r\n\]*\r\n" {
+	    exp_continue
+	}
+    }
+
+    if { $ok == 0 } {
+	return
+    }
+
+    # Skip till prompt.
+    gdb_test_multiple "" $test_name {
+	-re "^$gdb_prompt $" {
+	    pass $gdb_test_name
+	}
+	-re "^\[^\r\n\]*\r\n" {
+	    exp_continue
+	}
+    }
 }
 
 # Test whether gdb can find an exec file from a core file's build-id.

Re: [PATCH][gdb/testsuite] Fix corefile-buildid.exp with check-read1

[Pedro Alves]

On 2/19/20 5:40 PM, Tom de Vries wrote:
> Hi,
> 
> When running gdb.base/corefile-buildid.exp using check-read1, I run into:
> ...
> FAIL: gdb.base/corefile-buildid.exp: shared: info files (timeout)
> FAIL: gdb.base/corefile-buildid.exp: symlink shared: info files (timeout)
> FAIL: gdb.base/corefile-buildid.exp: shared sepdebug: info files (timeout)
> FAIL: gdb.base/corefile-buildid.exp: symlink shared sepdebug: info files \
>   (timeout)
> ...
> 
> This is caused by attempting to match the output of an "info files" command
> using a single gdb_test in check_exec_file.
> 
> Fix this by doing line-by-line matching in check_exec_file.
> 
> Tested on x86_64-linux, using make targets check and check-read1.
> 
> OK for trunk?

OK.

If this pattern appears in more places it may be worth it to
think about some abstraction to make it easier to write.
Like e.g., a new "-lbl" (line-by-line) option switch to
gdb_test_multiple that auto-appends the "match one line" regexp.

Thanks,
Pedro Alves

[RFC][gdb/testsuite] Handle -line and -non-empty-line in gdb_test_multiple

[Tom de Vries]

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

[ was: Re: [PATCH][gdb/testsuite] Fix corefile-buildid.exp with
check-read1 ]
On 19-02-2020 21:09, Pedro Alves wrote:
> On 2/19/20 5:40 PM, Tom de Vries wrote:
>> Hi,
>>
>> When running gdb.base/corefile-buildid.exp using check-read1, I run into:
>> ...
>> FAIL: gdb.base/corefile-buildid.exp: shared: info files (timeout)
>> FAIL: gdb.base/corefile-buildid.exp: symlink shared: info files (timeout)
>> FAIL: gdb.base/corefile-buildid.exp: shared sepdebug: info files (timeout)
>> FAIL: gdb.base/corefile-buildid.exp: symlink shared sepdebug: info files \
>>   (timeout)
>> ...
>>
>> This is caused by attempting to match the output of an "info files" command
>> using a single gdb_test in check_exec_file.
>>
>> Fix this by doing line-by-line matching in check_exec_file.
>>
>> Tested on x86_64-linux, using make targets check and check-read1.
>>
>> OK for trunk?
> 
> OK.
> 

Committed.

> If this pattern appears in more places it may be worth it to
> think about some abstraction to make it easier to write.
> Like e.g., a new "-lbl" (line-by-line) option switch to
> gdb_test_multiple that auto-appends the "match one line" regexp.

How about this?

Thanks,
- Tom


[-- Attachment #2: 0001-gdb-testsuite-Handle-line-and-non-empty-line-in-gdb_test_multiple.patch --]
[-- Type: text/x-patch, Size: 4641 bytes --]

[gdb/testsuite] Handle -line and -non-empty-line in gdb_test_multiple

Add predefined regexps in gdb_test_multiple:
* -line
  meaning -re "^\[^\r\n\]*\r\n"
* -non-empty-line
  meaning -re "^\[^\r\n\]+\r\n"

Reg-tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

	* lib/gdb.exp (gdb_test_multiple): Handle -line and -non-empty-line.
	* gdb.base/corefile-buildid.exp: Use -line.
	* gdb.base/solib-corrupted.exp: Same.
	* gdb.arch/mips-fpregset-core.exp: Use -non-empty-line.
	* gdb.base/auxv.exp: Same.
	* gdb.base/callfuncs.exp: Same.

---
 gdb/testsuite/gdb.arch/mips-fpregset-core.exp |  2 +-
 gdb/testsuite/gdb.base/auxv.exp               |  2 +-
 gdb/testsuite/gdb.base/callfuncs.exp          |  2 +-
 gdb/testsuite/gdb.base/corefile-buildid.exp   |  6 +++---
 gdb/testsuite/gdb.base/solib-corrupted.exp    |  2 +-
 gdb/testsuite/lib/gdb.exp                     | 19 +++++++++++++++++++
 6 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/gdb/testsuite/gdb.arch/mips-fpregset-core.exp b/gdb/testsuite/gdb.arch/mips-fpregset-core.exp
index 3a199f8eba..fecc9f00e3 100644
--- a/gdb/testsuite/gdb.arch/mips-fpregset-core.exp
+++ b/gdb/testsuite/gdb.arch/mips-fpregset-core.exp
@@ -55,7 +55,7 @@ proc mips_fpregset_core_fetch_float_registers { test } {
 	-re "$gdb_prompt $" {
 	    incr bad
 	}
-	-re "^\[^\r\n\]+\r\n" {
+	-non-empty-line {
 	    if { !$bad } {
 		warning "Unrecognized output: $expect_out(0,string)"
 		set bad 1
diff --git a/gdb/testsuite/gdb.base/auxv.exp b/gdb/testsuite/gdb.base/auxv.exp
index 9834a3564d..5a54599fc1 100644
--- a/gdb/testsuite/gdb.base/auxv.exp
+++ b/gdb/testsuite/gdb.base/auxv.exp
@@ -100,7 +100,7 @@ proc fetch_auxv {test} {
 	-re "$gdb_prompt $" {
 	    incr bad
 	}
-	-re "^\[^\r\n\]+\r\n" {
+	-non-empty-line {
 	    if {!$bad} {
 		warning "Unrecognized output: $expect_out(0,string)"
 		set bad 1
diff --git a/gdb/testsuite/gdb.base/callfuncs.exp b/gdb/testsuite/gdb.base/callfuncs.exp
index 5d98541745..33740922e7 100644
--- a/gdb/testsuite/gdb.base/callfuncs.exp
+++ b/gdb/testsuite/gdb.base/callfuncs.exp
@@ -302,7 +302,7 @@ proc fetch_all_registers {test} {
 	-re "$gdb_prompt $" {
 	    incr bad
 	}
-	-re "^\[^\r\n\]+\r\n" {
+	-non-empty-line {
 	    if {!$bad} {
 		warning "Unrecognized output: $expect_out(0,string)"
 		set bad 1
diff --git a/gdb/testsuite/gdb.base/corefile-buildid.exp b/gdb/testsuite/gdb.base/corefile-buildid.exp
index b9844ee354..43e44443d5 100644
--- a/gdb/testsuite/gdb.base/corefile-buildid.exp
+++ b/gdb/testsuite/gdb.base/corefile-buildid.exp
@@ -121,7 +121,7 @@ proc check_exec_file {file} {
 	-re "^$gdb_prompt $" {
 	    fail $gdb_test_name
 	}
-	-re "^\[^\r\n\]*\r\n" {
+	-line {
 	    exp_continue
 	}
     }
@@ -139,7 +139,7 @@ proc check_exec_file {file} {
 	-re "^$gdb_prompt $" {
 	    fail $gdb_test_name
 	}
-	-re "^\[^\r\n\]*\r\n" {
+	-line {
 	    exp_continue
 	}
     }
@@ -153,7 +153,7 @@ proc check_exec_file {file} {
 	-re "^$gdb_prompt $" {
 	    pass $gdb_test_name
 	}
-	-re "^\[^\r\n\]*\r\n" {
+	-line {
 	    exp_continue
 	}
     }
diff --git a/gdb/testsuite/gdb.base/solib-corrupted.exp b/gdb/testsuite/gdb.base/solib-corrupted.exp
index 5ee943cae1..10adb9a0ba 100644
--- a/gdb/testsuite/gdb.base/solib-corrupted.exp
+++ b/gdb/testsuite/gdb.base/solib-corrupted.exp
@@ -50,7 +50,7 @@ gdb_test_multiple $test $test {
 	}
 	exp_continue
     }
-    -re "^\[^\r\n\]*\r\n" {
+    -line {
 	exp_continue
     }
     -re "^$gdb_prompt $" {
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index d5e2295703..7fd783e786 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -792,6 +792,13 @@ proc gdb_internal_error_resync {} {
 #	}
 #    }
 #
+# In EXPECT_ARGUMENTS, instead of -re "bla" we can use a few predefined
+# regexps:
+# * -line
+#    meaning -re "^\[^\r\n\]*\r\n"
+# * -non-empty-line
+#    meaning -re "^\[^\r\n\]+\r\n"
+#
 proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
     global verbose use_gdb_stub
     global gdb_prompt pagination_prompt
@@ -867,6 +874,18 @@ proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
 	    lappend $current_list $item
 	    continue
 	}
+	if { $item == "-line" } {
+	    lappend $current_list -re
+	    lappend $current_list "^\[^\r\n\]*\r\n"	
+	    set expecting_action 1
+	    continue
+	}
+	if { $item == "-non-empty-line" } {
+	    lappend $current_list -re
+	    lappend $current_list "^\[^\r\n\]+\r\n"
+	    set expecting_action 1
+	    continue
+	}
 	if { $item == "-early" } {
 	    set current_list "early_processed_code"
 	    continue

Re: [RFC][gdb/testsuite] Handle -line and -non-empty-line in gdb_test_multiple

[Pedro Alves]

On 2/19/20 9:30 PM, Tom de Vries wrote:
> [ was: Re: [PATCH][gdb/testsuite] Fix corefile-buildid.exp with

> Committed.
> 
>> If this pattern appears in more places it may be worth it to
>> think about some abstraction to make it easier to write.
>> Like e.g., a new "-lbl" (line-by-line) option switch to
>> gdb_test_multiple that auto-appends the "match one line" regexp.
> 
> How about this?

Oh, by "pattern", I meant the design pattern, the higher-level
thing of expecting a string while at the same time consuming
input a line at a time.  Something like:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git c/gdb/testsuite/lib/gdb.exp w/gdb/testsuite/lib/gdb.exp
index d8ebddf63ce..6eaebc7710d 100644
--- c/gdb/testsuite/lib/gdb.exp
+++ w/gdb/testsuite/lib/gdb.exp
@@ -858,6 +858,7 @@ proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
     set expecting_action 0
     set expecting_arg 0
     set wrap_pattern 0
+    set line_by_line 0
     foreach item $user_code subst_item $subst_code {
        if { $item == "-n" || $item == "-notransfer" || $item == "-nocase" } {
            lappend $current_list $item
@@ -880,6 +881,10 @@ proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
            set wrap_pattern 1
            continue
        }
+       if {$item == "-lbl"} {
+           set line_by_line 1
+           continue
+       }
        if { $expecting_arg } {
            set expecting_arg 0
            lappend $current_list $subst_item
@@ -1070,6 +1075,14 @@ proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
        }
     }
 
+    if {$line_by_line} {
+       append code {
+           -re "^\[^\r\n\]*\r\n" {
+               exp_continue
+           }
+       }
+    }
+
     # Now patterns that apply to any spawn id specified.
     append code {
        -i $any_spawn_id
~~~~~~~~~~~~~~~~~~~~~~~~~~~

That should mean we could drop the $gdb_prompt matches too.
But maybe a new gdb_test_lbl procedure that wraps gdb_test_multiple
would be preferred.

The way you have it doesn't look very different from
creating a couple globals, like:

 set line_re "^\[^\r\n\]*\r\n"
 set non_empty_line_re "^\[^\r\n\]+\r\n"

and the using them like:

 -re "$line_re" {

Maybe removing the leading "^" anchor from the variables
would make them usable in more places.

Anyway, I don't object to your patch if you like it.  It just
wasn't what I was suggesting.

Thanks,
Pedro Alves

[RFC][gdb/testsuite] Add -lbl option in gdb_test_multiple

[Tom de Vries]

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

[ was: Re: [RFC][gdb/testsuite] Handle -line and -non-empty-line in
gdb_test_multiple ]
On 20-02-2020 14:27, Pedro Alves wrote:
> On 2/19/20 9:30 PM, Tom de Vries wrote:
>> [ was: Re: [PATCH][gdb/testsuite] Fix corefile-buildid.exp with
> 
>> Committed.
>>
>>> If this pattern appears in more places it may be worth it to
>>> think about some abstraction to make it easier to write.
>>> Like e.g., a new "-lbl" (line-by-line) option switch to
>>> gdb_test_multiple that auto-appends the "match one line" regexp.
>>
>> How about this?
> 
> Oh, by "pattern", I meant the design pattern, the higher-level
> thing of expecting a string while at the same time consuming
> input a line at a time.

Right, I sort of got that, but went for a simpler form of abstraction.

> Something like:
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> diff --git c/gdb/testsuite/lib/gdb.exp w/gdb/testsuite/lib/gdb.exp
> index d8ebddf63ce..6eaebc7710d 100644
> --- c/gdb/testsuite/lib/gdb.exp
> +++ w/gdb/testsuite/lib/gdb.exp
> @@ -858,6 +858,7 @@ proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
>      set expecting_action 0
>      set expecting_arg 0
>      set wrap_pattern 0
> +    set line_by_line 0
>      foreach item $user_code subst_item $subst_code {
>         if { $item == "-n" || $item == "-notransfer" || $item == "-nocase" } {
>             lappend $current_list $item
> @@ -880,6 +881,10 @@ proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
>             set wrap_pattern 1
>             continue
>         }
> +       if {$item == "-lbl"} {
> +           set line_by_line 1
> +           continue
> +       }
>         if { $expecting_arg } {
>             set expecting_arg 0
>             lappend $current_list $subst_item
> @@ -1070,6 +1075,14 @@ proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
>         }
>      }
>  
> +    if {$line_by_line} {
> +       append code {
> +           -re "^\[^\r\n\]*\r\n" {
> +               exp_continue
> +           }
> +       }
> +    }
> +
>      # Now patterns that apply to any spawn id specified.
>      append code {
>         -i $any_spawn_id
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> That should mean we could drop the $gdb_prompt matches too.
> But maybe a new gdb_test_lbl procedure that wraps gdb_test_multiple
> would be preferred.
> 

I think we don't want to integrate -lbl in the user_code parsing, because:
...
gdb_test_multiple "command" "testname" {
	-re "bla" {
	}
	-lbl
}
...
and:
...
gdb_test_multiple "command" "testname" {
	-lbl
	-re "bla" {
	}
}
...
will have the same effect, which is likely to cause confusion.

So I've added it as option to gdb_test_multiple. [ Which caused me to
rewrite the optional $prompt_regexp argument to -prompt $prompt_regexp. ]

I had to rewrite the -lbl regexp to "\r\n" at start-of-line rather than
end-of-line, because it didn't work well otherwise with the implicit
regexps that are listed before it.  Consequently, I had to rewrite the
regexps in corefile-buildid.exp in a similar way.

> The way you have it doesn't look very different from
> creating a couple globals, like:
> 
>  set line_re "^\[^\r\n\]*\r\n"
>  set non_empty_line_re "^\[^\r\n\]+\r\n"
> 
> and the using them like:
> 
>  -re "$line_re" {
> 
> Maybe removing the leading "^" anchor from the variables
> would make them usable in more places.
> 

Ack, that all makes sense.

> Anyway, I don't object to your patch if you like it.  It just
> wasn't what I was suggesting.

I'll drop that one for now, maybe rewrite it at some point to use some
global variables instead.

So how about this -lbl implementation? Any comments (other than missing
documentation in gdb_test_multiple proc header)?

Reg-tested on x86_64-linux.

Tested corefile-buildid.exp with check-read1.

Thanks,
- Tom


[-- Attachment #2: 0001-gdb-testsuite-Add-lbl-option-in-gdb_test_multiple.patch --]
[-- Type: text/x-patch, Size: 5027 bytes --]

[gdb/testsuite] Add -lbl option in gdb_test_multiple

Add gdb_test_multiple option -lbl, that adds a regexp after the user code that
reads one line, and discards it:
...
           -re "\r\n\[^\r\n\]*(?=\r\n)" {
               exp_continue
           }
...

In order to be able to write:
...
gdb_test_multiple "command" "testname" {
  ...
} -lbl
...
as opposed to having to insert the "" for the prompt_regexp arguments:
...
gdb_test_multiple "command" "testname" {
  ...
} "" -lbl
...
rewrite the promp_regexp argument usage into:
...
gdb_test_multiple "command" "testname" {
  ...
} -prompt $prompt_regexp
...

gdb/testsuite/ChangeLog:

2020-02-2120  Pedro Alves  <palves@redhat.com>
	      Tom de Vries  <tdevries@suse.de>

	* lib/gdb.exp (gdb_test_multiple): Handle prompt_regexp option using
	-prompt prefix.  Add -lbl option.
	(skip_python_tests_prompt, skip_libstdcxx_probe_tests_prompt)
	(gdb_is_target_1): Add -prompt prefix.
	* gdb.base/corefile-buildid.exp: Use -lbl option.  Rewrite regexps to
	have "\r\n" at start-of-line, instead of at end-of-line.

---
 gdb/testsuite/gdb.base/corefile-buildid.exp | 27 ++++++--------------------
 gdb/testsuite/lib/gdb.exp                   | 30 ++++++++++++++++++++++++-----
 2 files changed, 31 insertions(+), 26 deletions(-)

diff --git a/gdb/testsuite/gdb.base/corefile-buildid.exp b/gdb/testsuite/gdb.base/corefile-buildid.exp
index b9844ee354..b91550bc82 100644
--- a/gdb/testsuite/gdb.base/corefile-buildid.exp
+++ b/gdb/testsuite/gdb.base/corefile-buildid.exp
@@ -114,17 +114,11 @@ proc check_exec_file {file} {
     # Get line with "Local exec file:".
     set ok 0
     gdb_test_multiple "info files" "" {
-	-re "^Local exec file:\r\n" {
+	-re "\r\nLocal exec file:" {
 	    set test_name $gdb_test_name
 	    set ok 1
 	}
-	-re "^$gdb_prompt $" {
-	    fail $gdb_test_name
-	}
-	-re "^\[^\r\n\]*\r\n" {
-	    exp_continue
-	}
-    }
+    } -lbl
 
     if { $ok == 0 } {
 	return
@@ -133,16 +127,10 @@ proc check_exec_file {file} {
     # Get subsequent line with $file.
     set ok 0
     gdb_test_multiple "" $test_name {
-	-re "^\[\t\ \]+`[string_to_regexp $file]'\[^\r\n\]*\r\n" {
+	-re "\r\n\[\t\ \]+`[string_to_regexp $file]'\[^\r\n\]*" {
 	    set ok 1
 	}
-	-re "^$gdb_prompt $" {
-	    fail $gdb_test_name
-	}
-	-re "^\[^\r\n\]*\r\n" {
-	    exp_continue
-	}
-    }
+    } -lbl
 
     if { $ok == 0 } {
 	return
@@ -150,13 +138,10 @@ proc check_exec_file {file} {
 
     # Skip till prompt.
     gdb_test_multiple "" $test_name {
-	-re "^$gdb_prompt $" {
+	-re "\r\n$gdb_prompt $" {
 	    pass $gdb_test_name
 	}
-	-re "^\[^\r\n\]*\r\n" {
-	    exp_continue
-	}
-    }
+    } -lbl
 }
 
 # Test whether gdb can find an exec file from a core file's build-id.
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 81518b9646..caa64f36f1 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -792,7 +792,7 @@ proc gdb_internal_error_resync {} {
 #	}
 #    }
 #
-proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
+proc gdb_test_multiple { command message user_code args } {
     global verbose use_gdb_stub
     global gdb_prompt pagination_prompt
     global GDB
@@ -802,6 +802,18 @@ proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
     upvar expect_out expect_out
     global any_spawn_id
 
+    set line_by_line 0
+    set prompt_regexp ""
+    for {set i 0} {$i < [llength $args]} {incr i} {
+	set opt [lindex $args $i]
+	if { $opt  == "-prompt" } {
+	    incr i
+	    set prompt_regexp [lindex $args $i]
+	} elseif { $opt == "-lbl" } {
+	    set line_by_line 1
+	}
+    }
+
     if { "$prompt_regexp" == "" } {
 	set prompt_regexp "$gdb_prompt $"
     }
@@ -1070,6 +1082,14 @@ proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
 	}
     }
 
+    if {$line_by_line} {
+       append code {
+           -re "\r\n\[^\r\n\]*(?=\r\n)" {
+               exp_continue
+           }
+       }
+    }
+
     # Now patterns that apply to any spawn id specified.
     append code {
 	-i $any_spawn_id
@@ -2005,7 +2025,7 @@ proc skip_python_tests_prompt { prompt_regexp } {
 	    return 1
 	}
 	-re "$prompt_regexp" {}
-    } "$prompt_regexp"
+    } -prompt "$prompt_regexp"
 
     gdb_test_multiple "python print (sys.version_info\[0\])" "check if python 3" {
 	-re "3.*$prompt_regexp" {
@@ -2014,7 +2034,7 @@ proc skip_python_tests_prompt { prompt_regexp } {
 	-re ".*$prompt_regexp" {
             set gdb_py_is_py3k 0
         }
-    } "$prompt_regexp"
+    } -prompt "$prompt_regexp"
 
     return 0
 }
@@ -3274,7 +3294,7 @@ proc skip_libstdcxx_probe_tests_prompt { prompt_regexp } {
 	}
 	-re "\r\n$prompt_regexp" {
 	}
-    } "$prompt_regexp"
+    } -prompt "$prompt_regexp"
     set skip [expr !$supported]
     return $skip
 }
@@ -3322,7 +3342,7 @@ proc gdb_is_target_1 { target_name target_stack_regexp prompt_regexp } {
 	-re "$prompt_regexp" {
 	    pass $test
 	}
-    } "$prompt_regexp"
+    } -prompt "$prompt_regexp"
     return 0
 }
 

Re: [RFC][gdb/testsuite] Add -lbl option in gdb_test_multiple

[Pedro Alves]

On 2/21/20 3:35 PM, Tom de Vries wrote:

> I think we don't want to integrate -lbl in the user_code parsing, because:
> ...
> gdb_test_multiple "command" "testname" {
> 	-re "bla" {
> 	}
> 	-lbl
> }
> ...
> and:
> ...
> gdb_test_multiple "command" "testname" {
> 	-lbl
> 	-re "bla" {
> 	}
> }
> ...
> will have the same effect, which is likely to cause confusion.

Well:

 gdb_test_multiple "command" "testname" {
	-re "bar" {
	}
	-timeout 60
 }

and:

 gdb_test_multiple "command" "testname" {
	-timeout 60
	-re "bla" {
	}
 }

also have the same effect.  So there's precedent and it goes
all the way back to expect.

> [gdb/testsuite] Add -lbl option in gdb_test_multiple
> 
> Add gdb_test_multiple option -lbl, that adds a regexp after the user code that
> reads one line, and discards it:
> ...
>            -re "\r\n\[^\r\n\]*(?=\r\n)" {
>                exp_continue
>            }
> ...
> 
> In order to be able to write:
> ...
> gdb_test_multiple "command" "testname" {
>   ...
> } -lbl
> ...
> as opposed to having to insert the "" for the prompt_regexp arguments:
> ...
> gdb_test_multiple "command" "testname" {
>   ...
> } "" -lbl
> ...
> rewrite the promp_regexp argument usage into:
> ...
> gdb_test_multiple "command" "testname" {
>   ...
> } -prompt $prompt_regexp
> ...

Honestly, to me, this:

 gdb_test_multiple "command" "testname" {
   ...
 } -lbl -prompt $prompt_regexp

looks a bit harder to grok than:

 gdb_test_multiple "command" "testname" {
   -lbl
   -prompt $prompt_regexp
   ...
 }

... because those options appear at the end, after the regexes.

Alternatively, if you don't like the -lbl within the {} block, and if
we're going to use "-" options, how about supporting them before
the {} user code block, so that the user code block is always
at the end?  Like:

 gdb_test_multiple "command" "testname" -lbl {
   ...
 }

 gdb_test_multiple "command" "testname" -prompt $prompt_regexp {
   ...
 }

That should be doable with:

 -proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
 +proc gdb_test_multiple { command message args } {

and then walking the $args list, processing "-" arguments, and interpreting
the first non-"-" argument as the user code block (and erroring out if there
are more arguments).  I think the gdb_test_multiple code would look quite similar
to your patch, except that the user_code parameter would no longer be a parameter,
instead it would be a local variable set to the first non-"-" element of $args.

Thanks,
Pedro Alves

Re: [RFC][gdb/testsuite] Add -lbl option in gdb_test_multiple

[Tom de Vries]

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

On 27-02-2020 17:02, Pedro Alves wrote:
> On 2/21/20 3:35 PM, Tom de Vries wrote:
> 
>> I think we don't want to integrate -lbl in the user_code parsing, because:
>> ...
>> gdb_test_multiple "command" "testname" {
>> 	-re "bla" {
>> 	}
>> 	-lbl
>> }
>> ...
>> and:
>> ...
>> gdb_test_multiple "command" "testname" {
>> 	-lbl
>> 	-re "bla" {
>> 	}
>> }
>> ...
>> will have the same effect, which is likely to cause confusion.
> 
> Well:
> 
>  gdb_test_multiple "command" "testname" {
> 	-re "bar" {
> 	}
> 	-timeout 60
>  }
> 
> and:
> 
>  gdb_test_multiple "command" "testname" {
> 	-timeout 60
> 	-re "bla" {
> 	}
>  }
> 
> also have the same effect.  So there's precedent and it goes
> all the way back to expect.
> 

Hm, I see.

>> [gdb/testsuite] Add -lbl option in gdb_test_multiple
>>
>> Add gdb_test_multiple option -lbl, that adds a regexp after the user code that
>> reads one line, and discards it:
>> ...
>>            -re "\r\n\[^\r\n\]*(?=\r\n)" {
>>                exp_continue
>>            }
>> ...
>>
>> In order to be able to write:
>> ...
>> gdb_test_multiple "command" "testname" {
>>   ...
>> } -lbl
>> ...
>> as opposed to having to insert the "" for the prompt_regexp arguments:
>> ...
>> gdb_test_multiple "command" "testname" {
>>   ...
>> } "" -lbl
>> ...
>> rewrite the promp_regexp argument usage into:
>> ...
>> gdb_test_multiple "command" "testname" {
>>   ...
>> } -prompt $prompt_regexp
>> ...
> 
> Honestly, to me, this:
> 
>  gdb_test_multiple "command" "testname" {
>    ...
>  } -lbl -prompt $prompt_regexp
> 
> looks a bit harder to grok than:
> 
>  gdb_test_multiple "command" "testname" {
>    -lbl
>    -prompt $prompt_regexp
>    ...
>  }
> 
> ... because those options appear at the end, after the regexes.
> 
> Alternatively, if you don't like the -lbl within the {} block, and if
> we're going to use "-" options, how about supporting them before
> the {} user code block, so that the user code block is always
> at the end?  Like:
> 
>  gdb_test_multiple "command" "testname" -lbl {
>    ...
>  }
> 
>  gdb_test_multiple "command" "testname" -prompt $prompt_regexp {
>    ...
>  }
> 
> That should be doable with:
> 
>  -proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
>  +proc gdb_test_multiple { command message args } {
> 
> and then walking the $args list, processing "-" arguments, and interpreting
> the first non-"-" argument as the user code block (and erroring out if there
> are more arguments).  I think the gdb_test_multiple code would look quite similar
> to your patch, except that the user_code parameter would no longer be a parameter,
> instead it would be a local variable set to the first non-"-" element of $args.

Yes, I like that suggestion.

Implemented and attached below.

OK for trunk.

Thanks,
- Tom

[-- Attachment #2: 0001-gdb-testsuite-Add-lbl-option-in-gdb_test_multiple.patch --]
[-- Type: text/x-patch, Size: 8053 bytes --]

[gdb/testsuite] Add -lbl option in gdb_test_multiple

Add gdb_test_multiple option -lbl, that adds a regexp after the user code that
reads one line, and discards it:
...
           -re "\r\n\[^\r\n\]*(?=\r\n)" {
               exp_continue
           }
...

In order to be able to write:
...
gdb_test_multiple "command" "testname" -lbl {
  ...
}
...
rewrite the promp_regexp argument usage into the similar:
...
gdb_test_multiple "command" "testname" -prompt $prompt_regexp {
  ...
}
...

Build and reg-tested on x86_64-linux.

Tested gdb.base/corefile-buildid.exp with both make targets check and
check-read1.

gdb/testsuite/ChangeLog:

2020-02-2120  Pedro Alves  <palves@redhat.com>
	      Tom de Vries  <tdevries@suse.de>

	* lib/gdb.exp (gdb_test_multiple): Handle prompt_regexp option using
	-prompt prefix, before user_code argument.  Add -lbl option likewise.
	(skip_python_tests_prompt, skip_libstdcxx_probe_tests_prompt)
	(gdb_is_target_1): Add -prompt prefix and move to before user_code
	argument.
	* gdb.base/corefile-buildid.exp: Use -lbl option.  Rewrite regexps to
	have "\r\n" at start-of-line, instead of at end-of-line.

---
 gdb/testsuite/gdb.base/corefile-buildid.exp | 27 ++------
 gdb/testsuite/lib/gdb.exp                   | 98 +++++++++++++++++++----------
 2 files changed, 72 insertions(+), 53 deletions(-)

diff --git a/gdb/testsuite/gdb.base/corefile-buildid.exp b/gdb/testsuite/gdb.base/corefile-buildid.exp
index b9844ee354..e24562dedb 100644
--- a/gdb/testsuite/gdb.base/corefile-buildid.exp
+++ b/gdb/testsuite/gdb.base/corefile-buildid.exp
@@ -113,17 +113,11 @@ proc check_exec_file {file} {
 
     # Get line with "Local exec file:".
     set ok 0
-    gdb_test_multiple "info files" "" {
-	-re "^Local exec file:\r\n" {
+    gdb_test_multiple "info files" "" -lbl {
+	-re "\r\nLocal exec file:" {
 	    set test_name $gdb_test_name
 	    set ok 1
 	}
-	-re "^$gdb_prompt $" {
-	    fail $gdb_test_name
-	}
-	-re "^\[^\r\n\]*\r\n" {
-	    exp_continue
-	}
     }
 
     if { $ok == 0 } {
@@ -132,16 +126,10 @@ proc check_exec_file {file} {
 
     # Get subsequent line with $file.
     set ok 0
-    gdb_test_multiple "" $test_name {
-	-re "^\[\t\ \]+`[string_to_regexp $file]'\[^\r\n\]*\r\n" {
+    gdb_test_multiple "" $test_name -lbl {
+	-re "\r\n\[\t\ \]+`[string_to_regexp $file]'\[^\r\n\]*" {
 	    set ok 1
 	}
-	-re "^$gdb_prompt $" {
-	    fail $gdb_test_name
-	}
-	-re "^\[^\r\n\]*\r\n" {
-	    exp_continue
-	}
     }
 
     if { $ok == 0 } {
@@ -149,13 +137,10 @@ proc check_exec_file {file} {
     }
 
     # Skip till prompt.
-    gdb_test_multiple "" $test_name {
-	-re "^$gdb_prompt $" {
+    gdb_test_multiple "" $test_name -lbl {
+	-re "\r\n$gdb_prompt $" {
 	    pass $gdb_test_name
 	}
-	-re "^\[^\r\n\]*\r\n" {
-	    exp_continue
-	}
     }
 }
 
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 26795d0152..ab22f24436 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -698,20 +698,22 @@ proc gdb_internal_error_resync {} {
 }
 
 
-# gdb_test_multiple COMMAND MESSAGE EXPECT_ARGUMENTS PROMPT_REGEXP
+# gdb_test_multiple COMMAND MESSAGE [ -promp PROMPT_REGEXP] [ -lbl ]
+#                   EXPECT_ARGUMENTS
 # Send a command to gdb; test the result.
 #
 # COMMAND is the command to execute, send to GDB with send_gdb.  If
 #   this is the null string no command is sent.
 # MESSAGE is a message to be printed with the built-in failure patterns
 #   if one of them matches.  If MESSAGE is empty COMMAND will be used.
+# -prompt PROMPT_REGEXP specifies a regexp matching the expected prompt
+#   after the command output.  If empty, defaults to "$gdb_prompt $".
+# -lbl specifies that line-by-line matching will be used.
 # EXPECT_ARGUMENTS will be fed to expect in addition to the standard
 #   patterns.  Pattern elements will be evaluated in the caller's
 #   context; action elements will be executed in the caller's context.
 #   Unlike patterns for gdb_test, these patterns should generally include
 #   the final newline and prompt.
-# PROMPT_REGEXP is a regexp matching the expected prompt after the command
-#   output.  If empty, defaults to "$gdb_prompt $"
 #
 # Returns:
 #    1 if the test failed, according to a built-in failure pattern
@@ -791,7 +793,7 @@ proc gdb_internal_error_resync {} {
 #	}
 #    }
 #
-proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
+proc gdb_test_multiple { command message args } {
     global verbose use_gdb_stub
     global gdb_prompt pagination_prompt
     global GDB
@@ -801,6 +803,26 @@ proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
     upvar expect_out expect_out
     global any_spawn_id
 
+    set line_by_line 0
+    set prompt_regexp ""
+    for {set i 0} {$i < [llength $args]} {incr i} {
+	set arg [lindex $args $i]
+	if { $arg  == "-prompt" } {
+	    incr i
+	    set prompt_regexp [lindex $args $i]
+	} elseif { $arg == "-lbl" } {
+	    set line_by_line 1
+	} else {
+	    set user_code $arg
+	    break
+	}
+    }
+    if { [expr $i + 1] < [llength $args] } {
+	error "Too many arguments to gdb_test_multiple"
+    } elseif { ![info exists user_code] } {
+	error "Too few arguments to gdb_test_multiple"
+    }
+
     if { "$prompt_regexp" == "" } {
 	set prompt_regexp "$gdb_prompt $"
     }
@@ -1069,6 +1091,14 @@ proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
 	}
     }
 
+    if {$line_by_line} {
+       append code {
+           -re "\r\n\[^\r\n\]*(?=\r\n)" {
+               exp_continue
+           }
+       }
+    }
+
     # Now patterns that apply to any spawn id specified.
     append code {
 	-i $any_spawn_id
@@ -1996,22 +2026,24 @@ proc skip_rust_tests {} {
 proc skip_python_tests_prompt { prompt_regexp } {
     global gdb_py_is_py3k
 
-    gdb_test_multiple "python print ('test')" "verify python support" {
-	-re "not supported.*$prompt_regexp" {
-	    unsupported "Python support is disabled."
-	    return 1
+    gdb_test_multiple "python print ('test')" "verify python support" \
+	-prompt "$prompt_regexp" {
+	    -re "not supported.*$prompt_regexp" {
+		unsupported "Python support is disabled."
+		return 1
+	    }
+	    -re "$prompt_regexp" {}
 	}
-	-re "$prompt_regexp" {}
-    } "$prompt_regexp"
 
-    gdb_test_multiple "python print (sys.version_info\[0\])" "check if python 3" {
-	-re "3.*$prompt_regexp" {
-            set gdb_py_is_py3k 1
-        }
-	-re ".*$prompt_regexp" {
-            set gdb_py_is_py3k 0
-        }
-    } "$prompt_regexp"
+    gdb_test_multiple "python print (sys.version_info\[0\])" "check if python 3" \
+	-prompt "$prompt_regexp" {
+	    -re "3.*$prompt_regexp" {
+		set gdb_py_is_py3k 1
+	    }
+	    -re ".*$prompt_regexp" {
+		set gdb_py_is_py3k 0
+	    }
+	}
 
     return 0
 }
@@ -3265,13 +3297,14 @@ proc skip_unwinder_tests {} {
 
 proc skip_libstdcxx_probe_tests_prompt { prompt_regexp } {
     set supported 0
-    gdb_test_multiple "info probe" "check for stap probe in libstdc++" {
-	-re ".*libstdcxx.*catch.*\r\n$prompt_regexp" {
-	    set supported 1
-	}
-	-re "\r\n$prompt_regexp" {
+    gdb_test_multiple "info probe" "check for stap probe in libstdc++" \
+	-prompt "$prompt_regexp" {
+	    -re ".*libstdcxx.*catch.*\r\n$prompt_regexp" {
+		set supported 1
+	    }
+	    -re "\r\n$prompt_regexp" {
+	    }
 	}
-    } "$prompt_regexp"
     set skip [expr !$supported]
     return $skip
 }
@@ -3311,15 +3344,16 @@ proc skip_compile_feature_tests {} {
 
 proc gdb_is_target_1 { target_name target_stack_regexp prompt_regexp } {
     set test "probe for target ${target_name}"
-    gdb_test_multiple "maint print target-stack" $test {
-	-re "${target_stack_regexp}${prompt_regexp}" {
-	    pass $test
-	    return 1
-	}
-	-re "$prompt_regexp" {
-	    pass $test
+    gdb_test_multiple "maint print target-stack" $test \
+	-prompt "$prompt_regexp" {
+	    -re "${target_stack_regexp}${prompt_regexp}" {
+		pass $test
+		return 1
+	    }
+	    -re "$prompt_regexp" {
+		pass $test
+	    }
 	}
-    } "$prompt_regexp"
     return 0
 }
 

Re: [RFC][gdb/testsuite] Add -lbl option in gdb_test_multiple

[Pedro Alves]

On 3/1/20 9:08 AM, Tom de Vries wrote:
> On 27-02-2020 17:02, Pedro Alves wrote:
>> Alternatively, if you don't like the -lbl within the {} block, and if
>> we're going to use "-" options, how about supporting them before
>> the {} user code block, so that the user code block is always
>> at the end?  Like:
>>
>>  gdb_test_multiple "command" "testname" -lbl {
>>    ...
>>  }
>>
>>  gdb_test_multiple "command" "testname" -prompt $prompt_regexp {
>>    ...
>>  }
>>
>> That should be doable with:
>>
>>  -proc gdb_test_multiple { command message user_code { prompt_regexp "" } } {
>>  +proc gdb_test_multiple { command message args } {
>>
>> and then walking the $args list, processing "-" arguments, and interpreting
>> the first non-"-" argument as the user code block (and erroring out if there
>> are more arguments).  I think the gdb_test_multiple code would look quite similar
>> to your patch, except that the user_code parameter would no longer be a parameter,
>> instead it would be a local variable set to the first non-"-" element of $args.
> 
> Yes, I like that suggestion.
> 
> Implemented and attached below.
> 
> OK for trunk.

OK.

Thanks,
Pedro Alves