From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3786 invoked by alias); 28 Apr 2003 23:31: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 3779 invoked from network); 28 Apr 2003 23:31:12 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 28 Apr 2003 23:31:12 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19AI5m-0003uC-00; Mon, 28 Apr 2003 18:31:27 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19AI5S-0001vp-00; Mon, 28 Apr 2003 19:31:06 -0400 Date: Tue, 29 Apr 2003 04:45: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: <20030428233106.GA7307@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , colins@google.com, gdb-patches@sources.redhat.com References: <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> <3EAD58B8.2070003@redhat.com> <20030428192506.GA11978@nevyn.them.org> <3EADB095.2090409@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EADB095.2090409@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00536.txt.bz2 On Mon, Apr 28, 2003 at 06:52:05PM -0400, Andrew Cagney wrote: > [I changed subjects, this thread is too long] > > >On Mon, Apr 28, 2003 at 12:37:12PM -0400, Andrew Cagney wrote: > > > >>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. > > > > > >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? 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. 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. > > - It doesn't work for frames, because by the time > >i386_pseudo_register_read is called the regcache is always > >current_regcache. I believe this is because of > >legacy_saved_regs_prev_register: > > > >975 if (get_frame_saved_regs (frame) != NULL > >976 && get_frame_saved_regs (frame)[regnum] != 0) > > > >I guess doing this much without doing the rest of the conversion makes > >the frame machinery quite sad. > > 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer