From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10390 invoked by alias); 29 Apr 2003 14:30:06 -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 10315 invoked from network); 29 Apr 2003 14:30:05 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 29 Apr 2003 14:30:05 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1C97A2B2F; Tue, 29 Apr 2003 10:30:04 -0400 (EDT) Message-ID: <3EAE8C6B.2050403@redhat.com> Date: Tue, 29 Apr 2003 15:25: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: re-ordered i386 regcache References: <200304272203.h3RM35Ur016419@elgar.kettenis.dyndns.org> <3EAD474C.6090403@redhat.com> <20030428153247.GA28501@nevyn.them.org> <3EAD51F1.8050605@redhat.com> <20030428161443.GA30324@nevyn.them.org> <3EAD58B8.2070003@redhat.com> <20030428192506.GA11978@nevyn.them.org> <3EADB095.2090409@redhat.com> <20030428233106.GA7307@nevyn.them.org> <3EADE027.90209@redhat.com> <20030429044506.GA11200@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00541.txt.bz2 >> >Of the above, at least the e500 issues I consider to be completely >> >different; that's dealing with a very particular set of debug info that >> >only has part of the register. That's a handy thing to solve in the >> >register cache. Besides, it doesn't play sequential-register-numbering >> >tricks. That was the whole point - the other numbers are way off in >> >the 1200 range. >> > >> >I'd say the MIPS/i386 issues are also more like e500 than like this >> >debug info ordering problem that we're talking about here. > >> >> (are you sure you're refering to the correct architectures here?) > > > Absolutely. The MIPS/i386 in the above be interpreted as i386 VS long long and not i386/x86-64. The reword below clarified it. > I know the e500 situation (limited form of DW_OP_piece for > 64-bit registers), and both MIPS/MIPS and x86-64/i386 are trying to > expose the same register in multiple ways. All three require a projection such that, assumed contigious, debug info registers project onto raw registers. Isn't this what i386 has? >>I'm not dismissing the value of the powerful pseudo technique that >> >you've put together. It's really handy. I just don't think it's the >> >answer to this problem. > >> >> Going back to an earlier point it contains an i386 specific problem to >> the i386. That way yet another hack doesn't get in the core code. >> However, the knowledge of needing to handle that case does. > > > If the choice is: > - contain an i386 specific problem to i386 specific code by using a > hack You mean that the cooked->raw mechanism is a hack? > - provide a general, well-defined mechanism that at least now we only > need for i386 (and I'm calling it a quick and tempoary hack, because it isn't the final solution) > then I'm all for plan B. Seems we've each taken to calling the alternative solution ``a hack'' :-( GDB can't afford to accumulate yet more mechanisms just on the off chance that a second architecture might just happen to need it. This is how GDB ended up with so many architecture methods used by 1 (then zero) targets (what's the harm in #define ...; #ifdef ...?). Instead, where possible, target dependand code should start out by using existing mechanisms; while the core is extended to use a more complete solution. > I suppose I could mark both versions of %eax saved in i386's > frame_get_saved_regs to fix the immediate problem... That is what was done (minus possible missed edge cases). Being able to project cooked onto raw registers at the frame level, should simplify this. Andrew