From: Michael Elizabeth Chastain <mec@shout.net>
To: ac131313@redhat.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] Rewrite "structs" testcase
Date: Sat, 08 Nov 2003 01:05:00 -0000 [thread overview]
Message-ID: <200311080105.hA815u3k028944@duracef.shout.net> (raw)
The results are:
PASS FAIL
gcc 2.95.3 -gdwarf-2 544 40
gcc 2.95.3 -gstabs+ 544 40
gcc 3.3.2 -gdwarf-2 540 44
gcc 3.3.2 -gstabs+ 544 40
The problem is in this code:
# Now force a return. Be careful to only produce one PASS/FAIL.
send_gdb "return foo${n}\n"
gdb_expect {
-re "Make fun${n} return now.*y or n. $" {
send_gdb "y\n"
gdb_expect {
-re "L${n} *= fun${n}.*${gdb_prompt} $" {
# Need to step off the function call
gdb_test "next" "L.* *= fun.*" "${test}"
}
-re "${gdb_prompt} $" {
pass "${test}"
}
timeout {
fail "${test} (timeout)"
}
}
}
}
First there are duplicate "${test}" names in the output,
and some of them PASS and some of them FAIL. Confusion!
The real problem is what to do when the notorious
"location at which to store the function's return value is unknown"
happens. If that message happens, perhaps it is a KFAIL because
gdb cannot do what the user asked. Or perhaps it is okay because
a message was printed. I'm leaning towards the KFAIL, myself.
But the next bit of code:
# Finally check that the value returned ended up in "L${n}".
setup_fails ${fails} gdb/1444
gdb_test "p/c L${n}" " = [foo ${n}]" "${test}"
If "location unknown" has occurred, then it's not even worthwhile
to execute this at all. Once gdb has informed the user about
"location unknown" then there should be no expectation on the
part of the user that the return value will get stored into memory.
Maybe gdb needs to print an additional message to make it
more clear to the user:
The location at which to store the function's return value is unknown.
If you continue, the return value that you specified will be ignored.
Make fun1 return now? (y or n) y
Then in the test script, if you get "location unknown", issue a KFAIL
(or do whatever) and skip a test or two.
I put up a tarball here:
ftp://ftp.shout.net/pub/users/mec/gdb/2003-11-06.tar.gz
(The filename is lame because I made 2003-11-06-2 yesterday).
Michael C
next reply other threads:[~2003-11-08 1:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-08 1:05 Michael Elizabeth Chastain [this message]
2003-11-09 1:22 ` Andrew Cagney
2003-11-10 0:32 ` Michael Elizabeth Chastain
2003-11-11 22:28 ` Andrew Cagney
-- strict thread matches above, loose matches on Subject: below --
2003-11-12 18:30 Michael Elizabeth Chastain
2003-11-12 18:13 Michael Elizabeth Chastain
2003-11-13 16:11 ` Andrew Cagney
2003-11-17 15:59 ` Andrew Cagney
2003-11-20 17:17 ` Andrew Cagney
2003-11-12 16:51 Michael Elizabeth Chastain
2003-11-06 20:44 Michael Elizabeth Chastain
2003-11-07 20:35 ` Andrew Cagney
2003-11-06 19:10 Michael Elizabeth Chastain
2003-11-06 20:22 ` Andrew Cagney
2003-11-06 17:33 Michael Elizabeth Chastain
2003-11-06 18:49 ` Andrew Cagney
2003-11-06 21:38 ` Michael Snyder
2003-11-05 22:17 Andrew Cagney
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=200311080105.hA815u3k028944@duracef.shout.net \
--to=mec@shout.net \
--cc=ac131313@redhat.com \
--cc=gdb-patches@sources.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