From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27152 invoked by alias); 6 Oct 2002 15:09:02 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27145 invoked from network); 6 Oct 2002 15:09:01 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 6 Oct 2002 15:09:01 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17yDxV-0007Qd-00; Sun, 06 Oct 2002 11:08:45 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17yD2E-00068x-00; Sun, 06 Oct 2002 11:09:34 -0400 Date: Sun, 06 Oct 2002 08:09:00 -0000 From: Daniel Jacobowitz To: Klee Dienes Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Use read_memory_unsigned_integer when reading to CORE_ADDR Message-ID: <20021006150934.GA23448@nevyn.them.org> Mail-Followup-To: Klee Dienes , gdb-patches@sources.redhat.com References: <20021006025716.GA27734@nevyn.them.org> <3F2B1B3E-D8F8-11D6-9DA9-00039396EEB8@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F2B1B3E-D8F8-11D6-9DA9-00039396EEB8@apple.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-10/txt/msg00158.txt.bz2 On Sun, Oct 06, 2002 at 02:52:57AM -0400, Klee Dienes wrote: > Perhaps something along the lines of the following? > > { > unsigned char buf[sizeof (CORE_ADDR)]; > if (target_read_memory (memaddr, buf, TYPE_LENGTH > (builtin_type_void_data_ptr)) != 0) > error ("Unable to determine lower bound of array."); > *lower_bound = extract_typed_address (buf, > builtin_type_void_data_ptr); > } > > That's a bit verbose, and it's not clear to me if sizeof (CORE_ADDR) is > guaranteed to be large enough to contain a raw target pointer, but I > can't really think of any better alternatives. Might want to use alloca (TYPE_LENGTH (builtin_type_void_data_ptr)). > Aside from the intimidating comments in findvar.c, this would seem a > good candidate for extract_address ... though a similar modification > would have to be made to it to handle the sign-extension as well. > > Or alternately, I could just leave well-enough alone, and be careful to > truncate CORE_ADDRs to 32 bits in our target xfer_memory code (or the > MIPS code could sign-extend it in the same place). Well, I think a general read_memory_typed_address (returning CORE_ADDR, and honoroing POINTER_TO_ADDRESS) would be the way to go here. > > On Saturday, October 5, 2002, at 10:57 PM, Daniel Jacobowitz wrote: > > > >Well, I'm a little concerned about this. MIPS generally wants the > >result to be sign extended; the MIPS 32-bit ABIs map onto the lowest > >and highest 2G segments of the 64-bit address space, not the low 4G > >segment. Isn't there an appropriate function somewhere to read a > >CORE_ADDR? > > > >Answer: Yes, there is, but it has the same problem. You're just > >extending current practice, so I don't see a problem with your patch. > > > >Andrew, is my understanding right? Is there some reason this isn't a > >problem? > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer