From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14982 invoked by alias); 9 Jan 2008 09:39:32 -0000 Received: (qmail 14972 invoked by uid 22791); 9 Jan 2008 09:39:31 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Jan 2008 09:39:10 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw2.br.ibm.com (Postfix) with ESMTP id 396FC17F6A9 for ; Wed, 9 Jan 2008 07:33:28 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m099d6oK4186330 for ; Wed, 9 Jan 2008 07:39:06 -0200 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m099d5jP024376 for ; Wed, 9 Jan 2008 07:39:06 -0200 Received: from [9.8.14.212] ([9.8.14.212]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m099d5NW024365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jan 2008 07:39:05 -0200 Subject: Re: [patch] Fix watch_thread_num testcase for ppc32 From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: Joel Brobecker Cc: gdb-patches@sourceware.org In-Reply-To: <20080109041508.GA21281@adacore.com> References: <1199849652.22083.20.camel@gargoyle> <20080109041508.GA21281@adacore.com> Content-Type: text/plain Date: Wed, 09 Jan 2008 09:39:00 -0000 Message-Id: <1199871500.22083.29.camel@gargoyle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00177.txt.bz2 On Tue, 2008-01-08 at 20:15 -0800, Joel Brobecker wrote: > > The watch_thread_num.exp testcase was timing out on a number of > > iterations for PPC32, while giving a full pass for PPC64. Removing the > > usleep(1) call fixed the problem. It gives full passes for both PPC > > 32/64. > > Would you mind sending the log files when it times out? I don't > understand why removing the usleep fixes the problem. I'm a bit > concerned with removing this delay because the thread would then > be free to eat up all the CPU, and the test is creating quite a > number of them... > > Thanks, The test will create a max of five threads, that will keep updating a shared variable. The reason why it times out is not really clear, i'm still investigating. When you hit continue in 32-bit, GDB seems to stand there doing something. It occurs from time to time. Sometimes it will stop due to the watchpoint, sometimes it will "lock". When you hit ctrl-C, it's clear that GDB is still executing the "nanosleep" function. That's what pointed me to usleep(). Regards, -- Luis Machado Software Engineer IBM Linux Technology Center