From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4323 invoked by alias); 6 Oct 2002 06:52:55 -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 4314 invoked from network); 6 Oct 2002 06:52:54 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 6 Oct 2002 06:52:54 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g966qrs13784 for ; Sat, 5 Oct 2002 23:52:53 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 5 Oct 2002 23:52:45 -0700 Received: from molly.local. (vpn-scv-x2-154.apple.com [17.219.193.154]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g966qqb01355; Sat, 5 Oct 2002 23:52:53 -0700 (PDT) Date: Sat, 05 Oct 2002 23:52:00 -0000 Subject: Re: [PATCH] Use read_memory_unsigned_integer when reading to CORE_ADDR Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: gdb-patches@sources.redhat.com To: Daniel Jacobowitz From: Klee Dienes In-Reply-To: <20021006025716.GA27734@nevyn.them.org> Message-Id: <3F2B1B3E-D8F8-11D6-9DA9-00039396EEB8@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00156.txt.bz2 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. 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). 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?