From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13070 invoked by alias); 30 Dec 2009 22:15:45 -0000 Received: (qmail 13062 invoked by uid 22791); 30 Dec 2009 22:15:44 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Dec 2009 22:15:39 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 9B04C10DAA; Wed, 30 Dec 2009 22:15:37 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 811F110D9E; Wed, 30 Dec 2009 22:15:36 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1NQ6pL-0006hh-9C; Wed, 30 Dec 2009 17:15:35 -0500 Date: Wed, 30 Dec 2009 22:15:00 -0000 From: Daniel Jacobowitz To: Thiago Jung Bauermann , Eli Zaretskii Cc: gdb-patches@sourceware.org, luisgpm@linux.vnet.ibm.com, tyrlik@us.ibm.com Subject: Re: [PATCH 0/2] Support the new PPC476 processor Message-ID: <20091230221535.GA25399@caradoc.them.org> Mail-Followup-To: Thiago Jung Bauermann , Eli Zaretskii , gdb-patches@sourceware.org, luisgpm@linux.vnet.ibm.com, tyrlik@us.ibm.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831vicdwd0.fsf@gnu.org> <200912300112.13363.bauerman@br.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00454.txt.bz2 On Wed, Dec 30, 2009 at 01:12:13AM -0200, Thiago Jung Bauermann wrote: > 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 This unintuitive command should also work: watch {char[len]} addr It's not a very nice syntax though. > 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. Also consider an unknown shared library as a block of code with multiple entry points. On Wed, Dec 30, 2009 at 10:45:31PM +0200, Eli Zaretskii wrote: > > watch-range addr, +len > > What would be the use-case for watching a range of addresses that is > not an integral multiple of a variable's size? With literal numbers GDB will use units of ints instead of bytes: (gdb) ptype 0x10000000@32 type = int [32] So "watch 0x10000000@32" will not have the expected effect. This is more likely to be useful when specifying the bare address rather than a C-level variable, I think. > Thanks for the explanations. I think we should emulate this on > architectures that don't have this in hardware (it doesn't sound > hard). How do you mean? It seems basically impossible to me. -- Daniel Jacobowitz CodeSourcery