This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] New thread testcase.


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]