From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8531 invoked by alias); 29 Apr 2003 04:45:17 -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 8524 invoked from network); 29 Apr 2003 04:45:16 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 29 Apr 2003 04:45:16 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19AMze-0004M6-00; Mon, 28 Apr 2003 23:45:26 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19AMzK-0002wA-00; Tue, 29 Apr 2003 00:45:06 -0400 Date: Tue, 29 Apr 2003 15:08:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com Subject: Re: re-ordered i386 regcache Message-ID: <20030429044506.GA11200@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EADE027.90209@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00539.txt.bz2 On Mon, Apr 28, 2003 at 10:15:03PM -0400, Andrew Cagney wrote: > > >>>Here's a discussion piece. I've implemented your suggestion. Two > >>>notes: > >>> - Having done it, I still don't like it :) Using the register cache > >>>in this way seems very wrong to me. > > > >> > >>Got another way of getting MIPS (32 on 64), i386 on x86-64 (or even > >>ia64?), e500 on PPC, sh4 on sh64, ... all working? > > > > > >What problem besides the REGISTER_BYTE() problem are you solving with > >this mechanism? > > REGISTER_BYTE() is a side issue. It is eliminated with proper location > support. Sure. That's why I'm trying to get a grasp on what you think the real issue is. > >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. 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. > >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 - provide a general, well-defined mechanism that at least now we only need for i386 then I'm all for plan B. > >>Should there be a frame equivalent to the regcache's cooked->raw > >>projection? Should the read side of the cooked->raw projection be moved > >>to the frame? > >> > >>Note that things like the m68hc11 some of the cooked registers are > >>mapped onto memory so the cooked->raw writes would likely still need to > >>remain. > > > > > >Hmm, certainly something will have to change. Invoking > >gdbarch_pseudo_register_read on the current regcache when we're > >actually several frames away doesn't respond right. It seems to me > >that moving the logic such that gdbarch_pseudo_register_read takes a > >frame parameter might work better, but I'm not sure of the > >implications. > > The e500 and sh both handle this by doing the maps on a per-frame basis. Not familiar with the SH code... skimming the e500 code I can't quite tell how it works, but it looks as if the pseudo registers are found in get_frame_saved_regs and e500_pseudo_register_read will only behave correctly for the topmost frame. Which makes sense given the way we handle e500 regs. I suppose I could mark both versions of %eax saved in i386's frame_get_saved_regs to fix the immediate problem... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer