From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23863 invoked by alias); 28 Apr 2003 15:32:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23818 invoked from network); 28 Apr 2003 15:32:53 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 28 Apr 2003 15:32:53 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19AAct-0003Aj-00; Mon, 28 Apr 2003 10:33:07 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19AAcZ-0007QA-00; Mon, 28 Apr 2003 11:32:47 -0400 Date: Mon, 28 Apr 2003 16:14:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com Subject: Re: patch for printing 64-bit values in i386 registers; STABS format Message-ID: <20030428153247.GA28501@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com References: <20030425002744.GA9492@nevyn.them.org> <200304252121.h3PLLD8I000461@elgar.kettenis.dyndns.org> <20030425213548.GA22505@nevyn.them.org> <3EA9B6AE.90001@redhat.com> <20030426015010.GA25355@nevyn.them.org> <3EA9F295.2090803@redhat.com> <20030426030534.GA26304@nevyn.them.org> <3EA9FDDF.8070205@redhat.com> <200304272203.h3RM35Ur016419@elgar.kettenis.dyndns.org> <3EAD474C.6090403@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EAD474C.6090403@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00520.txt.bz2 On Mon, Apr 28, 2003 at 11:22:52AM -0400, Andrew Cagney wrote: > > Date: Fri, 25 Apr 2003 23:32:47 -0400 > > From: Andrew Cagney > > > > > I'm afraid I don't understand, and I still don't see your reasoning > > > against this approach. > > > > It isn't necessary, just like register convertible and register > > raw/virtual size; .... that go before it, also were not necessary. And > > now all these years later, GDB is still yet to expunge. > > > >I still don't see how you can get rid of the register convertible > >stuff. On the i386 I still need it for variables stuffed into the > >floating point registers. > > That case is fine. A while ago I split the mechanism in half: > > - given a single FP register convert the type into its true form > - the MIPS jungle of combining sub-parts and adjacent FP and integer > register values > > > Until someone does the right think - add support for values scattered > > across registers and memory - hacks should be confined to architecture > > specific code. > > > >But even if someone does add support for values scattered across > >multiple registers and/or memory, we still need the architecture > >method I proposed. There simply is too much debugging info out there > >that can't express values being scattered across multiple registers. > > The stabs reader will need to be modified so that it generates a proper > location description. Note that it is STABS centric. dwarf2 doesn't > need that mechanism since (presumably) GCC is generating the correct > info (....). No, that's incorrect. GDB wouldn't even be able to find half the value if GCC was putting out correct information. We can't fix that until GDB is ready to not choke on the result. We will have to handle the incorrect debug info probably forever. > >And I don't think the hack you proposed is a good idea. I think it's > >better to add a new architecture method with a clear purpose than > >abuse an existing mechanism for something that it wasn't quite > >intended for. Even if the architecture method in question would only > >be used by a single target. > > This is one of the intended purposes of this mechanism, and as I > indicated, is needed by MIPS. Being able to project an arbitrary [debug > info] view of the registers onto the raw register buffer. > > BTW, what happens when there is an attempt to write a long long value? > GDB again assumes that it can write to contigious registers - the reason > why REGISTER_BYTE can't be killed. That ugliness could go away too with Mark's introduced method. GDB could be fixed to find the next register properly. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer