From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Tom de Vries <tdevries@suse.de>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH][gdb/testsuite] Introduce gdb_test_ext
Date: Thu, 19 Sep 2019 19:24:00 -0000 [thread overview]
Message-ID: <20190919192423.GF4962@embecosm.com> (raw)
In-Reply-To: <62b20c8f-6792-c17e-621a-946002df6df9@suse.de>
* Tom de Vries <tdevries@suse.de> [2019-09-19 21:01:01 +0200]:
> On 19-09-19 18:18, Andrew Burgess wrote:
> > * Tom de Vries <tdevries@suse.de> [2019-09-19 13:13:23 +0200]:
> >
> >> Hi,
> >>
> >> In commit 25e5c20918 "[gdb/testsuite] Allow some tests in gdb.base/store.exp
> >> to be unsupported" we replace a gdb_test:
> >> ...
> >> gdb_test "print l" " = ${l}" \
> >> "${prefix}; print old l, expecting ${l}"
> >> ...
> >> with a gdb_test_multiple:
> >> ...
> >> set supported 1
> >> set test "${prefix}; print old l, expecting ${l}"
> >> gdb_test_multiple "print l" "$test" {
> >> -re " = <optimized out>\r\n$gdb_prompt $" {
> >> unsupported $test
> >> set supported 0
> >> }
> >> -re " = ${l}\r\n$gdb_prompt $" {
> >> pass $test
> >> }
> >> }
> >> ...
> >> in order to handle the UNSUPPORTED case.
> >>
> >> This has the drawback that we have to be explicit about the gdb_prompt, and
> >> move the gdb_test arguments around to fit the gdb_test_multiple format.
> >>
> >> Introduce a new proc gdb_test_ext that behaves as gdb_test, but also allows
> >> extension, allowing us to rewrite the gdb_test_multiple above in a form
> >> resembling the original gdb_test:
> >> ...
> >> set supported 1
> >> gdb_test_ext "print l" " = ${l}" \
> >> "${prefix}; print old l, expecting ${l}" \
> >> -- [list "unsupported" " = <optimized out>" "set supported 0"]
> >
> > I've also thought about this sort of problem in the past, and would
> > like to propose a similar, but slightly different solution.
> >
> > My idea is more like a trimmed down gdb_test_multiple, so for your
> > example above you would write this:
> >
> > gdb_test_ext "print l" "${prefix}; print old l, expecting ${l}" {
> > " = ${l}" {
> > pass $gdb_test_ext_name
> > }
> > " = <optimized out>" {
> > unsupported $gdb_test_ext_name
> > set supported 0
> > }
> > }
> >
> > You don't put '-re' before each pattern, this is because they aren't
> > full patterns, gdb_test_ext will be extending them.
> >
> > Unlike your solution the 'pass' case is not created automatically, you
> > need to write it yourself, so maybe that's a negative. The advantages
> > I see of this approach is that there's not special handling for
> > different "types" of alternatives as in your original code, the action
> > block can contain anything 'unsupported', 'fail', etc. Plus it's
> > formatted as a code body, which I like.
> >
>
> The solution as I proposed it doesn't limit itself to require each
> alternative to be handled as either supported or pass or fail or
> somesuch. It just adds a means to extend gdb_test using a keyword that
> determines how the keyword arguments are handled.
I don't really understand what you're trying to say here, sorry.
Looking at the code it still appears that each case would need to be
added specifically, so if tomorrow I want a 'fail' case, I'd need to
add it to lib/gdb.exp - or am I not understanding?
>
> So, I've added the style you propose here as "generic", and rewrote one
> of the two places I update in store.exp using the "generic" style for
> demonstration purposes.
>
> I envision the usage like this: you'd usually use "unsupported" or
> similar to skip all the repetitive code and focus on the bits that
> actually contain content, and for special cases where that doesn't fit
> you'd use "generic". You can go further and add a "freeform" or some
> such where you'd have to write out the entire regexp.
>
> The nice thing is that you can add keywords and corresponding handling
> as you go, whereas the gdb_test_multiple-like solution you propose only
> has one way of handling its arguments, which of course does makes things
> consistent and clear, but is not very extensible.
I'm still not seeing which arguments can only be handled in one way.
Could you give an example maybe? I do see that you're suggestion
improves the existing test - removing the need to set an extra 'test'
variable, and not having to add $gdb_prompt, but when all is said and
done, the pattern is still just a pattern, and the code is still just
code - how is this any different to gdb_test_multiple?
>
> > One other thing which I've wanted for _ages_ is to avoid having to set
> > the test name into a separate variable, which your solution offers
> > too. The solution I offer is '$gdb_test_ext_name', this variable is
> > set auto-magically by the call to 'gdb_test_ext, and is available in
> > all of the action bodies for calls to pass/fail/unsupported/etc.
> >
>
> Nice trick, I've copied that for usage in the "generic" method.
>
> So, WDYT?
I'm still not convinced.
On further thought, I actually think there's no need for an extra
function at all, we can get all the benefit (as I see it) by possibly
updating gdb_test_multiple. I'm travelling right now so can't code
this up, but I think a solution that does something like this:
gdb_test_multiple "command" "test name" {
-re "full regexp here$gdb_prompt" {
pass $gdb_test_multiple_name
}
-output "pattern without prompt" {
fail $gdb_test_multiple_name
}
}
So using '-re' and '-output' to specialise the behaviour of
gdb_test_multiple, and adding in the $gdb_test_multiple_name variable.
When I get back to my desk I'll try to code this up.
I'm know the above isn't going to satisfy you though - it's basically
an iteration on what I already proposed - maybe you could expand on
the benefits of you solution a bit more.
Thanks,
Andrew
>
> Thanks,
> - Tom
>
> [gdb/testsuite] Introduce gdb_test_ext
>
> In commit 25e5c20918 "[gdb/testsuite] Allow some tests in gdb.base/store.exp
> to be unsupported" we replace a gdb_test:
> ...
> gdb_test "print l" " = ${l}" \
> "${prefix}; print old l, expecting ${l}"
> ...
> with a gdb_test_multiple:
> ...
> set supported 1
> set test "${prefix}; print old l, expecting ${l}"
> gdb_test_multiple "print l" "$test" {
> -re " = <optimized out>\r\n$gdb_prompt $" {
> unsupported $test
> set supported 0
> }
> -re " = ${l}\r\n$gdb_prompt $" {
> pass $test
> }
> }
> ...
> in order to handle the UNSUPPORTED case.
>
> This has the drawback that we have to be explicit about the gdb_prompt, and
> move the gdb_test arguments around to fit the gdb_test_multiple format.
>
> Introduce a new proc gdb_test_ext that behaves as gdb_test, but also allows
> extension, allowing us to rewrite the gdb_test_multiple above in a form
> resembling the original gdb_test:
> ...
> set supported 1
> gdb_test_ext "print l" " = ${l}" \
> "${prefix}; print old l, expecting ${l}" \
> -- [list "unsupported" " = <optimized out>" "set supported 0"]
> ...
>
> Tested on x86_64-linux.
>
> gdb/testsuite/ChangeLog:
>
> 2019-09-19 Tom de Vries <tdevries@suse.de>
>
> * lib/gdb.exp (gdb_test_ext): New proc.
> * gdb.base/store.exp: Use gdb_test_ext.
>
> ---
> gdb/testsuite/gdb.base/store.exp | 27 ++++--------
> gdb/testsuite/lib/gdb.exp | 95 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 103 insertions(+), 19 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.base/store.exp b/gdb/testsuite/gdb.base/store.exp
> index 9c19ce15a7..89a594f96a 100644
> --- a/gdb/testsuite/gdb.base/store.exp
> +++ b/gdb/testsuite/gdb.base/store.exp
> @@ -56,16 +56,8 @@ proc check_set { t l r new add } {
> }
>
> set supported 1
> - set test "${prefix}; print old l, expecting ${l}"
> - gdb_test_multiple "print l" "$test" {
> - -re " = <optimized out>\r\n$gdb_prompt $" {
> - unsupported $test
> - set supported 0
> - }
> - -re " = ${l}\r\n$gdb_prompt $" {
> - pass $test
> - }
> - }
> + gdb_test_ext "print l" " = ${l}" "${prefix}; print old l, expecting ${l}" \
> + -- [list "unsupported" " = <optimized out>" "set supported 0"]
> if { $supported } {
> gdb_test "print r" " = ${r}" \
> "${prefix}; print old r, expecting ${r}"
> @@ -102,16 +94,13 @@ proc up_set { t l r new } {
> "${prefix}; up"
>
> set supported 1
> - set test "${prefix}; print old l, expecting ${l}"
> - gdb_test_multiple "print l" "$test" {
> - -re " = <optimized out>\r\n$gdb_prompt $" {
> - unsupported $test
> - set supported 0
> + gdb_test_ext "print l" " = ${l}" "${prefix}; print old l, expecting ${l}" \
> + -- {
> + "generic" " = <optimized out>" {
> + set supported 0
> + unsupported $gdb_test_ext_name
> + }
> }
> - -re " = ${l}\r\n$gdb_prompt $" {
> - pass $test
> - }
> - }
> if { $supported } {
> gdb_test "print r" " = ${r}" \
> "${prefix}; print old r, expecting ${r}"
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index acbeb01376..d01ca25ef7 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -1103,6 +1103,101 @@ proc gdb_test { args } {
> }]
> }
>
> +# As gdb_test, but with additional parameters, listed after a "--" separator.
> +# Handled extra parameters:
> +# - [list "unsupported" <pattern> [<code>]]
> +# The idea is to prevent the need to rewrite gdb_test into gdb_test_multiple
> +# if some modification is needed.
> +proc gdb_test_ext { args } {
> + global gdb_prompt
> + upvar timeout timeout
> +
> + # Find the '--' separator.
> + set pos -1
> + set index 0
> + while { $index < [llength $args] } {
> + if { [lindex $args $index] == "--" } {
> + set pos $index
> + break
> + }
> + set index [expr $index + 1]
> + }
> + if { $pos == -1 } {
> + error "No -- argument found"
> + }
> +
> + if { $pos > 2 } then {
> + set message [lindex $args 2]
> + } else {
> + set message [lindex $args 0]
> + }
> + set command [lindex $args 0]
> + set pattern [lindex $args 1]
> +
> + set user_code {}
> + lappend user_code {
> + -re "\[\r\n\]*(?:$pattern)\[\r\n\]+$gdb_prompt $" {
> + if ![string match "" $message] then {
> + pass "$message"
> + }
> + }
> + }
> +
> + if { $pos == 5 } {
> + set question_string [lindex $args 3]
> + set response_string [lindex $args 4]
> + lappend user_code {
> + -re "(${question_string})$" {
> + send_gdb "$response_string\n"
> + exp_continue
> + }
> + }
> + }
> +
> + set index [expr $pos + 1]
> + while { $index < [llength $args] } {
> + set arg [lindex $args $index]
> + set index [expr $index + 1]
> + set kind [lindex $arg 0]
> + switch $kind {
> + "unsupported" {
> + set unsupported_pattern [lindex $arg 1]
> + set unsupported_code [lindex $arg 2]
> + if { $unsupported_code == "" } {
> + set unsupported_code "expr true"
> + }
> + lappend user_code {
> + -re "\[\r\n\]*(?:$unsupported_pattern)\[\r\n\]+$gdb_prompt $" {
> + unsupported $message
> + uplevel $unsupported_code
> + }
> + }
> + }
> + "generic" {
> + # In order to support the gdb_test_ext_name variable we need to
> + # push the variable into the parent scope. Before we blindly do
> + # that check the user hasn't already defined that variable. If
> + # they haven't, go ahead and create it for them.
> + if { [uplevel { info exists gdb_test_ext_name }] } {
> + error "variable gdb_test_ext_name unexpectedly exists"
> + return -1
> + }
> + uplevel set gdb_test_ext_name \"$message\"
> + set generic_pattern [lindex $arg 1]
> + set generic_code [lindex $arg 2]
> + lappend user_code {
> + -re "\[\r\n\]*(?:$generic_pattern)\[\r\n\]+$gdb_prompt $" {
> + uplevel $generic_code
> + }
> + }
> + }
> + }
> + }
> +
> + set user_code [join $user_code " "]
> + return [gdb_test_multiple $command $message $user_code]
> +}
> +
> # Return 1 if version MAJOR.MINOR is at least AT_LEAST_MAJOR.AT_LEAST_MINOR.
> proc version_at_least { major minor at_least_major at_least_minor} {
> if { $major > $at_least_major } {
next prev parent reply other threads:[~2019-09-19 19:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 11:13 Tom de Vries
2019-09-19 16:18 ` Andrew Burgess
2019-09-19 19:01 ` Tom de Vries
2019-09-19 19:24 ` Andrew Burgess [this message]
2019-09-19 21:50 ` Tom de Vries
2019-10-05 6:05 ` [PATCH][gdb/testsuite] Add -cooked pattern flag to gdb_test_multiple Tom de Vries
2019-10-05 15:38 ` Andrew Burgess
2019-10-06 6:37 ` Tom de Vries
2019-10-07 10:30 ` Andrew Burgess
2019-10-06 8:29 ` Tom de Vries
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=20190919192423.GF4962@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
/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