From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18416 invoked by alias); 24 Apr 2007 18:13:13 -0000 Received: (qmail 18396 invoked by uid 22791); 24 Apr 2007 18:13:12 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Apr 2007 19:13:10 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id D71064B267 for ; Tue, 24 Apr 2007 13:13:08 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id BAB8B4B262 for ; Tue, 24 Apr 2007 13:13:08 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HgPVk-0006vA-8V for gdb-patches@sourceware.org; Tue, 24 Apr 2007 14:13:08 -0400 Date: Tue, 24 Apr 2007 21:34:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: [RFC] dwarf2_read_address(): sign extend as appropriate Message-ID: <20070424181308.GA26543@caradoc.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <20070420163312.56701614@ironwood.lan> <200704231505.l3NF5KV5025451@d12av02.megacenter.de.ibm.com> <20070423094900.15a047d2@ironwood.lan> <20070423165646.GA15110@caradoc.them.org> <20070423140642.3920579e@ironwood.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070423140642.3920579e@ironwood.lan> User-Agent: Mutt/1.5.15 (2007-04-09) 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: 2007-04/txt/msg00320.txt.bz2 On Mon, Apr 23, 2007 at 02:06:42PM -0700, Kevin Buettner wrote: > dwarf2_read_address() isn't reading an address from some value in the > inferior, but rather is decoding some sequence of bytes as an address > in the DWARF2 info. As such, dwarf2_read_address() doesn't have > anything readily available to pass to value_as_address(). That means > that a suitable value would have to be constructed and then immediately > decomposed, leading to an expression which might look something like this: > > result = value_as_address (value_from_longest > (unsigned_address_type (), > extract_unsigned_integer > (buf, > TARGET_ADDR_BIT / TARGET_CHAR_BIT))); > > Please let me know if this is what you had in mind. If so, I'll > try it out and post the results. That is what I had in mind - we have an interface for doing arithmetic with target values, but there's all sorts of places we do not use it. But if you're justifiably offended by the inefficiency, let's not do it now. Your original patch is fine with me. (If you fix the formatting issues "struct type *" shouldn't be followed by a space, "unsigned_address_type()" should have one.) -- Daniel Jacobowitz CodeSourcery