Re: RFA (threads testsuite): More thread tests

[Michael Snyder <msnyder at redhat dot com>]

Daniel Jacobowitz wrote:
> 
> 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...

Well -- if they won't build (eg. because there's no threads library), 
it's a pretty sure bet they won't run.  If they do build...