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

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

[Jason Molenda]

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?

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

[Jason Molenda]

On Thu, Oct 10, 2002 at 04:05:47PM -0700, Jason Molenda wrote:

> Problems with my change include 
> 
>   mi_get_stopped doesn't look for a specific result code, just the *stopped
>   message.

(I mean "specific sequence #" - it'll accept any old sequence number.  This
doesn't concern me overly; if the sequence number stuff was broken I imagine
that'll be readily apparent from all the other tests.)

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

[Elena Zannoni]

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?