* [PATCH][gdb/testsuite] Fix corefile-buildid.exp with check-read1 @ 2020-02-19 17:40 Tom de Vries 2020-02-19 20:09 ` Pedro Alves 0 siblings, 1 reply; 8+ messages in thread From: Tom de Vries @ 2020-02-19 17:40 UTC (permalink / raw) To: gdb-patches 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix corefile-buildid.exp with check-read1 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 0 siblings, 1 reply; 8+ messages in thread From: Pedro Alves @ 2020-02-19 20:09 UTC (permalink / raw) To: Tom de Vries, gdb-patches 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [RFC][gdb/testsuite] Handle -line and -non-empty-line in gdb_test_multiple 2020-02-19 20:09 ` Pedro Alves @ 2020-02-19 21:30 ` Tom de Vries 2020-02-20 13:28 ` Pedro Alves 0 siblings, 1 reply; 8+ messages in thread From: Tom de Vries @ 2020-02-19 21:30 UTC (permalink / raw) To: Pedro Alves, gdb-patches [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC][gdb/testsuite] Handle -line and -non-empty-line in gdb_test_multiple 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 ` [RFC][gdb/testsuite] Add -lbl option " Tom de Vries 0 siblings, 1 reply; 8+ messages in thread From: Pedro Alves @ 2020-02-20 13:28 UTC (permalink / raw) To: Tom de Vries, gdb-patches 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [RFC][gdb/testsuite] Add -lbl option in gdb_test_multiple 2020-02-20 13:28 ` Pedro Alves @ 2020-02-21 15:35 ` Tom de Vries 2020-02-27 16:03 ` Pedro Alves 0 siblings, 1 reply; 8+ messages in thread From: Tom de Vries @ 2020-02-21 15:35 UTC (permalink / raw) To: Pedro Alves, gdb-patches [-- 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 } ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC][gdb/testsuite] Add -lbl option in gdb_test_multiple 2020-02-21 15:35 ` [RFC][gdb/testsuite] Add -lbl option " Tom de Vries @ 2020-02-27 16:03 ` Pedro Alves 2020-03-01 9:08 ` Tom de Vries 0 siblings, 1 reply; 8+ messages in thread From: Pedro Alves @ 2020-02-27 16:03 UTC (permalink / raw) To: Tom de Vries, gdb-patches 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC][gdb/testsuite] Add -lbl option in gdb_test_multiple 2020-02-27 16:03 ` Pedro Alves @ 2020-03-01 9:08 ` Tom de Vries 2020-03-02 13:34 ` Pedro Alves 0 siblings, 1 reply; 8+ messages in thread From: Tom de Vries @ 2020-03-01 9:08 UTC (permalink / raw) To: Pedro Alves, gdb-patches [-- 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 } ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC][gdb/testsuite] Add -lbl option in gdb_test_multiple 2020-03-01 9:08 ` Tom de Vries @ 2020-03-02 13:34 ` Pedro Alves 0 siblings, 0 replies; 8+ messages in thread From: Pedro Alves @ 2020-03-02 13:34 UTC (permalink / raw) To: Tom de Vries, gdb-patches 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-03-02 13:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 ` [RFC][gdb/testsuite] Add -lbl option " Tom de Vries 2020-02-27 16:03 ` Pedro Alves 2020-03-01 9:08 ` Tom de Vries 2020-03-02 13:34 ` Pedro Alves
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox