This is the mail archive of the
gdb-testers@sources.redhat.com
mailing list for the GDB project.
Re: gdb, native i686-pc-linux-gnu
- From: Daniel Jacobowitz <drow at false dot org>
- To: Michael Chastain <mec dot gnu at mindspring dot com>
- Cc: gcc-testresults at gcc dot gnu dot org, gdb-testers at sources dot redhat dot com
- Date: Wed, 11 Aug 2004 10:30:33 -0400
- Subject: Re: gdb, native i686-pc-linux-gnu
- References: <411A2231.nailCEL1114EF@mindspring.com>
On Wed, Aug 11, 2004 at 09:42:09AM -0400, Michael Chastain wrote:
> . Highlights of This Spin
>
> I added gdb 6.2, skipping 6.1.91, 6.1.92, and 6.1.93. There is one
> regression from gdb 6.1.1 to gdb 6.2: PR gdb/1650. To see all the
> changes from gdb 6.1.1 to gdb 6.2, look at the difference tables for
> gdb (6.1.1, 6.2).
>
> gdb.threads/watchthreads.exp is unstable in my test bed. I have not
> analyzed this yet.
I have. The main problem is that the test script works if one
watchpoint triggers at a time.
(A) The test script has problems. It doesn't match the output
correctly, and bails out of the main loop too early.
(B) GDB has problems. If a thread creation breakpoint is hit, and a
watchpoint triggers while we are stopping all threads, then GDB prints
"Thread Creation Event - GDB should not stop!" or something like that.
Even if I fix that bug and make GDB print the watchpoint information,
it thinks the current thread is the one stopped in __nptl_create_event
and prints that thread's location.
In other words, GDB's thread event handling is lousy. Not a shocker
:-(
> All tests PASSed in all non-gcc-HEAD configurations except for
> the "thread N ran" tests. Here are the counts per thread.
>
> t0 t1 t2 t3 t4 t5
> PASS 2 22 21 22 21 22
> FAIL 20 0 1 0 1 0
Do you think these tests add any value? I'm considering weakening them
so that we don't generally have this problem. I'm a little curious as
to why one thread fails more frequently than the others... but it's
probably just a scheduling artifact.
--
Daniel Jacobowitz