Re: gdb, native i686-pc-linux-gnu

[Michael Chastain <mec dot gnu at mindspring dot com>]

(I removed gcc-testresults because this isn't relevant to gcc
any more).

Let me go up a level first.  Is testing on linuxthreads still valuable,
or am I the last guy in the world with a linuxthreads system?

For the schedlock.exp "thread N ran" tests, I suspect that it is
marginally valuable, but that linuxthreads might pass into obsoletion
before I ever actually look at it.

>From my point of view it would be nicer to lump the tests together
into a larger test that FAILs all the time, or even better, KFAILs
all the time.  Then it won't show up as diff noise.

For watchthreads.exp, for the test script problems, sounds like a job
for Michael Snyder or for me.

For the gdb problem, if a test passes N% of the time, my response
would be to write a loop in the test script and iterate up to 10
times or 100 times, until gdb blows it or until we give up.
That is a better test, and it also gets rid of the diff noise.

Diff noise is not just a problem for me, it's a problem for anyone
who actually takes our recommendations seriously and runs the test
suite before and after making a change.

Michael C