From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31061 invoked by alias); 10 Aug 2004 07:24:30 -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 31053 invoked from network); 10 Aug 2004 07:24:29 -0000 Received: from unknown (HELO barry.mail.mindspring.net) (207.69.200.25) by sourceware.org with SMTP; 10 Aug 2004 07:24:29 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BuQzY-0002OU-00; Tue, 10 Aug 2004 03:24:16 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id CD4B74B102; Tue, 10 Aug 2004 03:24:23 -0400 (EDT) Date: Tue, 10 Aug 2004 07:24:00 -0000 From: Michael Chastain To: msnyder@redhat.com, manjo@austin.ibm.com Subject: Re: [RFC] New thread testcase. Cc: gilliam@us.ibm.com, gdb-patches@sources.redhat.com Message-ID: <41187827.nailB8H1E9AWV@mindspring.com> References: <4117F82B.nail1N111PN0T@mindspring.com> In-Reply-To: User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00352.txt.bz2 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?