From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19813 invoked by alias); 28 Apr 2003 16:37:13 -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 19800 invoked from network); 28 Apr 2003 16:37:11 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 28 Apr 2003 16:37:11 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 74FB52B2F; Mon, 28 Apr 2003 12:37:12 -0400 (EDT) Message-ID: <3EAD58B8.2070003@redhat.com> Date: Mon, 28 Apr 2003 19:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com Subject: Re: patch for printing 64-bit values in i386 registers; STABS format References: <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> <20030428153247.GA28501@nevyn.them.org> <3EAD51F1.8050605@redhat.com> <20030428161443.GA30324@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00526.txt.bz2 > - stabs would have to be modified (if we did this fixup in each and > every debug reader, instead of in read_var_value and friends; I see > good arguments both ways) It would hopefully be a shared function that those debug readers could call. The important thing is that the core code only knows about one mechanism. >> >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. > >> >> GDB also uses it to encode offsets into a register. It also does not >> help the MIPS where the debug register does need to be projected into >> the raw registers. Why have add more mechanisms when the existing one >> is sufficient. Focus the effort on fixing the real problem. >> >> BTW, my comment about no names was wrong. They can be named, that >> restriction should have been removed by the introduction of reggroups. > > > Well, in that case I guess it would work. Let's do it? > > It still feels much more like a hack to me than Mark's approach; I'll > just quietly disagree I suppose. Hmm, I think it will be needed anyway, what happens when the user is debugging an i386 mode function (with 32 bit register based long long debug info) on an x86-64 target? That's the MIPS problem, and it needs that projection(1). Also, the next_regnum method assumes that all debug infos use the same register sequencing. A word of caution though, the projection, at the register level works. Frame's might need tweaking. The alternative is to start out with deprecated_next_regnum so that it is clear where this stands. Andrew (1) dwarf2 debug info makes certain assumptions about the size of registers