From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20923 invoked by alias); 30 Oct 2006 16:44:23 -0000 Received: (qmail 20915 invoked by uid 22791); 30 Oct 2006 16:44:23 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 30 Oct 2006 16:44:16 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GeaFC-0003Gi-CY for gdb@sourceware.org; Mon, 30 Oct 2006 11:44:14 -0500 Date: Mon, 30 Oct 2006 16:44:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: Problem with breakpoint addresses Message-ID: <20061030164414.GA11764@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <452E8150.5090209@st.com> <1160682611.14535.191.camel@localhost.localdomain> <452F4C03.2010608@st.com> <20061013131900.GA9025@nevyn.them.org> <4546257E.50207@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4546257E.50207@st.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00301.txt.bz2 On Mon, Oct 30, 2006 at 04:17:02PM +0000, Andrew STUBBS wrote: > Sorry it's taken me a little while to get back to this. > > Daniel Jacobowitz wrote: > >Secondly, this is just our use of CORE_ADDR as a native arithmetic type > >coming home to byte us. We knew it would someday. I think you should > >figure out where the sign extended CORE_ADDR was created, and why. > >I hope it was in value_as_address. This isn't a right final fix, but > >could you see if setting gdbarch_integer_to_address to a function that > >always uses extract_unsigned_integer helps? > > This fix does indeed solve the problem. Thanks. > > Why do you think this isn't the right final fix? I can't think of an > example of why this wouldn't always work until SH5, but the fix need not > affect that. I can't remember how my logic went. Should have written more of it down. Some day, I think we're going to need to do as Mark and Michael suggested; stop using CORE_ADDR so indiscriminately as a convenient integer type. In the mean time, perhaps everywhere that doesn't define integer_to_address should get a better default, or the fallback case in value_as_address should be changed, so that this is fixed equally on other platforms. -- Daniel Jacobowitz CodeSourcery