diff mbox

Force to update thread list in queue-signal.exp

Message ID 877g0at7mi.fsf@codesourcery.com
State New
Headers show

Commit Message

Yao Qi Oct. 9, 2014, 12:21 a.m. UTC
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?

Comments

Pedro Alves Oct. 10, 2014, 9:18 a.m. UTC | #1
On 10/09/2014 01:21 AM, Yao Qi wrote:
> 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.

Odd.  I sent it as a separate thread with git send-email.
The cover letter has no In-Reply-To or References headers even.
My Thunderbird doesn't put it under any other thread, and the
archives have it as a separate thread too.

But now that you mention this, I had found odd that this series

  https://sourceware.org/ml/gdb-patches/2014-09/msg00772.html

had been sent as reply to an unrelated old email from 2012, but,
now that I look at the raw headers of Jose's email, it doesn't seem
to have been send as response to any email after all, but rather
it's my Thunderbird that's acting up.  gmane doesn't nest that under
what my TB is nesting it under either, this:

  http://thread.gmane.org/gmane.comp.gdb.patches/75048

Jose's mail's headers have:

 Message-Id: <1411724905-31234-1-git-send-email-jose.marchesi@oracle.com>
 In-Reply-To: <no>
 References: <no>

And the message my TB nests it under has:

 Message-Id: <1334741131-29283-1-git-send-email-Hilfinger@adacore.com>
 In-Reply-To: <no>
 References: <no>

I wondered if those "<no>"s triggered that, but my email doesn't
have it, so that wouldn't explain it for your case.

Sounds like we're both hitting the same Thunderbird bug still.
I'm running version 31.1.1 on Fedora 20.

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

Thanks!  I intended to do something like that myself after a period.

Looks good, please push.

Thanks,
Pedro Alves
Yao Qi Oct. 11, 2014, 12:43 a.m. UTC | #2
Pedro Alves <palves@redhat.com> writes:

> Sounds like we're both hitting the same Thunderbird bug still.
> I'm running version 31.1.1 on Fedora 20.

I am running on Fedora 20 too, but with an older ThunderBird.  This
problem bites me from time to time.  Emacs/gnus doesn't have such
problem, and I am using both of them.

>
>> Looks other tests don't have to pull thread list explicitly, IIUC, so we
>> can remove them.  How about the patch below?
>
> Thanks!  I intended to do something like that myself after a period.

Patch is pushed in.
diff mbox

Patch

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 .*" \