* [RFA] New threads test
@ 2003-09-30 19:22 Daniel Jacobowitz
2003-10-01 18:37 ` Michael Snyder
0 siblings, 1 reply; 9+ messages in thread
From: Daniel Jacobowitz @ 2003-09-30 19:22 UTC (permalink / raw)
To: gdb-patches
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 \\(\\);"
+
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFA] New threads test 2003-09-30 19:22 [RFA] New threads test Daniel Jacobowitz @ 2003-10-01 18:37 ` Michael Snyder 2003-10-01 18:52 ` Daniel Jacobowitz 0 siblings, 1 reply; 9+ messages in thread From: Michael Snyder @ 2003-10-01 18:37 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb-patches 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] New threads test 2003-10-01 18:37 ` Michael Snyder @ 2003-10-01 18:52 ` Daniel Jacobowitz 2003-10-09 14:10 ` Daniel Jacobowitz 0 siblings, 1 reply; 9+ messages in thread From: Daniel Jacobowitz @ 2003-10-01 18:52 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb-patches 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] New threads test 2003-10-01 18:52 ` Daniel Jacobowitz @ 2003-10-09 14:10 ` Daniel Jacobowitz 2003-10-09 19:41 ` Michael Snyder 0 siblings, 1 reply; 9+ messages in thread From: Daniel Jacobowitz @ 2003-10-09 14:10 UTC (permalink / raw) To: Michael Snyder, gdb-patches 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] New threads test 2003-10-09 14:10 ` Daniel Jacobowitz @ 2003-10-09 19:41 ` Michael Snyder 2003-10-09 19:49 ` Daniel Jacobowitz 0 siblings, 1 reply; 9+ messages in thread From: Michael Snyder @ 2003-10-09 19:41 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb-patches 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". ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] New threads test 2003-10-09 19:41 ` Michael Snyder @ 2003-10-09 19:49 ` Daniel Jacobowitz 2003-10-10 0:05 ` Michael Snyder 0 siblings, 1 reply; 9+ messages in thread From: Daniel Jacobowitz @ 2003-10-09 19:49 UTC (permalink / raw) To: gdb-patches 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 \\(\\);" + ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] New threads test 2003-10-09 19:49 ` Daniel Jacobowitz @ 2003-10-10 0:05 ` Michael Snyder 2003-10-10 1:28 ` Daniel Jacobowitz 0 siblings, 1 reply; 9+ messages in thread From: Michael Snyder @ 2003-10-10 0:05 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb-patches 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] New threads test 2003-10-10 0:05 ` Michael Snyder @ 2003-10-10 1:28 ` Daniel Jacobowitz 0 siblings, 0 replies; 9+ messages in thread From: Daniel Jacobowitz @ 2003-10-10 1:28 UTC (permalink / raw) To: gdb-patches 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] New threads test @ 2003-09-30 19:39 Michael Elizabeth Chastain 0 siblings, 0 replies; 9+ messages in thread From: Michael Elizabeth Chastain @ 2003-09-30 19:39 UTC (permalink / raw) To: drow, gdb-patches 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-10-10 1:28 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-09-30 19:22 [RFA] New threads test Daniel Jacobowitz 2003-10-01 18:37 ` Michael Snyder 2003-10-01 18:52 ` Daniel Jacobowitz 2003-10-09 14:10 ` Daniel Jacobowitz 2003-10-09 19:41 ` Michael Snyder 2003-10-09 19:49 ` Daniel Jacobowitz 2003-10-10 0:05 ` Michael Snyder 2003-10-10 1:28 ` Daniel Jacobowitz 2003-09-30 19:39 Michael Elizabeth Chastain
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox