From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30004 invoked by alias); 30 Oct 2006 16:55:17 -0000 Received: (qmail 29991 invoked by uid 22791); 30 Oct 2006 16:55:16 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-04.spheriq.net (HELO lon-del-04.spheriq.net) (195.46.50.101) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Oct 2006 16:55:03 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-04.spheriq.net with ESMTP id k9UGt0Bb014557 for ; Mon, 30 Oct 2006 16:55:00 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-01.spheriq.net with ESMTP id k9UGt0IE004482 for ; Mon, 30 Oct 2006 16:55:00 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id k9UGsvks010976 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 30 Oct 2006 16:54:59 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id A8163DA42 for ; Mon, 30 Oct 2006 16:54:57 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1781D47793 for ; Mon, 30 Oct 2006 16:54:55 +0000 (GMT) Received: from [164.129.15.13] (bri1043.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CID63314 (AUTH stubbsa); Mon, 30 Oct 2006 16:54:52 GMT Message-ID: <45462E5B.1020207@st.com> Date: Mon, 30 Oct 2006 16:55:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Problem with breakpoint addresses References: <452E8150.5090209@st.com> <1160682611.14535.191.camel@localhost.localdomain> <452F4C03.2010608@st.com> <20061013131900.GA9025@nevyn.them.org> <4546257E.50207@st.com> <20061030164414.GA11764@nevyn.them.org> In-Reply-To: <20061030164414.GA11764@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00302.txt.bz2 Daniel Jacobowitz wrote: > 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. Hmmm, well some of those platforms, such as sh64, like the current default behaviour as it is. Meanwhile, those that do not like it have the option of overriding it using integer_to_address. I assume those targets that don't have a 64 bit variant only care about this on 64 bit hosts, so only mips bothers to implement integer_to_address so far (AFAICS). Perhaps the correct fix is to define a default address width for each target variant, but that seems like more work than is really necessary. Should I post my patch or work up something else? Andrew