From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3824 invoked by alias); 14 Aug 2007 16:21:14 -0000 Received: (qmail 3674 invoked by uid 22791); 14 Aug 2007 16:21:13 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Aug 2007 16:21:02 +0000 Received: from mailhub1.br.ibm.com (unknown [9.18.232.109]) by igw3.br.ibm.com (Postfix) with ESMTP id 50628390144 for ; Tue, 14 Aug 2007 13:14:52 -0300 (BRT) 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.5) with ESMTP id l7EGKxlF1785988 for ; Tue, 14 Aug 2007 13:20:59 -0300 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 l7EGKxsg026169 for ; Tue, 14 Aug 2007 13:20:59 -0300 Received: from dyn532126.br.ibm.com (dyn532126.br.ibm.com [9.18.238.250]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7EGKx41026166 for ; Tue, 14 Aug 2007 13:20:59 -0300 Subject: Watchpoints stopping GDB on specific threads From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: gdb@sourceware.org Content-Type: text/plain Date: Tue, 14 Aug 2007 16:21:00 -0000 Message-Id: <1187108458.4388.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00113.txt.bz2 Folks, GDB currently has support for conditional breakpoint stops on specific threads, by issuing the command "break thread ". I'm looking forward to have the same functionality for watchpoints. So whenever GDB detects a watchpoint trigger, it would verify the current thread and would stop only if the thread matches the ID we provided in a command like "watch
thread ". if no ID is provided, GDB would stop at every thread as usual (assuming a threaded watchpoint support). This is useful to conduct debugging sessions on applications with a great number of threads, being able to inspect just the thread we're interested in. It would also take advantage of the upcomming threaded watchpoint support, hopefully. At a first glance, i'd need to work in a different way than the breakpoint case, because the entire watchpoint expression is handled by a expression parser. It automatically processes the "thread " parameter and of course gives an error because that's not recognized. Do you have any idea on how this could be solved in a clever way? We could start parsing the expression from the end, and try to locate the "thread " parameter, and then hand over the remaining parameters to the expression parser. What do you think? Best regards, -- Luis Machado Software Engineer IBM Linux Technology Center LoP Toolchain/Debuggers' team Phone: +55 19-2132-2218 T/L: 839-2218 e-mail: luisgpm@vnet.linux.ibm.com