From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29275 invoked by alias); 9 Sep 2002 16:28:25 -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 29257 invoked from network); 9 Sep 2002 16:28:24 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 9 Sep 2002 16:28:24 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g89GC7126869 for ; Mon, 9 Sep 2002 12:12:07 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g89GSLd18079; Mon, 9 Sep 2002 12:28:22 -0400 Received: from romulus.sfbay.redhat.com (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g89GSLC31457; Mon, 9 Sep 2002 09:28:21 -0700 Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g89GSJi14376; Mon, 9 Sep 2002 09:28:19 -0700 Date: Mon, 09 Sep 2002 09:28:00 -0000 From: Kevin Buettner Message-Id: <1020909162819.ZM14375@localhost.localdomain> In-Reply-To: Fred Fish "[RFC] Another 64 bit CORE_ADDR & 32 bit target address printing botch" (Sep 7, 11:33pm) References: <200209080433.g884XU302357@beeville.vert.intrinsity.com> To: fnf@intrinsity.com, gdb-patches@sources.redhat.com Subject: Re: [RFC] Another 64 bit CORE_ADDR & 32 bit target address printing botch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-09/txt/msg00120.txt.bz2 On Sep 7, 11:33pm, Fred Fish wrote: > I found another place where 32 bit addresses with the MSB set are printed > as 0xffffffffxxxxxxxx. I hacked around the problem with this patch, > but it might not be the best place to do it. Any better ideas? Was this on MIPS? Aren't these addresses supposed to be sign extended on MIPS? In any event, if the address stored in the CORE_ADDR is incorrect, I think it'd be better to fix it at the point where it's being stored incorrectly. Kevin