From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22239 invoked by alias); 23 Oct 2002 05:35:08 -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 22225 invoked from network); 23 Oct 2002 05:35:07 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 23 Oct 2002 05:35:07 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C27783CCB; Wed, 23 Oct 2002 01:24:50 -0400 (EDT) Message-ID: <3DB632A2.4010003@redhat.com> Date: Tue, 22 Oct 2002 22:35: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: "Martin M. Hunt" Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] string_to_core_addr fix References: <200210101507.46548.hunt@redhat.com> <1021010223959.ZM14496@localhost.localdomain> <200210102129.52218.hunt@redhat.com> <1021011065646.ZM14913@localhost.localdomain> <3DB45E39.9000102@redhat.com> <1035342441.19691.112.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00456.txt.bz2 > On Mon, 2002-10-21 at 13:06, Andrew Cagney wrote: > > >> Insight parse_and_eval_address() was simply bogus. See the thread >> around the original introduction of these functions. > > > I looked. All I found was something about parse_and_eval_address() > being broken for harvard arch. Sigh, looks like it was private e-mail :-( >> A short summary is >> that parse_and_eval_address() does conversions like you describe and >> none are needed. Instead functions that parse in, write out, raw >> CORE_ADDR values are needed. > > > I believe we have target addrs and CORE_ADDRs, where CORE_ADDRs are > sometimes target addrs sign-extended to 64-bits. Is that not right? (not sure what `sometimes' was bound too) A CORE_ADDR always contains an address converted to a canonical form. For the MIPS (32 or 64 bit), when GDB is debugging a 32 bit ABI, the CORE_ADDR will always contain a canonical value that has been created by sign-extending the 32 bit pointer or register value. >>>From memory, you print out a target addr by using paddr_nz. If you > wanted to print a CORE_ADDR you would use core_addr_to_string_nz. You > can read in a CORE_ADDR with string_to_core_addr. So how do you read in > a target addr and have it converted to a CORE_ADDR? (is core_addr_to_string_nz() used?) Addresses are ment to be displayed using print_address_numeric() and similar. A user specified value would be parsed with something like parse_and_eval_address(). On the other hand, string<->core_addr() is used as a way for Insight to create an internal address handle (for saving things like frames). The user should not be able to access or manipulate such values directly. > >> I believe that this change is wrong and should be reverted. > > > By your definition of string_to_core_addr below, I agree. However, this > bug has been here a long time and I would like some agreement on how it > should properly be fixed. I know of several ongoing bugs: - GDB forgetting to convert a pointer into a core_addr - GDB/Insight incorrectly interchanging addresses and core_addr > The bug is simply that Insight gets CORE_ADDRs for any symbol lookup. > It must convert them to strings and uses paddr_nz. Then the user does > something with that address and Insight converts that address string > back into a CORE_ADDR incorrectly (it doesn't sign-extend to 64-bits, > therefore my patch). That code is definitly wrong. The equality: core_addr == string_to_core_addr (paddr_nz (core_addr)) does NOT hold. The code should either: - use string <-> core_addr() and not let the user directly manipulate the values (insight could manipulate it though). - Convert the CORE_ADDR back into an address, let the user manipulate the address, and then use parse_and_eval_address() to get the core_addr back. Not sure how well this would go with harvard architectures though - for them, a simple address may not be sufficient for re-constructing the CORE_ADDR. Any way, the patch should be reverted. Andrew