From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16436 invoked by alias); 12 Mar 2003 19:00:13 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16429 invoked from network); 12 Mar 2003 19:00:12 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 12 Mar 2003 19:00:12 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18tDLc-0005Xj-00; Wed, 12 Mar 2003 15:01:12 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18tBSC-0007BE-00; Wed, 12 Mar 2003 13:59:52 -0500 Date: Wed, 12 Mar 2003 19:00:00 -0000 From: Daniel Jacobowitz To: Paul Koning Cc: ac131313@redhat.com, mec@shout.net, stcarrez@nerim.fr, brobecker@gnat.com, gdb@sources.redhat.com, kettenis@chello.nl Subject: Re: 8-byte register values on a 32-bit machine Message-ID: <20030312185952.GA27508@nevyn.them.org> Mail-Followup-To: Paul Koning , ac131313@redhat.com, mec@shout.net, stcarrez@nerim.fr, brobecker@gnat.com, gdb@sources.redhat.com, kettenis@chello.nl References: <200303021659.h22Gxc908446@duracef.shout.net> <3E6F53B3.6010803@redhat.com> <20030312155116.GA3669@nevyn.them.org> <3E6F7C6F.2030805@redhat.com> <20030312183517.GA26765@nevyn.them.org> <15983.36589.555000.415537@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15983.36589.555000.415537@gargle.gargle.HOWL> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00194.txt.bz2 On Wed, Mar 12, 2003 at 02:47:57PM -0500, Paul Koning wrote: > >>>>> "Daniel" == Daniel Jacobowitz writes: > > Daniel> On Wed, Mar 12, 2003 at 01:29:03PM -0500, Andrew Cagney > Daniel> wrote: > >> > >The new code fixes some reported wrong-value-reported bugs in > >> other >debugging >situations; one of them was reported just > >> recently. So I don't think >'equalled the functionality of the > >> old mechanism' is really quite fair. > >> > >> True. However, breaking `long long' is a serious regression. If > >> a developer can't trust that, what can they trust? > > Daniel> Historically it hasn't been all that trustable anyway. I > Daniel> don't have a testcase handy but CORE_ADDRs in GDB backtraces > Daniel> tend to be wrong, even when they're properly saved to the > Daniel> stack. Et cetera. > > I don't like the way this discussion is going. Perhaps I'm reading > too much into the words. A quick review of the thread doesn't help > make it clearer. > > We have a large body of code full of long long variables, compiled for > MIPS using the o32 ABI. So each of those ends up in a register pair. > > I'm not aware of any reported problems in dealing with long long > variables on that platform. > > So... if the current proposal has the side effect of breaking that > working function, on the grounds that it "wasn't all that reliable", > I've got to ask why that's a valid argument. I don't know if it would break or not. > If that's not the current proposal, could you reword it to help > eliminate the confusion over what you intend? No one is proposing to leave it broken. To pull up an example from earlier in the thread, Andrew broke x86-64 when working on the frame changes. It was an accident, and eventually fixed (by Michal Ludvig, I might add). I apparently broke long long (in registers) in some of my DWARF-2 support patches. I'm working to fix it. I'm only one person and I only have so much time. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer