[RFC] New thread testcase.

[Manoj Iyer]

Wow! Michael,

That was really great feedback! A very through review, even typos! I will
fix the testcase with the changes you mentioned and submit again.

Andrew,

yes, manythreads.c and tbug.c look similar, but the tests (*.exp) intend
to test different things. (I believe). My testcase intends to check if we
can set a breakpoint at a thread function, step thro it, backtrace from
it, delete breakpoints and run to completion.

Is there a quick reference list of testcases with Assertion/Strategy ??

Thanks a ton!
----- ----
Manoj Iyer
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Cognito ergo sum                                                          +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

On Tue, 10 Aug 2004, Michael Chastain wrote:

> Hi Manoj,
>
> I am not the maintainer of gdb.threads -- that is Michael Snyder.
> (See the gdb/MAINTAINERS file for a list of who maintains what
> subdirectory).  You'll have to work with Michael Snyder on this
> patch.  I can give you some feedback though.
>
> The basic idea of the test is good but it needs revision.  Don't get
> discouraged by the long list that follows.  I spent some time
> proof-reading this because I think it's good and I want it to get in.
>
> Also, since this is Michael Snyder's area, anything he says
> outweighs anything I say.  The changes below are just my advice.
>
> Michael C
>
> ===
>
>   tbug.c
>
>     I think this name is too generic.  gdb.threads is full of
>     files which are about thread bugs.
>
>   * Please email any bugs, comments, and/or additions to this file to:
>   * bug-gdb@prep.ai.mit.edu
>
>     Drop this part, bug-gdb@prep.ai.mit.edu is dead.
>
>   sleep(2);
>
>     See the call to sleep() in gdb.mi/pthreads.c:
>
>       /* When gdb is running, it sets hidden breakpoints in the thread
> 	 library.  The signals caused by these hidden breakpoints can
> 	 cause system calls such as 'sleep' to return early.  Pay attention
> 	 to the return value from 'sleep' to get the full sleep.  */
>       int unslept = 9;
>       while (unslept > 0)
> 	unslept = sleep (unslept);
>
>     All the sleep() calls in gdb.threads need to be like this.
>     See gdb.texinfo, section "Stopping and starting multi-thread
>     programs", for more information on this.
>
>   thread_check.exp
>
>     Same complaint about the name.
>
>   'bracktrace'
>
>     Typo.
>
>   'On ppc64 system this test is known to fail due to kernel bug
>    in ptrace system call.'
>
>     This is a start, but more info please.  ppc64 is just a processor,
>     we need a whole gnu triple here, like ppc64-unknown-linux-gnu.
>     Run 'config.guess' on the system where it fails and report that
>     info.  Also run 'uname -a' and get the kernel version.  And it
>     would help to report the libc / glibc version as well.
>
>   send_gdb / gdb_expect
>
>     We are moving away from those to gdb_test_multiple.
>     With gdb_test_multiple, you don't need the default FAIL case
>     and the timeout case.
>
>   send_gdb "delete\n"
>   gdb_expect 100 {
>
>     Drop the timeout, you should not need a special timeout
>     for deleting breakpoints.
>
>   -re "39.*sprintf.* .*\r\n$gdb_prompt $" {
>
>     Do not use absolute line numbers!  Call gdb_get_line_number to
>     get the line number you want.
>
>       set marker_1 [gdb_get_line_number "marker 1"]
>       ...
>       -re "$marker_1.*sprintf.* .*\r\n$gdb_prompt $" {
>
>     Then in the test program, do this:
>
>       sprintf(number, "tf(%ld): begin", (long)arg); /* marker 1 */
>
>   -re ".*3.* .*0x.* in clone.* from .*libc.*$" {
>
>     This is not generic enough.  There's no guarantee that
>     pthread_create is implemented with clone.  For your purposes,
>     is it good enough to look for pthread_create on the stack?
>