From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15343 invoked by alias); 12 Mar 2003 17:01:06 -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 15330 invoked from network); 12 Mar 2003 17:01:05 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 12 Mar 2003 17:01:05 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18tBUR-0005GP-00; Wed, 12 Mar 2003 13:02:11 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18t9b2-0003Qj-00; Wed, 12 Mar 2003 12:00:52 -0500 Date: Wed, 12 Mar 2003 17:01: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: <20030312170052.GA31979@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> <20030312155116.GA3669@nevyn.them.org> <3E6F670D.4030205@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E6F670D.4030205@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00183.txt.bz2 On Wed, Mar 12, 2003 at 11:57:49AM -0500, Andrew Cagney 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. > > > >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. > > There are other ways forward on this - moving the algorithm to libiberty > (like the demangler). This is a target-specific allocation order, for communication between GCC and GDB, not a matter of published interfaces - I don't think it belongs in libiberty. It's subject to change, but I have a reasonable expectation that it won't change until after debugging info to express it is available. In any case I'm going back to working on locations as objects, which is the next step in fixing this properly. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer