[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