From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22149 invoked by alias); 10 Aug 2004 20:13:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22084 invoked from network); 10 Aug 2004 20:13:09 -0000 Received: from unknown (HELO e32.co.us.ibm.com) (32.97.110.130) by sourceware.org with SMTP; 10 Aug 2004 20:13:09 -0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i7AKCnmL533902; Tue, 10 Aug 2004 16:12:49 -0400 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7AKClM4382302; Tue, 10 Aug 2004 14:12:49 -0600 Received: from lazy.austin.ibm.com (lazy.austin.ibm.com [9.53.94.97]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id i7AKClSZ024590; Tue, 10 Aug 2004 15:12:47 -0500 Date: Tue, 10 Aug 2004 20:13:00 -0000 From: Manoj Iyer X-X-Sender: manjo@lazy To: Michael Chastain cc: msnyder@redhat.com, gilliam@us.ibm.com, gdb-patches@sources.redhat.com Subject: Re: [RFC] New thread testcase. In-Reply-To: <41187827.nailB8H1E9AWV@mindspring.com> Message-ID: References: <4117F82B.nail1N111PN0T@mindspring.com> <41187827.nailB8H1E9AWV@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-08/txt/msg00370.txt.bz2 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? >