This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[ob] Adjust tls.exp for slow hosts
- From: Daniel Jacobowitz <drow at false dot org>
- To: gdb-patches at sourceware dot org
- Date: Wed, 3 Jan 2007 12:34:54 -0500
- Subject: [ob] Adjust tls.exp for slow hosts
I ran this test a huge number of times yesterday while working on a
kernel patch. It expects a group of threads to sem_post, eventually
waking the main thread, and then go to sleep in sem_wait. But if the
threads don't get scheduled after they post, they might still be
in sem_post.
Of course, as the comment says, they can be anywhere else too if we're
unlikely with time slices. But in practice that's vanishingly unlikely, so
I restricted myself to the common case and an explanatory comment.
Checked in after mind numbing testing on x86_64-pc-linux-gnu.
--
Daniel Jacobowitz
CodeSourcery
2007-01-03 Daniel Jacobowitz <dan@codesourcery.com>
* gdb.threads/tls.exp: Allow stops in sem_post.
Index: testsuite/gdb.threads/tls.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/tls.exp,v
retrieving revision 1.4
diff -u -p -r1.4 tls.exp
--- testsuite/gdb.threads/tls.exp 29 Jul 2003 21:51:25 -0000 1.4
+++ testsuite/gdb.threads/tls.exp 3 Jan 2007 17:27:43 -0000
@@ -246,7 +246,11 @@ foreach i [array names spin_threads] {
incr thrs_in_spin
select_thread $i
set level $spin_threads_level($i)
- gdb_test "up $level" ".*spin.*sem_wait.*" "thread $i up"
+ # We expect to be in sem_wait, but if the thread has not yet
+ # been scheduled, we might be in sem_post still. We could be at
+ # any intermediate point in spin, too, but that is much less
+ # likely.
+ gdb_test "up $level" ".*spin.*sem_(wait|post).*" "thread $i up"
check_thread_local $i
}
}