From: Tom de Vries <tdevries@suse.de>
To: Pedro Alves <palves@redhat.com>, gdb-patches@sourceware.org
Subject: [RFC][gdb/testsuite] Add -lbl option in gdb_test_multiple
Date: Fri, 21 Feb 2020 15:35:00 -0000 [thread overview]
Message-ID: <80d69419-60df-8308-9587-295a86c5041b@suse.de> (raw)
In-Reply-To: <883bfb0f-c8e7-ae6c-aa94-2486b3c76362@redhat.com>
[-- 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
}
next prev parent reply other threads:[~2020-02-21 15:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 17:40 [PATCH][gdb/testsuite] Fix corefile-buildid.exp with check-read1 Tom de Vries
2020-02-19 20:09 ` Pedro Alves
2020-02-19 21:30 ` [RFC][gdb/testsuite] Handle -line and -non-empty-line in gdb_test_multiple Tom de Vries
2020-02-20 13:28 ` Pedro Alves
2020-02-21 15:35 ` Tom de Vries [this message]
2020-02-27 16:03 ` [RFC][gdb/testsuite] Add -lbl option " Pedro Alves
2020-03-01 9:08 ` Tom de Vries
2020-03-02 13:34 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80d69419-60df-8308-9587-295a86c5041b@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox