[patch] New thread test to exercise Daniel's Patch

[Jeff Johnston]

Daniel Jacobowitz wrote:
> On Fri, Mar 26, 2004 at 04:13:18PM -0500, Jeff Johnston wrote:
> 
>>See the attached test.  There was some stuff in pthreads.exp about Crtl-C 
>>and alpha-*-osf*.  Do I need to account for this platform?
> 
> 
> Well, it's still supported, but I have no idea whether the bit in that
> test is necessary - or what it's supposed to accomplish.  So let's
> ignore it.
> 
> 
>>+# This only works with native configurations
>>+if ![isnative] then {
>>+    return
>>+}
> 
> 
> This shouldn't be necessary.
> 

Ok.

> 
>>+set testfile "manythreads"
>>+set srcfile ${testfile}.c
>>+set binfile ${objdir}/${subdir}/${testfile}
>>+if {[gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug libs=-lpthread}] != ""} {
> 
> 
> See gdb_compile_pthreads.
>

Will do.

> 
>>+send_gdb "set print sevenbit-strings\n" ; gdb_expect -re "$gdb_prompt $"
> 
> 
> gdb_test "set print sevenbit-strings" ""
> 

Ok.

> 
>>+send_gdb "continue\n"
>>+gdb_expect {
> 
> 
> Everywhere you're using gdb_expect, please use gdb_test_multiple
> instead.  For the "after" tests, you can use gdb_test_multiple with
> "" as the first argument.
>

I tried this initially but I kept getting "Error: internal buffer is full".  I 
tried lowering the "after" time which is why it ended up 100 below but that 
didn't solve the problem.  Any suggestions on how to avoid the "full_buffer" error.

> 
>>+# Send a Ctrl-C and verify that we can do info threads and continue
>>+after 100 {send_gdb "\003"}
> 
> 
> Is 100 ms enough to be interesting?
>

It still kicks off a fair number of threads that have started/exited, but I can 
make this bigger.

-- Jeff J.