Re: [patch] improve hand-call-in-threads.exp failure handling

[Pedro Alves <palves at redhat dot com>]

On 09/06/2015 11:44 PM, Sandra Loosemore wrote:
> I've been looking at some apparent regressions in nios2-linux-gnu 
> gdbserver testing involving gdb.threads/hand-call-in-threads.exp.  It is 
> failing to stop at the breakpoint after switching to thread 2, with the 
> result that all subsequent tests are timing out because we've lost the 
> gdb prompt while the target is stuck running an infinite loop.  Getting 
> 30 more timeouts after the initial failure only slows down testing and 
> doesn't provide any useful information, so we might as well just give up 
> the first time.
> 
> Then I noticed that, while all these tests used to PASS, they weren't 
> really working, and never have, AFAICT.  Here's an excerpt from the 
> oldest archived test results I have handy (from a 2012-vintage gdb):
> 
> (gdb) PASS: gdb.threads/hand-call-in-threads.exp: hand call, thread 1
> thread 2
> Thread ID 2 not known.
> (gdb) PASS: gdb.threads/hand-call-in-threads.exp: prepare to make hand 
> call, thread 2
> call hand_call()
> 
> Breakpoint 3, hand_call () at 
> gdb/testsuite/gdb.threads/hand-call-in-threads.c:78
> 78	}
> The program being debugged stopped while in a function called from GDB.
> Evaluation of the expression containing the function
> (hand_call) will be abandoned.
> When the function is done executing, GDB will silently stop.
> (gdb) PASS: gdb.threads/hand-call-in-threads.exp: hand call, thread 2
> 
> Looks like the breakpoint hit test only appears to PASS because the 
> "thread" command was unsuccessful and we're still in thread 1.  And, the 
> .exp file doesn't do anything to confirm that the "thread" command was 
> successful.  Nowadays the "thread" command really does switch threads 
> here, but the .exp file still doesn't verify that it worked.
> 
> This patch tightens up the handling of both failure modes.  OK to commit 
> as a general testsuite robustness improvement?
> 
> This doesn't fix the broken nios2 behavior, of course.  I'm still 
> scratching my head....  kernel bug or something missing from the 
> gdbserver target back end?  :-S
> 

Looks fine to me.

Thanks,
Pedro Alves