From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27975 invoked by alias); 12 Mar 2003 15:51:29 -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 27968 invoked from network); 12 Mar 2003 15:51:29 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 12 Mar 2003 15:51:29 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18tAP5-00057t-00; Wed, 12 Mar 2003 11:52:35 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18t8Vg-0000yX-00; Wed, 12 Mar 2003 10:51:16 -0500 Date: Wed, 12 Mar 2003 15:51:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michael Elizabeth Chastain , 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: <20030312155116.GA3669@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michael Elizabeth Chastain , stcarrez@nerim.fr, brobecker@gnat.com, gdb@sources.redhat.com, kettenis@chello.nl References: <200303021659.h22Gxc908446@duracef.shout.net> <3E6F53B3.6010803@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E6F53B3.6010803@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00180.txt.bz2 On Wed, Mar 12, 2003 at 10:35:15AM -0500, Andrew Cagney wrote: > >Okay, I got some sleep and drank some tea and stuff. I'm a bit more > >calm now. :) > > > >I filed a proper PR, so that Daniel J (or anybody) can flow it into > >their TODO list. Daniel said he has several things to do in this code > >so I want to get in line properly. > > > >I did mark it severity=critical because gdb prints incorrect values, and > >priority=high because Stephane C says that it happens a lot on the HC11. > > > >gdb 5.3 has a different bug in the same area, so this is only sort-of a > >regression. The specific program store.exp in the test suite regressed > >between 2003-02-15 and 2003-02-23, but my test program r8.c in the PR is > >busted with both gdb 5.3 and gdb 2003-03-01-cvs. > > Shouldn't the new code have been made conditional until it at least > equalled the functionality of the old mechanism? > > By failing to do this to do this, the next release of GDB has gained a > dependency on the timetable of an internal change. That is bad. 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. I was also not aware that we had sketchy multi-register support until it was pointed out to me, because the support isn't in any of the places I was working in directly; it's off in the generic value code, isn't it? So I didn't know this was going to happen. We have a plan to fix it, too. Mark posted it, and then ran out of time (?). You didn't like his plan because: I think it is very dangerous. It's assuming a specific algorithm in the compiler. That locks both GDB and GCC into something of a death spiral. I think its far better to try and get a proper location mechanism working. Well, that's what we did before, in the "old mechanism", and we don't have any new debug info that we didn't have then so it's what we need to keep doing until support for the new debug info is ready (then GCC can emit it more broadly). By the way, you wrote: On Sun, Feb 02, 2003 at 11:14:29AM -0500, Andrew Cagney wrote: > If only it were that easy. The dwarf2 reader, for instance, also > contains the assumption that registers are allocated sequentially. > > Is the proposal to modify such readers so that they check against this > next_allocated_regnum algorithm? And I wrote back: > Where? I can't find this; it doesn't even acknowledge multi-register > values. I still don't understand what code you're referring to in the reader. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer