Re: [PATCH] gdb: use gdb_test_multiple in gdb_breakpoint

[Simon Marchi <simon.marchi@polymtl.ca>]

> As mentioned, this is more of a generic concern of all procedures exposed
> by lib/gdb.exp.  gdb_breakpoint was just one among many.  Seems better to look
> at the overall design/direction rather than just one case in isolation.
> 
> Let's take runto.  It calls gdb_breakpoint (which used to use gdb_expect before your change),
> and then gdb_run_cmd, and then gdb_expect directly.  gdb_run_cmd itself uses gdb_expect.
> gdb_run_cmd may use gdb_reload, which calls gdb_load, which uses gdb_load_cmd, which uses
> gdb_expect.
> 
> So changing any of these gdb_expect to gdb_test_multiple would result in intermediate PASSes
> starting to be emitted.  Depending on refactoring, etc, you'd get different internal PASSes.
> Depending on different target, you'd get wildly different internal PASSes, etc.  You'd get
> a lot more mismatching PASS/FAIL cases when one of the internal gdb_test_multiple's failed.
> Etc.  That doesn't seem like the ideal approach to me.
I don't see that as a big problem.  In fact I like having fine-grained
PASSes or FAILs for the various intermediate steps of the test.  I think
it's fine to get different PASSes on different targets, it represents
what's actually being done.  When debugging a test, I look at the first
FAIL/UNRESOLVED. In the example you gave, if the gdb_load_cmd fails, I'd
appreciate having a FAIL for that, close to the source of the problem,
rather than starting from a later point and having to backtrack.

Plus, the fact that I encountered a few times cases like:

  # Return early if do_something fails
  if { ![do_something] } {
    return
  }

... where do_something would not log anything.  So I broke do_something,
but didn't notice because nothing logged a failure.

However, I can see that having different PASSes in each test can be
annoying if you are diffing test results from two target boards.  That
will add noise in the diff.  When mixing these two concerns, I guess
that we arrive to the "don't tell me when it works, but tell me when it
fails" that gdb_breakpoint and others have.  Maybe it's good after all.

Simon