From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Michael Snyder <msnyder@vmware.com>
Subject: Re: [RFA] gdb.base/c*.exp, send_gdb vs. gdb_test
Date: Sun, 23 May 2010 01:40:00 -0000 [thread overview]
Message-ID: <201005222335.58505.pedro@codesourcery.com> (raw)
In-Reply-To: <4BF84A62.40806@vmware.com>
On Saturday 22 May 2010 22:19:30, Michael Snyder wrote:
>
> Index: call-ar-st.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.base/call-ar-st.exp,v
> retrieving revision 1.24
> diff -u -p -r1.24 call-ar-st.exp
> --- call-ar-st.exp 5 May 2010 18:06:57 -0000 1.24
> +++ call-ar-st.exp 22 May 2010 21:15:10 -0000
> @@ -61,24 +61,19 @@ set timeout [expr "$timeout + 60"]
> proc set_lang_c {} {
> global gdb_prompt
>
> - send_gdb "set language c\n"
> - gdb_expect {
> - -re ".*$gdb_prompt $" {}
> - timeout { fail "set language c (timeout)" ; return 0; }
> - }
> + gdb_test_no_output "set language c"
>
> - send_gdb "show language\n"
> - gdb_expect {
> + gdb_test_multiple "show language" "set language to \"c\"" {
> -re ".* source language is \"c\".*$gdb_prompt $" {
> pass "set language to \"c\""
> return 1
> }
> -re ".*$gdb_prompt $" {
> - fail "setting language to \"c\""
> + fail "set language to \"c\""
> return 0
> }
> timeout {
> - fail "can't show language (timeout)"
> + fail "(timeout) set language to \"c\""
> return 0
> }
You'll need to have the pass branch set a variable, and
do the return outside gdb_test_multiple. This is because
gdb_test_multiple catches other error reasons (the whole purpose
of gdb_test_multiple). This pattern shows up in several
other files, I'll skip mentioning those from here on.
(I'm not sure whether you've missed the "return 0" on the
"set" test above: it does seem okay to let the "show" test
handle it.)
> #call compute_with_small_structs(20)
> -send_gdb "print compute_with_small_structs(20)\n"
> -gdb_expect {
> - -re ".*\[0-9\]+ =.*$gdb_prompt $" {
> - pass "print compute_with_small_structs(20)"
> - }
> - -re ".*$gdb_prompt $" { fail "print compute_with_small_structs(20)" }
> - timeout { fail "(timeout) compute_with_small_structs(20)" }
> - }
> +gdb_test "print compute_with_small_structs(20)" \
> + "\[0-9\]+ = void" \
> + "print compute_with_small_structs(20)"
>
You didn't resist changing the expected output here? :-)
> - send_gdb "step\n"
> - gdb_expect {
> - -re "
> -init_bit_flags_combo \\(bit_flags_combo=, a=1, b=0, ch1=121 .y., g=1, d=0, ch2=110 .n., e=1, o=0\\) at .*call-ar-st.c:416\[ \t\n\r\]+416.*bit_flags_combo->alpha = a;.*$gdb_prompt $" {
> - pass "step into init_bit_flags_combo"}
> - -re ".*$gdb_prompt $" { fail "step into init_bit_flags_combo" }
> - timeout { fail "step into init_bit_flags_combo (timeout)" }
> - }
> +gdb_test "step" \
> + "init_bit_flags_combo \\(bit_flags_combo=, a=1, b=0, ch1=121 .y., g=1, d=0, ch2=110 .n., e=1, o=0\\) at .*call-ar-st.c:416\[ \t\n\r\]+416.*bit_flags_combo->alpha = a;" \
> + "step into init_bit_flags_combo"
>
Missing .* at end of expected output? I saw several of
those; I don't know if this was on purpose.
On Saturday 22 May 2010 22:19:30, Michael Snyder wrote:
> + gdb_test_multiple "bt" "backtrace" {
> + -re "#(\[0-9\]*) *<function called from gdb>.*$gdb_prompt $" {
> + return $expect_out(1,string)
> + }
> + -re "$gdb_prompt $" {
> + return ""
> + }
> + timeout {
> + return ""
> + }
> + }
> + return ""
Similar remark one of the above, but in this case, there's already a
return outside gdb_test_multiple, so you can remove the last -re and
the timeout handling.
> if ![gdb_skip_stdio_test "call str_func1(s)"] {
> - send_gdb "call str_func1(s)\n"
> - gdb_expect {
> - -re "first string arg is: test string.*\"test string\".*$gdb_prompt $" {
> - pass "call str_func1(s)"
> - }
> - -re ".*$gdb_prompt $" { fail "call str_func1(s)" }
> - timeout { fail "(timeout) call str_func1(s)" }
> - }
> + gdb_test "call str_func1(s)" \
The previous test output didn't have the extra space. Could you
remove it? There are several instances of this.
I've been assuming you've been diffing gdb.sum before/after
these patches; it'd be nice if you mentioned any changes shown by
that diff.
> + "first string arg is: test string.*\"test string\".*"
> }
Are you planning on committing the patches that have been
reviewed soon? I think it would be a good idea to get them in
sooner than later, so that we can see if there are any problems
we may have missed in review, and so we'd avoid propagating the
same mistakes in all these other patches.
--
Pedro Alves
next prev parent reply other threads:[~2010-05-22 22:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-22 22:33 Michael Snyder
2010-05-23 1:40 ` Pedro Alves [this message]
2010-05-23 20:15 ` Michael Snyder
2010-05-23 21:40 ` Pedro Alves
2010-05-24 22:07 ` Michael Snyder
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=201005222335.58505.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=msnyder@vmware.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