From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6488 invoked by alias); 29 Apr 2003 02:15:10 -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 6480 invoked from network); 29 Apr 2003 02:15:08 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 29 Apr 2003 02:15:08 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0BF5F2B2F; Mon, 28 Apr 2003 22:15:04 -0400 (EDT) Message-ID: <3EADE027.90209@redhat.com> Date: Tue, 29 Apr 2003 14:30: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: <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> <20030428233106.GA7307@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00538.txt.bz2 >> >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. > 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?) > 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. >> 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. Andrew