Re: RFA (threads testsuite): More thread tests

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Aug 23, 2002 at 11:51:41AM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Thu, Aug 22, 2002 at 04:34:51PM -0700, Michael Snyder wrote:
> > > Daniel Jacobowitz wrote:
> > > >
> > > > Here's two tests I had lying around from when I developed the gdbserver
> > > > threads support.  Gdbserver passes them with flying colors (if you use my
> > > > other patch which lets gdbserver run tests properly).  GDB shows a couple of
> > > > problems, unpredictably (not always repeatable).
> > > >
> > > > OK to add these?
> > >
> > > Hi Joel,
> > >
> > > I understand the point of schedlock.exp, but what's the point of
> > > print-threads.exp?  What is it that you're testing?
> > 
> > No specific feature - just the general ability to handle threads doing
> > things.  It has a slightly different behavior pattern than the other
> > threads testscases, and triggered different problems.  Oh, and I
> > remember - there is no other testcase in the testsuite with
> > pthread_join in it; no threads ever actually exit.  I found some
> > problems there while I was implementing the gdbserver threads support.
> 
> OK, then, since we definitely need more thread testing, 
> let's accept these.  I like the way you verified that 
> schedlock was implemented for the target before testing it.
> 
> BTW, do these really have to be native-only?  They should
> work for embedded pthread targets, shouldn't they?

(And I'll make them use the new compile command too!)

Sure.  But which ones will it work on, that's the question.  I'm
tempted to have a gdb_skip_threads_test, but not sure what to key it
off of...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer