This is the mail archive of the gdb-patches@sourceware.org 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]

Re: [RFA] Fix setting of VSX registers


>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Tom> One approach would be to refactor these procs so that your use can work.
Tom> I think this would be nice to have -- I think it would be good to have
Tom> fewer boilerplate tests with "synthetic" names, ones that nobody is
Tom> interested in.

Joel> When we discussed the new gdb-testsuite that AdaCore uses, we talked
Joel> about that quite a bit. And unsurprisingly, there was no obvious answer.
Joel> These tests can be an annoyance if all hell breaks lose and they all
Joel> start to fail. A PASS indeed adds little value to the results.  But
Joel> on the other hand, I have always felt that we should verify that these
Joel> commands have the expected results, and that we should get a FAIL if
Joel> we detect something went wrong. Ideally, we wanted to be able to group
Joel> a sequence of commands as one "setup phase" and generate one FAIL if
Joel> part of the sequence fails. But in the end, we decided that it was just
Joel> simpler to treat everything as a test (this is what I have pretty much
Joel> done in dejagnu as well).

Yeah, it is definitely simpler to keep going with what we already have.
At least for me, test suite hacking is in itself not very interesting,
so I usually just opt for the minimal change that works, and move on to
fun things.

If someone is motivated to work on this, though, one approach would be
to separate out the mechanics of sending a command to gdb and matching
responses from the pass/fail reporting.  Then it would be possible to
write a proc that evals its argument and passes or fails based on the
answer:

single_gdb_test "test name here" {
  gdb_send_no_response "set language c";  # throws exception on "failure"
  gdb_send_and_response "print 23" " = 23"
}

... or what have you.

Another thing I've often wanted is to have the tests forced to have
unique names: by having the test frame work automatically include the
.exp name in the test name, and by automatically handling duplicates
somehow (either an error, or appending a counter).

Tom


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