Re: [RFA] gdb.trace/*.exp send_gdb vs. gdb_test

[Michael Snyder <msnyder@vmware.com>]

Pedro Alves wrote:
> 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.

Done and committed.  By the way, would you take a look at the
diff just above?  What is "all tests in this module will fail"
doing there?  The same thing appears in both backtrace.exp and
report.exp.