GDB/testsuite: Correct gdb.base/watchpoint-solib.exp timeout tweak

  Hi,

 Similarly to the changes to gdb.reverse/sigall-reverse.exp and 
gdb.reverse/until-precsave.exp recently posted this corrects the timeout 
tweak in gdb.base/watchpoint-solib.exp.

 This test case executes a large amount of code with a software watchpoint 
enabled.  This means single-stepping all the way through and takes a lot 
of time, e.g. for an ARMv7 Panda board and a `-march=armv5te' multilib:

PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 714

for the same board and a `-mthumb -march=armv5te' multilib:

PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 1275

and for QEMU in the system emulation mode and a `-march=armv4t'
multilib:

PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 115

(values in seconds) -- all of which having the default timeout of 60s, set 
based on the requirement of the remaining test cases (other than 
gdb.reverse ones).

 Here again the timeout extension to have a meaning should be calculated 
by scaling rather than using an arbitrary constant, and a larger factor of 
30 will do, leaving some margin.  Hopefully for everyone or otherwise 
we'll probably have to come up with a smarter solution.

 OTOH the other test cases in this script do not require the extension so 
they can be moved outside its umbrella so as to avoid unnecessary delays 
if something goes wrong and a genuine timeout triggers.

 Tested on arm-linux-gnueabi.  OK to apply?

2014-07-29  Maciej W. Rozycki  <macro@codesourcery.com>

	gdb/testsuite/
	* gdb.base/watchpoint-solib.exp: Increase the timeout by a factor
	of 30 rather than hardcoding 120 for a slow test case.  Take the 
	`gdb,timeout' target setting into account for this calculation.
	Don't extend the timeout for the test cases that don't need it.

  Maciej

gdb-test-watchpoint-solib-timeout.diff
  

On 07/29/2014 01:10 PM, Maciej W. Rozycki wrote:
> Hi,
> 
>  Similarly to the changes to gdb.reverse/sigall-reverse.exp and 
> gdb.reverse/until-precsave.exp recently posted this corrects the timeout 
> tweak in gdb.base/watchpoint-solib.exp.
> 
>  This test case executes a large amount of code with a software watchpoint 
> enabled.  This means single-stepping all the way through and takes a lot 
> of time, e.g. for an ARMv7 Panda board and a `-march=armv5te' multilib:
> 
> PASS: gdb.base/watchpoint-solib.exp: continue to foo again
> elapsed: 714
> 
> for the same board and a `-mthumb -march=armv5te' multilib:
> 
> PASS: gdb.base/watchpoint-solib.exp: continue to foo again
> elapsed: 1275
> 
> and for QEMU in the system emulation mode and a `-march=armv4t'
> multilib:
> 
> PASS: gdb.base/watchpoint-solib.exp: continue to foo again
> elapsed: 115
> 
> (values in seconds) -- all of which having the default timeout of 60s, set 
> based on the requirement of the remaining test cases (other than 
> gdb.reverse ones).
> 
>  Here again the timeout extension to have a meaning should be calculated 
> by scaling rather than using an arbitrary constant, and a larger factor of 
> 30 will do, leaving some margin.  Hopefully for everyone or otherwise 
> we'll probably have to come up with a smarter solution.
> 
>  OTOH the other test cases in this script do not require the extension so 
> they can be moved outside its umbrella so as to avoid unnecessary delays 
> if something goes wrong and a genuine timeout triggers.
> 
>  Tested on arm-linux-gnueabi.  OK to apply?

OK

> +
> +set savedtimeout $timeout
> +if { [target_info exists gdb,timeout]
> +     && $timeout < [target_info gdb,timeout] } {
> +    set oldtimeout [target_info gdb,timeout]
> +} else {
> +    set oldtimeout $timeout
> +}
> +set timeout [expr $oldtimeout * 30]

Clearly this pattern is going to be popping in more
places going forward.  Maybe we should even consider factoring
it out to a with_test_prefix-like procedure.  Something like:

 proc with_timeout_factor { factor } {
   ...
 }

 with_timeout_factor 30 {
    ...
    gdb_test "continue" ".*Breakpoint 2.*foo.*" "continue to foo again"
    ...
 }

Thanks,
Pedro Alves
  

On Tue, 29 Jul 2014, Pedro Alves wrote:

> >  Tested on arm-linux-gnueabi.  OK to apply?
> 
> OK

 Applied now, thanks.

> > +
> > +set savedtimeout $timeout
> > +if { [target_info exists gdb,timeout]
> > +     && $timeout < [target_info gdb,timeout] } {
> > +    set oldtimeout [target_info gdb,timeout]
> > +} else {
> > +    set oldtimeout $timeout
> > +}
> > +set timeout [expr $oldtimeout * 30]
> 
> Clearly this pattern is going to be popping in more
> places going forward.  Maybe we should even consider factoring
> it out to a with_test_prefix-like procedure.  Something like:
> 
>  proc with_timeout_factor { factor } {
>    ...
>  }
> 
>  with_timeout_factor 30 {
>     ...
>     gdb_test "continue" ".*Breakpoint 2.*foo.*" "continue to foo again"
>     ...
>  }

 Just as with the gdb.reverse change, I agree this is a good idea and I'll 
keep it in my mind as a future improvement (honestly I'd rather use my 
next available slot for GDB development though to get the outstanding 
microMIPS and MIPS FP stuff dusted off and resubmitted, so this stuff will 
only be for the second next slot or suchlike ;) ).

  Maciej