From: David Carlton <carlton@math.stanford.edu>
To: Jim Blandy <jimb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: report failure to restore selected frame, but continue
Date: Wed, 09 Apr 2003 22:14:00 -0000 [thread overview]
Message-ID: <ro14r57gvxq.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <vt2k7e3tklp.fsf@zenia.red-bean.com>
On 09 Apr 2003 16:41:06 -0500, Jim Blandy <jimb@redhat.com> said:
[ message snipped ]
Basically fine, just a few comments. It might be nice if there were a
test for this somewhere appropriate in gdb.base, in which case the big
comment could go there: or is there a reason why this only manifests
itself in C++? Actually, I'm not convinced that all of the big
comment belongs in the test suite at all: why not put it some place in
the GDB source code and/or the bug database, with a reference to that
in the testsuite? The diagnosis of the problem should be in the place
where it people fixing the problem will be most likely to see it,
after all.
The use of a conditional setup_kfail followed by a fail is good:
normally, I don't like setup_kfail so much, but it's quite appropriate
here.
> + # of 4-2003 it doesn't, so code like frame_find_by_id can't
Personally, I'd say "April 2003" or "2003-04-09" or something instead
of "4-2003".
> + # fail. We should detect report that failure, but let the marker call
Typo.
> + send_gdb "frame\n"
> + gdb_expect {
> + -re "#0 marker1.*$gdb_prompt $" {
> + setup_kfail "gdb/1155" s390-*-linux-gnu
> + fail "re-selected 'main' frame after inferior method call (gdb/1155)"
> + gdb_test "finish" ".*main.*at .*userdef.cc:27\[67\].*" \
> + "finish call to marker1"
> + }
> + -re "#1 ($hex in )?main.*$gdb_prompt $" {
> + pass "re-selected 'main' frame after inferior method call"
> + }
> + -re ".*$gdb_prompt $" {
> + fail "re-selected 'main' frame after inferior method call"
> + }
> + timeout {
> + fail "re-selected 'main' frame after inferior method call (timeout)"
> + }
> + }
> +
We're using gdb_test_multiple now: replace the first two lines by:
gdb_test_multiple "frame" "re-selected 'main' frame after inferior method call" {
and delete the last two branches. (I'm pretty sure that's right, run
it to make sure.) You can see an example in gdb.c++/templates.exp.
Also, don't put (gdb/1155) in the fail message: the setup_kfail should
take care of that for you.
Ditto for the uses in the other two files, of course.
Other than that, it's fine: no need to resubmit it for approval after
making those changes unless you think it would be useful for some
reason.
David Carlton
carlton@math.stanford.edu
next prev parent reply other threads:[~2003-04-09 22:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-09 21:40 Jim Blandy
2003-04-09 22:14 ` David Carlton [this message]
2003-04-09 23:21 ` Jim Blandy
2003-04-10 1:55 ` 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=ro14r57gvxq.fsf@jackfruit.Stanford.EDU \
--to=carlton@math.stanford.edu \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@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