This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC/RFA] testsuite/gdb.base/watch_thread_num.exp: Fix test for systems having hidden threads


This test currently fails on cygwin target
and it does by timeout's which means that it takes a lot of time...
The reason of the failure is that 
thread #2 is a thread created internally by cygwin,
for posix emulation, and thus never
changes the value of the variable shared_var.
  
  I modified the test so that it does
not suppose that thread 2 is one of the explicitly generated
threads, but instead adds a breakpoint to
thread_function, and reads the thread number of the first
explicitly generated thread.
  I also added an iteration number to the final test loop.

  I am mainly unsure about the details
required for the ChangeLog entry...

  I only tested the patch on Cygwin target where it gives
29 passes, but I expect it to give the same results
on other targets that had no failures before.

  One possible problem is about the $expect_out(1,string)
because this is undefined if the first pattern is not found.
But I suppose that this is not unique to my patch,
as lots of gdb_expect calls only have braces
to define a group that will become the $expect_out return values
in only one regular expression.

  Is there a coding rule for this?

Pierre Muller


testsuite directory ChangeLog entry

2007-12-19  Pierre Muller  <muller@ics-u-strasbg.fr>

	* (gdb.base/watch_thread_num.exp): Add breakpoint at
	thread_function and record first explicitly generated
	thread number. 
	Use that thread number for thread specific watchpoint test.
	Add iteration number to repetitive tests.

$ cat threadwatch.patch
Index: gdb/testsuite/gdb.base/watch_thread_num.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/watch_thread_num.exp,v
retrieving revision 1.1
diff -u -p -r1.1 watch_thread_num.exp
--- gdb/testsuite/gdb.base/watch_thread_num.exp 17 Dec 2007 12:32:23 -00001.1
+++ gdb/testsuite/gdb.base/watch_thread_num.exp 19 Dec 2007 08:45:41 -0000
@@ -54,11 +54,28 @@ gdb_test "watch shared_var thread" "A sy

 gdb_test "Next 5" ""

-gdb_test "watch shared_var thread 2" "Hardware watchpoint 2: shared_var" "Watch
point on shared variable"
-gdb_test "info breakpoint 2" "stop only in thread 2"
+gdb_test "break thread_function" "Breakpoint \[0-9\].*" \
+  "Set breakpoint at thread_function"

-for {set i 0} {$i < 10} {incr i 1} {
-gdb_test "continue" "Hardware watchpoint 2: shared_var.*" "Watchpoint triggered
"
-gdb_test "thread" "\\\[Current thread is 2 \\\(Thread $hex \\\(LWP $decimal\\\)
\\\)\\\]" "Check thread that triggered"
+gdb_test "continue" ".*Breakpoint 2.*" "Stopped in thread_function"
+
+send_gdb "thread\n"
+gdb_expect {
+  -re ".*Current thread is (\[0-9\]*).*$gdb_prompt $" { pass "Thread command" }
+  -re ".*$gdb_prompt $" { fail "Thread command" }
+  timeout { fail "(timeout) Thread command" }
+}
+
+set thread_num "$expect_out(1,string)"
+
+gdb_test "disable 2" "" "Disable breakpoint 2"
+gdb_test "watch shared_var thread $thread_num" "Hardware watchpoint 3: shared_v
ar" "Watchpoint on shared variable"
+gdb_test "info breakpoint 3" "stop only in thread $thread_num"
+
+for {set i 1} {$i <= 10} {incr i 1} {
+gdb_test "continue" "Hardware watchpoint 3: shared_var.*" \
+  "Watchpoint triggered iteration $i"
+gdb_test "thread" ".*Current thread is $thread_num .*" \
+  "Check thread that triggered iteration $i"
 }




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]