[RFA] gdb.trace/*.exp send_gdb vs. gdb_test
Pedro Alves
pedro@codesourcery.com
Thu May 27 23:15:00 GMT 2010
On Thursday 27 May 2010 20:08:40, Michael Snyder wrote:
> Pedro Alves wrote:
> > On Thursday 27 May 2010 19:18:37, Michael Snyder wrote:
> >> This patch should get extra-thorough review and preferably be tested by
> >> the tracepoint maintainers, since I wasn't able to test all of it.
> >
> > Did you test it against gdbserver x86 or x86_64? That should cover it:
> >
> > <http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration>
>
> OK thanks. They all work except for limits.exp, which does not run
> because it tests "tstatus" before it executes "target remote".
Thanks for testing. Indeed, I had never noticed that. I can't say
I'm fond of the:
"We generously give ourselves one "pass" if we
successfully detect that this test cannot be run on this target!"
pattern in this tests. :-) I wonder who shall I complain
about that to. ;-)
Let me try to fix that before you commit. Should be simple.
Other tests had the same issue, and I thought I had fixed them
all, but obviously this one slipped.
I took a look at your patch.
> -send_gdb "list $baseline, +12\n"
> -gdb_expect {
> +gdb_test_multiple "list $baseline, +12" "all tests in this module will fail" {
> -re "\[\r\n\](\[0-9\]+).*gdbtestline 1 " {
> set testline1 $expect_out(1,string)
> exp_continue
> @@ -108,7 +107,7 @@ all tests in this module will fail."
> untested backtrace.exp
> return -1
> all tests in this module will fail."
> - }
> + }
> }
>
Can you do the return outside of gdb_test_multiple please?
I saw a few other instances in tfind.exp. Otherwise, looked fine.
--
Pedro Alves
More information about the Gdb-patches
mailing list