From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31126 invoked by alias); 4 Feb 2002 17:01:45 -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 31070 invoked from network); 4 Feb 2002 17:01:44 -0000 Received: from unknown (HELO localhost.redhat.com) (24.114.26.18) by sources.redhat.com with SMTP; 4 Feb 2002 17:01:44 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7B6003E55; Mon, 4 Feb 2002 12:01:44 -0500 (EST) Message-ID: <3C5EBE78.1020500@cygnus.com> Date: Mon, 04 Feb 2002 09:01:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: Kevin Buettner Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: RFA: Do solib address arithmetic with appropriate truncation References: <20020203013131.C26295E9DE@zwingli.cygnus.com> <3C5D755D.4030201@cygnus.com> <1020204161424.ZM16473@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00082.txt.bz2 > There must be something around that this code can use. On something >> like a mips, this would be wrong - remember the sign extension problem. > > > I've never really understood the MIPS sign extension problem. Does it > occur when TARGET_PTR_BIT is smaller than the size of one or more of > the registers used to hold addresses? The MIPS ISA when running 32 bit code, sign extends pointers. GDB mimics this behavour. If it encounters a 32 bit pointer it will convert it to/from a cannonical form (sign extended CORE_ADDR for MIPS). Such pointers occure everywhere - debug info, registers, memory, ... By always sign extending, GDB avoids any potential inconsistency and latent bugs. POINTER_TO_ADDRESS and ADDRESS_TO_POINTER handle this. When debugging MIPS, the first thing to check is that CORE_ADDRs are sign exteded. A value like ``0x80001234'' as the patch would generate, indicate a bug. Interestingly, the SPARC is showing signs of the same, or similar, problems. enjoy, Andrew