gdb.base/checkpoint.exp failures

No failures on pavo1.

Running /home/yao/maverick/home/yao/cvs/src/gdb/testsuite/gdb.base/checkpoint.exp ...

  === gdb Summary ===

# of expected passes 139
/home/yao/maverick/home/yao/cvs/build/gdb/testsuite/../../gdb/gdb version 7.2.50.20100819-cvs -nw -nx

Still can't got any failure on Andrew's board, turn it into INVALID.

Running ../../../src/gdb/testsuite/gdb.base/checkpoint.exp ...

                === gdb Summary ===

# of expected passes 139
/home/yao/cvs/build/gdb/testsuite/../../gdb/gdb version 7.2.50.20100820-cvs -nw -nx

I can still reproduce problem reliably on GDB 7.2 on Loic's Beagleboard. Reopening ...

Hmm, it appears the system simply *is* slow. The test case creates > 600 checkpoints, by performing an inferior call to the "fork" function. Each such call apparently takes on the order of 1 second on the beagleboard, which means the test case actually requires more than 5 minutes to complete.

Raising the timeout values accordingly allows the tests to complete successfully.

It would be interesting to investigate whether the 1 sec per fork inferior call is just the way it is on that hardware, or if this is actually evidence of a performance problems somewhere else (kernel? gdb?) ...

One more data point: there is no timeout if running on a system with no (or inaccessible) debuginfo files for libc.

Maybe the slowness is not actually in the creation of the forks themselves, but in re-reading in the libc debuginfo for each newly created process?

I'm setting this to Won't Fix since:
- the problem doesn't show up in the default installation (where libc-dbg is not installed)
- in any case, there is no real bug, GDB is just slow
- this slowness is not ARM specific, it is just exacerbated by running on a slow machine
- the GDB community is already working on various ways to speed up symbol loading