Re: [PATCH] Force to update thread list in queue-signal.exp

[Yao Qi <yao@codesourcery.com>]

Pedro Alves <palves@redhat.com> writes:

>>> 	* gdb.threads/queue-signal.exp: Execute command "info threads".
>
> This part should no longer be necessary:
>
>  https://sourceware.org/ml/gdb-patches/2014-09/msg00734.html

Thanks for the pointer.  I didn't follow this patch series because
ThunderBird hides it under other unrelated thread.

Looks other tests don't have to pull thread list explicitly, IIUC, so we
can remove them.  How about the patch below?

-- 
Yao (齐尧)

Subject: [PATCH] No longer pull thread list explicitly

As the result of the patch below, GDB updates thread list when a stop is
presented to user.  The tests don't have to fetch thread list explicitly.

  [PATCH 3/3] Fix non-stop regressions caused by "breakpoints always-inserted off" changes
  https://sourceware.org/ml/gdb-patches/2014-09/msg00734.html

This patch is to remove the test code updating thread list.

Run these three tests many times on arm-linux-gnueabi and x86-linux.
No regressions.

gdb/testsuite:

2014-10-08  Yao Qi  <yao@codesourcery.com>

	* gdb.threads/attach-into-signal.exp (corefunc): Don't execute
	 command "info threads".
	* gdb.threads/thread-find.exp: Likewise.
	* gdb.threads/linux-dp.exp: Don't check the condition
	$threads_created equals to zero.

diff --git a/gdb/testsuite/gdb.threads/attach-into-signal.exp b/gdb/testsuite/gdb.threads/attach-into-signal.exp
index d77380b..277a9d0 100644
--- a/gdb/testsuite/gdb.threads/attach-into-signal.exp
+++ b/gdb/testsuite/gdb.threads/attach-into-signal.exp
@@ -102,15 +102,6 @@ proc corefunc { threadtype executable } {
 			# that by peeking at the thread's siginfo.
 			# SIGALRM is 14, SIGSTOP is 19.
 
-			# With remote targets, we need to pull the
-			# thread list explicitly before GDB even knows
-			# about thread 2.
-			set test2 "pull thread list"
-			gdb_test_multiple "info threads" $test2 {
-			    -re "\r\n$gdb_prompt $" {
-			    }
-			}
-
 			set test2 "thread apply 2 print \$_siginfo.si_signo"
 			gdb_test_multiple $test2 $test2 {
 			    -re " = 14\r\n$gdb_prompt $" {
diff --git a/gdb/testsuite/gdb.threads/linux-dp.exp b/gdb/testsuite/gdb.threads/linux-dp.exp
index 8fa8288..f4099fe 100644
--- a/gdb/testsuite/gdb.threads/linux-dp.exp
+++ b/gdb/testsuite/gdb.threads/linux-dp.exp
@@ -104,14 +104,7 @@ for {set i 0} {$i < 5} {incr i} {
 	-re "$gdb_prompt $" {
 	}
     }
-    if { $threads_created == 0 } {
-	# Not all targets announce new threads as they are created.
-	# For example, the GDB
-	# remote protocol target only finds out about threads when
-	# they actually report some event like a breakpoint hit,
-	# or when the user types 'info threads'.
-	unsupported "create philosopher: $i"
-    } elseif { $threads_created == 1 } {
+    if { $threads_created == 1 } {
 	if { $expect_manager < 0 } {
 	    set expect_manager 0
 	}
diff --git a/gdb/testsuite/gdb.threads/thread-find.exp b/gdb/testsuite/gdb.threads/thread-find.exp
index 25f2856..3e82989 100644
--- a/gdb/testsuite/gdb.threads/thread-find.exp
+++ b/gdb/testsuite/gdb.threads/thread-find.exp
@@ -29,10 +29,6 @@ runto_main
 gdb_breakpoint [gdb_get_line_number "linuxthreads.exp: info threads 2"]
 gdb_continue_to_breakpoint "main thread's sleep"
 
-# Make sure thread list is up-to-date (in case remote targets have not yet
-# reported thread creation events)
-gdb_test "info threads"
-
 # Create thread names.
 gdb_test "thread apply 1 thread name threadname_1" \
     "Thread 1 .*" \