Re: [RFC] New thread testcase.

[Michael Snyder <msnyder@redhat.com>]

Hello Manoj,

> #
> # step through the thread function.
> #
> send_gdb "step\n"
> gdb_expect {
>     -re "39.*sprintf.* .*\r\n$gdb_prompt $" {
>         pass "step to next instruction in tf";
>     }
>     -re ".*$gdb_prompt $" {
>         fail "step to next instruction in tf";
>         return 1;
>     }
>     timeout {
>         fail "step to next instruction in tf (timeout)";
>         return 1;
>     }
> }

This will probably work as written, but it hints at a faulty
assumption that might lead it to break if the test is modified
in the future.

When you say "step", you allow the opportunity for the inferior
to switch thread contexts.  At present there are only two threads,
and no other breakpoints exist that might be hit, but if that were
not the case, the next stop event could be at another breakpoint,
in another thread.  This would not be a bug, and should not cause
a fail.  It's expected behavior.

I suppose this could be addressed with a comment, warning the
future maintainer to take it into consideration if more threads
or breakpoints are added.

But like Andrew, I would also like to know what the expected
failure is -- what used to happen before the kernel bug was
fixed?  A comment explaining that would be welcome too.

Michael Snyder