Re: [RFA] New threads test

Re: [RFA] New threads test

[Michael Elizabeth Chastain]

I'm gonna be a stickler here ...

I think switch-threads.c needs an FSF copyright notice at the top.
It's long enough enough to be a non-trivial work.

  http://www.gnu.org/prep/maintain_8.html#SEC8

Michael C

===

2003-09-30  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.threads/switch-threads.exp: New test.
	* gdb.threads/switch-threads.c: New source file.

[RFA] New threads test

[Daniel Jacobowitz]

This is a test for the remote protocol issue I'm solving with vCont.  It
also shows up in schedlock, but the simpler test makes it much clearer
what's going wrong.  OK?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-09-30  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.threads/switch-threads.exp: New test.
	* gdb.threads/switch-threads.c: New source file.

--- /dev/null	1969-12-31 19:00:00.000000000 -0500
+++ testsuite/gdb.threads/switch-threads.c	2003-09-27 16:49:09.000000000 -0400
@@ -0,0 +1,25 @@
+#include <pthread.h>
+
+void foo (void)
+{
+}
+
+void *thread_func (void *arg)
+{
+  int x;
+  for (x = 0; x < 10; x++)
+    foo ();
+  return 0;
+}
+
+int main()
+{
+  pthread_t thr;
+  void *ret;
+  int x;
+
+  pthread_create (&thr, NULL, thread_func, NULL);
+  pthread_join (thr, &ret);
+  for (x = 0; x < 10; x++)
+    foo ();  
+}
--- /dev/null	1969-12-31 19:00:00.000000000 -0500
+++ testsuite/gdb.threads/switch-threads.exp	2003-09-28 13:04:48.000000000 -0400
@@ -0,0 +1,46 @@
+# Copyright (C) 2003 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# Please email any bugs, comments, and/or additions to this file to:
+# bug-gdb@prep.ai.mit.edu
+
+# This file was written by Daniel Jacobowitz <drow@mvista.com>.
+#
+# It tests that the correct thread is single-stepped.
+
+if $tracelevel then {
+	strace $tracelevel
+}
+
+set testfile "switch-threads"
+set srcfile ${testfile}.c
+set binfile ${objdir}/${subdir}/${testfile}
+
+if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable [list debug "incdir=${objdir}"]] != "" } {
+    return -1
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+
+runto_main
+
+gdb_breakpoint thread_func
+gdb_continue_to_breakpoint "continue to thread_func"
+gdb_test "next" ".*foo \\(\\);"
+

Re: [RFA] New threads test

[Michael Snyder]

Daniel Jacobowitz wrote:
> This is a test for the remote protocol issue I'm solving with vCont.  It
> also shows up in schedlock, but the simpler test makes it much clearer
> what's going wrong.  OK?
> 

Umm... what is going wrong?  What are you testing for here?

Re: [RFA] New threads test

[Daniel Jacobowitz]

On Wed, Oct 01, 2003 at 11:37:11AM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> >This is a test for the remote protocol issue I'm solving with vCont.  It
> >also shows up in schedlock, but the simpler test makes it much clearer
> >what's going wrong.  OK?
> >
> 
> Umm... what is going wrong?  What are you testing for here?

+# It tests that the correct thread is single-stepped.

More intelligibly: when gdbserver is told to single-step one thread
(without holding all others schedlocked), it assumes we mean the first
thread.  Which might not be the _right_ thread.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] New threads test

[Daniel Jacobowitz]

On Wed, Oct 01, 2003 at 02:52:30PM -0400, Daniel Jacobowitz wrote:
> On Wed, Oct 01, 2003 at 11:37:11AM -0700, Michael Snyder wrote:
> > Daniel Jacobowitz wrote:
> > >This is a test for the remote protocol issue I'm solving with vCont.  It
> > >also shows up in schedlock, but the simpler test makes it much clearer
> > >what's going wrong.  OK?
> > >
> > 
> > Umm... what is going wrong?  What are you testing for here?
> 
> +# It tests that the correct thread is single-stepped.
> 
> More intelligibly: when gdbserver is told to single-step one thread
> (without holding all others schedlocked), it assumes we mean the first
> thread.  Which might not be the _right_ thread.

Hi Michael,

Is this test OK (with a better comment and the copyright notice that
Michael C suggested)?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] New threads test

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Wed, Oct 01, 2003 at 02:52:30PM -0400, Daniel Jacobowitz wrote:
> 
>>On Wed, Oct 01, 2003 at 11:37:11AM -0700, Michael Snyder wrote:
>>
>>>Daniel Jacobowitz wrote:
>>>
>>>>This is a test for the remote protocol issue I'm solving with vCont.  It
>>>>also shows up in schedlock, but the simpler test makes it much clearer
>>>>what's going wrong.  OK?
>>>>
>>>
>>>Umm... what is going wrong?  What are you testing for here?
>>
>>+# It tests that the correct thread is single-stepped.
>>
>>More intelligibly: when gdbserver is told to single-step one thread
>>(without holding all others schedlocked), it assumes we mean the first
>>thread.  Which might not be the _right_ thread.

Hmmm... it should assume we mean the _current_ thread
(ie. the one that had a stop event).  The remote protocol
should cover this (and did, last I checked).

> Hi Michael,
> 
> Is this test OK (with a better comment and the copyright notice that
> Michael C suggested)?

OK, with emphasis on "more comments".

Re: [RFA] New threads test

[Daniel Jacobowitz]

On Thu, Oct 09, 2003 at 12:41:16PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> >On Wed, Oct 01, 2003 at 02:52:30PM -0400, Daniel Jacobowitz wrote:
> >
> >>On Wed, Oct 01, 2003 at 11:37:11AM -0700, Michael Snyder wrote:
> >>
> >>>Daniel Jacobowitz wrote:
> >>>
> >>>>This is a test for the remote protocol issue I'm solving with vCont.  It
> >>>>also shows up in schedlock, but the simpler test makes it much clearer
> >>>>what's going wrong.  OK?
> >>>>
> >>>
> >>>Umm... what is going wrong?  What are you testing for here?
> >>
> >>+# It tests that the correct thread is single-stepped.
> >>
> >>More intelligibly: when gdbserver is told to single-step one thread
> >>(without holding all others schedlocked), it assumes we mean the first
> >>thread.  Which might not be the _right_ thread.
> 
> Hmmm... it should assume we mean the _current_ thread
> (ie. the one that had a stop event).  The remote protocol
> should cover this (and did, last I checked).

I could have changed gdbserver to default to that, in fact I thought I
had (but I hadn't).  But it still breaks down if the user switches
threads explicitly - see vCont, which this is testing.

> >Hi Michael,
> >
> >Is this test OK (with a better comment and the copyright notice that
> >Michael C suggested)?
> 
> OK, with emphasis on "more comments".

Thanks!  Here's what I checked in.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-10-07  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.threads/switch-threads.exp: New test.
	* gdb.threads/switch-threads.c: New source file.

--- /dev/null	1969-12-31 19:00:00.000000000 -0500
+++ gdb.threads/switch-threads.c	2003-10-09 15:47:52.000000000 -0400
@@ -0,0 +1,47 @@
+/* A minimal multi-threaded test case.
+
+   Copyright 2003
+   Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#include <pthread.h>
+
+void foo (void)
+{
+}
+
+void *thread_func (void *arg)
+{
+  int x;
+  for (x = 0; x < 10; x++)
+    foo ();
+  return 0;
+}
+
+int main()
+{
+  pthread_t thr;
+  void *ret;
+  int x;
+
+  pthread_create (&thr, NULL, thread_func, NULL);
+  pthread_join (thr, &ret);
+  for (x = 0; x < 10; x++)
+    foo ();  
+}
--- /dev/null	1969-12-31 19:00:00.000000000 -0500
+++ gdb.threads/switch-threads.exp	2003-10-09 15:46:26.000000000 -0400
@@ -0,0 +1,52 @@
+# Copyright (C) 2003 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# Please email any bugs, comments, and/or additions to this file to:
+# bug-gdb@prep.ai.mit.edu
+
+# This file was written by Daniel Jacobowitz <drow@mvista.com>.
+#
+# It tests that the correct thread is single-stepped.  Prior to the
+# introduction of vCont, we didn't pass enough information to remote
+# multi-threaded stubs to reliably get this correct; gdbserver defaulted
+# to the first thread.
+
+# TODO: we should also test explicitly changing threads with the "thread"
+# command.
+
+if $tracelevel then {
+	strace $tracelevel
+}
+
+set testfile "switch-threads"
+set srcfile ${testfile}.c
+set binfile ${objdir}/${subdir}/${testfile}
+
+if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable [list debug "incdir=${objdir}"]] != "" } {
+    return -1
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+
+runto_main
+
+gdb_breakpoint thread_func
+gdb_continue_to_breakpoint "continue to thread_func"
+gdb_test "next" ".*foo \\(\\);"
+

Re: [RFA] New threads test

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Thu, Oct 09, 2003 at 12:41:16PM -0700, Michael Snyder wrote:
> 
>>Daniel Jacobowitz wrote:
>>
>>>On Wed, Oct 01, 2003 at 02:52:30PM -0400, Daniel Jacobowitz wrote:
>>>
>>>
>>>>On Wed, Oct 01, 2003 at 11:37:11AM -0700, Michael Snyder wrote:
>>>>
>>>>
>>>>>Daniel Jacobowitz wrote:
>>>>>
>>>>>
>>>>>>This is a test for the remote protocol issue I'm solving with vCont.  It
>>>>>>also shows up in schedlock, but the simpler test makes it much clearer
>>>>>>what's going wrong.  OK?
>>>>>>
>>>>>
>>>>>Umm... what is going wrong?  What are you testing for here?
>>>>
>>>>+# It tests that the correct thread is single-stepped.
>>>>
>>>>More intelligibly: when gdbserver is told to single-step one thread
>>>>(without holding all others schedlocked), it assumes we mean the first
>>>>thread.  Which might not be the _right_ thread.
>>
>>Hmmm... it should assume we mean the _current_ thread
>>(ie. the one that had a stop event).  The remote protocol
>>should cover this (and did, last I checked).
> 
> 
> I could have changed gdbserver to default to that, in fact I thought I
> had (but I hadn't).  But it still breaks down if the user switches
> threads explicitly - 

Hmmm, that's what target_prepare_to_proceed is supposed to handle.
Err... was.  What happened to it?  I missed this discussion, I guess.

 >see vCont, which this is testing.

Can you refer me to the threads on vcont?  I've been seeing
references to it, but haven't found the origin or the definition.

Re: [RFA] New threads test

[Daniel Jacobowitz]

On Thu, Oct 09, 2003 at 05:05:33PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> >On Thu, Oct 09, 2003 at 12:41:16PM -0700, Michael Snyder wrote:
> >
> >>Daniel Jacobowitz wrote:
> >>
> >>>On Wed, Oct 01, 2003 at 02:52:30PM -0400, Daniel Jacobowitz wrote:
> >>>
> >>>
> >>>>On Wed, Oct 01, 2003 at 11:37:11AM -0700, Michael Snyder wrote:
> >>>>
> >>>>
> >>>>>Daniel Jacobowitz wrote:
> >>>>>
> >>>>>
> >>>>>>This is a test for the remote protocol issue I'm solving with vCont.  
> >>>>>>It
> >>>>>>also shows up in schedlock, but the simpler test makes it much clearer
> >>>>>>what's going wrong.  OK?
> >>>>>>
> >>>>>
> >>>>>Umm... what is going wrong?  What are you testing for here?
> >>>>
> >>>>+# It tests that the correct thread is single-stepped.
> >>>>
> >>>>More intelligibly: when gdbserver is told to single-step one thread
> >>>>(without holding all others schedlocked), it assumes we mean the first
> >>>>thread.  Which might not be the _right_ thread.
> >>
> >>Hmmm... it should assume we mean the _current_ thread
> >>(ie. the one that had a stop event).  The remote protocol
> >>should cover this (and did, last I checked).
> >
> >
> >I could have changed gdbserver to default to that, in fact I thought I
> >had (but I hadn't).  But it still breaks down if the user switches
> >threads explicitly - 
> 
> Hmmm, that's what target_prepare_to_proceed is supposed to handle.
> Err... was.  What happened to it?  I missed this discussion, I guess.

It's still there.  It turned out that all of the architecture specific
versions could be replaced by a generic one.

prepare_to_proceed is part of the solution, yes - the reason that it
was changed was because I also ran into that when working on the same
problem.  But the problem is that the remote protocol wasn't rich
enough to describe what we wanted to do.  Particularly the difference
between:
  step thread 3
  step thread 3 and let all other threads run

We got instead:
  step thread 3
  step some thread and let all other threads run


> >see vCont, which this is testing.
> 
> Can you refer me to the threads on vcont?  I've been seeing
> references to it, but haven't found the origin or the definition.

The origin is hard to follow in the list archives, since the
conversation took six or seven months.  You can find the final
definition at:
  http://sources.redhat.com/ml/gdb/2003-10/msg00020.html
and some earlier discussion at:
  http://sources.redhat.com/ml/gdb/2003-09/msg00210.html
and
  http://sources.redhat.com/ml/gdb-patches/2003-09/msg00624.html

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer