Re: RFC a little redundancy removal I'd like in gdb.mi

[Elena Zannoni <ezannoni@redhat.com>]

Jason Molenda writes:
 > 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. 
 > 

Hmm yes, true. I think most of those, if not all, could be substituted
by the already existing "mi_runto function_to_stop_at" mechanism.

If so, we don't need this new function.

I think this is an artifact of how the testsuite got written. Only
after a while we thought of writing the mi version of the runto
function.

Elena


 > 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?