On 04/22/2013 09:02 PM, Pedro Alves wrote:
> I hacked GDB some more, and I have further insight.
> GDB _is_ to blame.  Updated GDB/test hack patch at the bottom.

> So GDB is to blame.  Fixing this, however, would be a different
> story, and doesn't look that simple.
>
> So the test could work around this by making sure that threads
> don't exit until after all watchpoints have been tested.

I did one more fix to the testcase to allow it to run properly when the 
number of threads is greater than the number of available hardware 
watchpoints.

I also cleaned up, adjusted and added some more comments to the expect 
file. NR_BYTES was removed (it was useless), so now we use NR_THREADS to 
allocate the static array.

One more internal variable was added to the testcase to allow GDB to 
share its knowledge on the number of available hardware watchpoints. 
That way the testcase never expects more triggers than what is supposed 
to come.

The question here is how many threads we should spawn. I went with 10 
since that is often greater than the number of hardware watchpoints in a 
target.

How does it look?

Luis