From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32478 invoked by alias); 19 Feb 2010 19:27:01 -0000 Received: (qmail 32373 invoked by uid 22791); 19 Feb 2010 19:27:00 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Feb 2010 19:26:55 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1JJQr2U006101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 19 Feb 2010 14:26:53 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o1JJQrSP016754; Fri, 19 Feb 2010 14:26:53 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o1JJQqKT005140; Fri, 19 Feb 2010 14:26:52 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id D3942378212; Fri, 19 Feb 2010 12:26:51 -0700 (MST) From: Tom Tromey To: gdb@sourceware.org Subject: Re: CORE_ADDR representation References: <20100218044416.GA19485@caradoc.them.org> <201002181017.o1IAHDdS030942@glazunov.sibelius.xs4all.nl> <20100218134345.GB17163@caradoc.them.org> Reply-To: tromey@redhat.com Date: Fri, 19 Feb 2010 19:27:00 -0000 In-Reply-To: <20100218134345.GB17163@caradoc.them.org> (Daniel Jacobowitz's message of "Thu, 18 Feb 2010 08:43:45 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2010-02/txt/msg00146.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Mark> Perhaps we should introduce a function to "normalize" addresses (mask Mark> off high-bits or sign extend) that we call in places that need it? Mark> It'd be a no-op for a N-bit debugger debugging an N-bit target, so Mark> you'd be able to call it unconditionally. That should clear away Mark> quite a bit of clutter. Daniel> That does sound better than the status quo. I worry that we'll have Daniel> otherwise the same trouble with figuring out places that 'need' it... Daniel> Hmm. I wonder if we could use a static analysis tool for this. It Daniel> sounds like a classic example of a static problem. The appended finds all uses of "+" on a CORE_ADDR. Well... it finds "all" uses modulo whatever little issues coccinelle has, I didn't mess around trying to make it look into macros. I ran it like: cd src/gdb spatch -sp_file coreaddr.cocci -dir . ... and got 1071 hits. On Fedora you can get the tool with "yum install coccinelle", I assume other distros are similar. Also it is here: http://coccinelle.lip6.fr/ I'm not sure if this was what you're really looking for, but it isn't too hard to modify this script to look for other things. The problem with doing static analysis is that you have to redo it pretty frequently. While moving to a struct CORE_ADDR would result in more verbose code (which is definitely bad, don't get me wrong), it does have the benefit that an attempt to do arithmetic on it results in a compiler error. This in turns means it is simpler to review the resulting patches. Tom @ coreaddr @ CORE_ADDR x; expression y; position p_1; @@ x @p_1 + y @ script:python @ loc_1 << coreaddr.p_1; @@ print "%s:%s:%s: CORE_ADDR + operation" % (loc_1[0].file, loc_1[0].line, loc_1[0].column)