This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]