From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14820 invoked by alias); 30 Dec 2009 03:13:09 -0000 Received: (qmail 14811 invoked by uid 22791); 30 Dec 2009 03:13:08 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e24smtp02.br.ibm.com (HELO e24smtp02.br.ibm.com) (32.104.18.86) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Dec 2009 03:13:03 +0000 Received: from mailhub3.br.ibm.com (mailhub3.br.ibm.com [9.18.232.110]) by e24smtp02.br.ibm.com (8.14.3/8.13.1) with ESMTP id nBU3H5VI008211 for ; Wed, 30 Dec 2009 01:17:05 -0200 Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.8.31.93]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBU3EwDq1908936 for ; Wed, 30 Dec 2009 01:14:58 -0200 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nBU3D0Ou032227 for ; Wed, 30 Dec 2009 01:13:00 -0200 Received: from hactar.localnet ([9.18.196.37]) by d24av02.br.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nBU3CxRx032224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Dec 2009 01:12:59 -0200 From: Thiago Jung Bauermann To: Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Support the new PPC476 processor Date: Wed, 30 Dec 2009 03:13:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.30-2-686; KDE/4.3.2; i686; ; ) Cc: luisgpm@linux.vnet.ibm.com, tyrlik@us.ibm.com References: <200912161847.17162.sergiodj@linux.vnet.ibm.com> <83y6l060qp.fsf@gnu.org> In-Reply-To: <83y6l060qp.fsf@gnu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912300112.13363.bauerman@br.ibm.com> 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: 2009-12/txt/msg00424.txt.bz2 Hi Eli, Thanks for the review! On Fri 18 Dec 2009 08:21:50 Eli Zaretskii wrote: > I have a few preliminary comments and questions about the proposed UI: > > * Simple Hardware Watchpoints: Monitors accesses to a single data > > address. For the PPC476, 2 of them are available provided that no > > Range/Mask watchpoints are being used. There is also the possibility of > > using conditions when monitoring the values. In this case, GDB will > > place the condition inside a register, and the evaluation will be > > hardware-accelerated, which will speed- up significantly the debugging > > process. The PPC476 processor has two registers that can be used to > > hardware-accelerate the condition evaluation. > > > > - Available GDB commands: [r|a]watch (rwatch/awatch/watch) > > or [r|a]watch if == <4-bytes unsigned constant> > > > > - Usage example: awatch i / rwatch *0xbffff8e8 / watch i if i == 28 > > Will GDB decide automatically whether to use hardware-accelerated > conditions or the current implementation, whereby an unconditional > hardware watchpoint is set, and when it breaks, GDB itself evaluates > the condition? I think this should be done automatically. Yes, GDB will use hardware-accelerated conditions automatically, when available on the target. > > * Range Hardware Watchpoints: Monitors accesses to an interval of data > > addresses. For the 476, a single Range Hardware Watchpoint can be used > > provided that no Simple/Mask watchpoints are being used. > > > > - Available GDB commands: [r|a]watch-range : > +>, where <= > > (rwatch-range/awatch-range/watch- range) > > > > - Usage example: watch-range &i,&k / awatch-range > > 0xbffff8e8,0xbffff8f8 / rwatch-range 0xbffff8e8,+8 > > Why is there a need for a separate GDB command? What are the > use-cases where the user would want to watch a region that is spanned > by more than one (albeit large) variable? If such use-cases are > infrequent enough or obscure, then we could simply use the normal > watch commands, and support any corner use-cases with something like > > watch *0xbffff8e8@8 > > using what is a normal GDB semantics for artificial arrays. IOW, no > need for either the comma-separated list of 2 addresses or a separate > command. I agree that it is convenient to support ranged watchpoints with an established GDB syntax. So I implemented that. If the user asks to watch an array (natural or artificial) or struct, and ranged watchpoints are available then it will use them automatically. I'm reluctant to remove the watch-range command though, because with the artificial array syntax it's not straightforward to say "watch len *bytes* starting at addr". Using: watch *addr@len is not correct, since it will watch len *integers* starting at addr. To do what he/she wants, the user will have to type: watch *((char *) addr)@len Compare with: watch-range addr, +len (or perhaps I'm missing a simpler way to use artificial arrays in the example above..) > > * Mask Hardware Watchpoints: Monitors accesses to data addresses that > > match a specific pattern. For the 476, a single Mask Hardware Watchpoint > > can be used provided that no Simple/Range watchpoints are being used. > > Due to the processor's design, the precise data address of the watchpoint > > trigger is not available, so the user must check the instruction that > > caused the trigger (usually at PC - 4) to obtain such data address. With > > such data address in hand, it's possible to tell if its contents have > > changed. > > > > - Available GDB commands: [r|a]watch mask > > > > > > - Usage example: watch i mask 0xffffff00 / awatch *0xbffff8e8 mask > > 0xffffff00 > > I'm not sure about the semantics of this: what exactly does the mask > do? how does it modify the unmasked command for the same address? The mask makes the processor ignore the address bits that are 0 in the mask when matching the data access address. In the example above, the watchpoint will hit whenever there's a memory access to an address that is equal to the address of i, but ignoring the last eight bits in the comparison. The PowerPC 440 user manual has an interesting example: This comparison mode is useful for detecting accesses to a particular byte address, when the accesses may be of various sizes. For example, if the debugger is interested in detecting accesses to byte address 0x00000003, then these accesses may occur due to a byte access to that specific address, or due to a halfword access to address 0x00000002, or due to a word access to address 0x00000000. By using address bit mask mode and specifying that the low-order two bits of the address should be ignored (that is, setting the address bit mask in DAC2 to 0xFFFFFFFC), the debugger can detect each of these types of access to byte address 0x00000003. > > * Range Hardware Breakpoint: Monitors an interval of instruction > > addresses. > > > > - Available GDB commands: hbreak-range : > +> where <= / hbreak-range > > : > > > > - Usage example: hbreak-range 0x10000658,0x10000660 / hbreak-range > > 0x10000658,+8 / hbreak-range 20,30 > > Again, what are the use-cases where such breakpoints would be useful? They don't seem to be useful for C-level debugging, but can be for assembly- level debugging. For instance, if you have a block of code that has more than one entrypoint and therefore you don't know where it will get jumped into, you can put a ranged breakpoint to cover the entire block. -- []'s Thiago Jung Bauermann IBM Linux Technology Center