RFA: adapt gdb.threads/linux-dp.exp to remote protocol and NPTL

RFA: adapt gdb.threads/linux-dp.exp to remote protocol and NPTL

[Jim Blandy]

The remote protocol doesn't announce thread creation.  NPTL has no
manager threads.  With this patch, linux-dp has no failures debugging
NPTL programs over the remote protocol.

2004-10-29  Jim Blandy  <jimb@redhat.com>

	* gdb.threads/linux-dp.exp: Tolerate the absence of "[New thread]"
	messages, and the absence of the manager thread.

Index: gdb/testsuite/gdb.threads/linux-dp.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/linux-dp.exp,v
retrieving revision 1.9
diff -c -r1.9 linux-dp.exp
*** gdb/testsuite/gdb.threads/linux-dp.exp	14 May 2003 19:36:56 -0000	1.9
--- gdb/testsuite/gdb.threads/linux-dp.exp	29 Oct 2004 05:10:41 -0000
***************
*** 91,97 ****
  	    return -1
  	}
  	-re "$gdb_prompt $" {
! 	    fail "create philosopher: $i"
  	}
  	timeout {
  	    fail "(timeout) create philosopher: $i"
--- 91,102 ----
  	    return -1
  	}
  	-re "$gdb_prompt $" {
! 	    # We used to fail here, but 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'.
! 	    unresolved "create philosopher: $i"
  	}
  	timeout {
  	    fail "(timeout) create philosopher: $i"
***************
*** 99,109 ****
      }
  }
  
! if {$expect_manager} {
!     set nthreads 7
! } else {
!     set nthreads 6
! }
  
  # Run until there are some threads.
  gdb_breakpoint [gdb_get_line_number "linuxthreads.exp: info threads 2"]
--- 104,110 ----
      }
  }
  
! set nthreads 6
  
  # Run until there are some threads.
  gdb_breakpoint [gdb_get_line_number "linuxthreads.exp: info threads 2"]
***************
*** 112,118 ****
  for {set i $nthreads} {$i > 0} {incr i -1} {
      append info_threads_ptn "$i Thread .*"
  }
! gdb_test "info threads" $info_threads_ptn "info threads 2"
  
  # Try setting a thread-specific breakpoint.
  gdb_breakpoint "print_philosopher thread 5"
--- 113,163 ----
  for {set i $nthreads} {$i > 0} {incr i -1} {
      append info_threads_ptn "$i Thread .*"
  }
! append info_threads_ptn "\[\r\n\]+$gdb_prompt $"
! set info_threads_manager_ptn "[expr $nthreads + 1] Thread .*$info_threads_ptn"
! 
! gdb_test_multiple "info threads" "info threads 2" {
!     -re "$info_threads_manager_ptn" {
! 	# We did see a manager thread.  Check that against what we expected.
! 	switch -exact -- $expect_manager {
! 	    -1 {
! 		# We weren't sure whether to expect a manager thread.
! 		pass "info threads 2"
! 	    }
! 	    1 {
! 		# We were expecting a manager thread.
! 		pass "info threads 2"
! 	    }
! 	    0 {
! 		# We were not expecting to see the manager thread.
! 		fail "info threads 2"
! 	    }
! 	}
! 	set expect_manager 1
! 	incr nthreads
!     }
!     -re "$info_threads_ptn" {
! 	# We did not see a manager thread.  Check that against what we
! 	# expected.
! 	switch -exact -- $expect_manager {
! 	    -1 {
! 		# We weren't sure whether to expect a manager thread.
! 		# Don't expect it from here on out.
! 		pass "info threads 2"
! 	    }
! 	    1 {
! 		# We were expecting a manager thread, but we didn't see one.
! 		fail "info threads 2"
! 	    }
! 	    0 {
! 		# We were not expecting to see the manager thread.
! 		pass "info threads 2"
! 	    }
! 	}
! 	set expect_manager 0
!     }
! }
! 
  
  # Try setting a thread-specific breakpoint.
  gdb_breakpoint "print_philosopher thread 5"

RFA: adapt gdb.threads/linux-dp.exp to remote protocol and NPTL

[Jim Blandy]

This patch is waiting for a review.

http://sources.redhat.com/ml/gdb-patches/2004-10/msg00483.html

The remote protocol doesn't announce thread creation.  NPTL has no
manager threads.  With this patch, linux-dp has no failures debugging
NPTL programs over the remote protocol.

2004-10-29  Jim Blandy  <jimb@redhat.com>

	* gdb.threads/linux-dp.exp: Tolerate the absence of "[New thread]"
	messages, and the absence of the manager thread.