From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8669 invoked by alias); 19 Apr 2008 16:03:23 -0000 Received: (qmail 8661 invoked by uid 22791); 19 Apr 2008 16:03:22 -0000 X-Spam-Check-By: sourceware.org Received: from ns.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 19 Apr 2008 16:03:03 +0000 Received: from Relay2.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 550BD40979 for ; Sat, 19 Apr 2008 18:03:00 +0200 (CEST) From: Andreas Schwab To: gdb-patches@sourceware.org Subject: Re: [rfc, rfa/doc] Multi-threaded watchpoint improvements References: <20070916183949.GA23966@caradoc.them.org> <20071001002015.GA15835@caradoc.them.org> <20080416224910.GA3716@caradoc.them.org> <20080416231831.GB6274@caradoc.them.org> <20080417123455.GA25679@caradoc.them.org> X-Yow: He is the MELBA-BEING... the ANGEL CAKE... XEROX him... XEROX him -- Date: Sun, 20 Apr 2008 02:35:00 -0000 In-Reply-To: <20080417123455.GA25679@caradoc.them.org> (Daniel Jacobowitz's message of "Thu, 17 Apr 2008 08:34:55 -0400") Message-ID: User-Agent: Gnus/5.110008 (No Gnus v0.8) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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-04/txt/msg00411.txt.bz2 Daniel Jacobowitz writes: > On Thu, Apr 17, 2008 at 11:52:31AM +0200, Andreas Schwab wrote: >> Looking closer, it is actually a kernel bug. PTRACE_GETSIGINFO is not >> emulated for 32-bit processes, so that si_addr is set to the upper half >> of the address, which is of course zero. > > Glad you could track that down. Yes, my patch made GDB less tolerant > of targets which claim they can report the stopped data address, but > actually fail. It will only report watchpoints when the target > doesn't know what address has changed, or report a changed address > that falls on a particular watchpoint. This lets us keep track of > which thread hit each watchpoint. There is still a problem with that: if the watchpoint granularity is bigger than the size of the data then gdb can still get this wrong. On ppc64 the granularity is 8 bytes, so if you watch a 4 byte object you also get a trap if the other 4 bytes of the watched 8 bytes are modified, but gdb should ignore that trap. I think there needs to be a target hook to tell watchpoints_triggered the granularity. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."