From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6679 invoked by alias); 2 Feb 2003 05:21:21 -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 6669 invoked from network); 2 Feb 2003 05:21:20 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 2 Feb 2003 05:21:20 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18fES8-0007lB-00; Sun, 02 Feb 2003 01:22:09 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18fCZm-0008Mh-00; Sun, 02 Feb 2003 00:21:54 -0500 Date: Sun, 02 Feb 2003 05:21:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: ac131313@redhat.com, gdb@sources.redhat.com Subject: Re: RFC: Variables in blocks of registers Message-ID: <20030202052153.GA30209@nevyn.them.org> Mail-Followup-To: Mark Kettenis , ac131313@redhat.com, gdb@sources.redhat.com References: <200302011448.h11EmCkP001176@elgar.kettenis.dyndns.org> <3E3BEC50.9040104@redhat.com> <20030201171001.GB29662@nevyn.them.org> <3E3C3200.8070803@redhat.com> <200302012235.h11MZ30D023842@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302012235.h11MZ30D023842@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00020.txt.bz2 On Sat, Feb 01, 2003 at 11:35:03PM +0100, Mark Kettenis wrote: > Date: Sat, 01 Feb 2003 15:45:52 -0500 > From: Andrew Cagney > > > Michael, I think the new multi-arch function is a good idea as long as > > it is a fallback from explicit debug info support, when we have such. > > I also think it needs a better name; but I'm not quite sure what. Hmm, > > that could be mitigated by adequate commenting. > > I suppose Daniel meant me, Mark, here ;-). Ack ack! I'm sorry, Mark. > 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. > > Hmm, I agree that it is better to get a proper location mechanism > working. However, I don't think we have any hope at getting such a > mechanism working with stabs. And I don't agree that it is very > dangerous to assume the specific algorithm that GCC has been using for > several years. Besides GDB already uses a specific algorithm since it > assumes that registers have been allocated by the compiler in the > order that is dictated by GDB's register cache. That algorithm is > known to be wrong for the majority of GDB's users, makes GDB print > bugus values and can lead to segfaults in the inferior when setting > variables. Why not replace this algorithm with something better? The > changes that are necessary aren't very invasive (see the end of this > message for the changes to findvar.c and valops.c). > > Daniel, do you think next_allocated_regnum is a better name? Hmm, yes, I like that better. We'll need to hook in a better mechanism when we have DW_OP_piece support, but it doesn't need to be designed now. The basic idea of your patch below looks good to me. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer