From: Jason Molenda <jason-swarelist@molenda.com>
To: gdb-patches@sources.redhat.com
Subject: RFC a little redundancy removal I'd like in gdb.mi
Date: Thu, 10 Oct 2002 16:07:00 -0000 [thread overview]
Message-ID: <20021010160547.A36555@molenda.com> (raw)
Hi all,
I'm looking at the gdb.mi testsuite a bit. There are nearly thirty
cases in the testsuite where code waits for a *stopped message and
matches the stopped location, e.g.
mi_run_cmd
# The running part has been checked already by mi_run_cmd
gdb_expect {
-re "\[\r\n\]*000\\*stopped,reason=\"breakpoint-hit\",bkptno=\"1\",thread-id
=\"\[01\]\",frame=\{addr=\"$hex\",func=\"do_block_tests\",args=\\\[\\\],file=\".
*var-cmd.c\",line=\"154\"\}\r\n$mi_gdb_prompt$" {
pass "run to do_block_tests"
}
-re ".*$mi_gdb_prompt$" {fail "run to do_block_tests (2)"}
timeout {fail "run to do_block_tests (timeout 2)"}
}
I replaced all of these a function, mi_get_stopped -
proc mi_get_stopped { reason thread args func file line message } {
and a shorthand version for stopping at a breakpoint,
proc mi_get_bp_stopped { bkptno thread args func file line message } {
(I should have also made a mi_get_wp_stopped shorthand for the few
watchpoint tests which are nearly identical).
This seems like a reasonable submission to the FSF gdb so I wanted to
bounce the idea off the list - I expect no one will really care either
way, except for maybe wanting a different function name used. :-)
Problems with my change include
mi_get_stopped doesn't look for a specific result code, just the *stopped
message.
mi_get_stopped doesn't eat up ^running text, so some cases where the
test case does a send_gdb "-exec-next\n", you need something like
gdb_expect {
-re "\\^running\r\n${mi_gdb_prompt}" {
mi_get_stopped "end-stepping-range" "\[01\]" "" "main" "func.c" "10" \
"step in main"
}
timeout { fail "step in main (timeout)" }
}
It's used inconsistently, but there are numbers after fail messages
when there are multiple possible failure points. Like the above example,
where we can fail to step correctly, or we can fail to get the ^running
response. mi_get_stopped doesn't currently give any indication about
where you lost, but I don't think it's all that hard to figure it out
from the gdb.log output..
Finally I require a ARGS field for mi_get_stopped, but it is nil for
all calls but one (and that one uses ".*"). I require the thread ID,
but it's [01] in all calls but one, where it's [0-9]. I don't think we'd
loosen the tests too much if these were just .* and [0-9] for all the
cases.
The motivation behind this is purely code clean-up. I promise! Oh OK,
it's not really - at Apple we have different *stopped messages and I
wanted to change one location instead of 30. Nevertheless, I think this
is change has merit all on its own.
Any comments?
next reply other threads:[~2002-10-10 23:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-10 16:07 Jason Molenda [this message]
2002-10-10 16:09 ` Jason Molenda
2002-10-18 15:11 ` Elena Zannoni
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=20021010160547.A36555@molenda.com \
--to=jason-swarelist@molenda.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