From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6799 invoked by alias); 21 Oct 2002 19:08:47 -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 6679 invoked from network); 21 Oct 2002 19:08:43 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 21 Oct 2002 19:08:43 -0000 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 8EB2F8000E4 for ; Mon, 21 Oct 2002 15:08:42 -0400 (EDT) Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6C78B3EEB; Mon, 21 Oct 2002 14:53:28 -0400 (EDT) Message-ID: <3DB44D28.2090209@redhat.com> Date: Mon, 21 Oct 2002 12:08:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Klee Dienes Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Use read_memory_unsigned_integer when reading to CORE_ADDR References: <3F2B1B3E-D8F8-11D6-9DA9-00039396EEB8@apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00342.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). Just FYI, the MIPS tried to do this, and it lost badly! It also turned out that the MIPS case was just a simplification of the more generic harvard case and hence the core of GDB is being modified, as people notice, to use the pointer to address and address to pointer functions. Andrew