From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25224 invoked by alias); 28 Aug 2002 16:04:32 -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 25211 invoked from network); 28 Aug 2002 16:04:29 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 28 Aug 2002 16:04:29 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DC0333F0A; Wed, 28 Aug 2002 12:04:28 -0400 (EDT) Message-ID: <3D6CF48C.3080908@ges.redhat.com> Date: Wed, 28 Aug 2002 09:58:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard.Earnshaw@arm.com Cc: Elena Zannoni , Kevin Buettner , gdb-patches@sources.redhat.com Subject: Re: [patch/wip] Save/restore cooked registers References: <200208281423.PAA16288@cam-mail2.cambridge.arm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00943.txt.bz2 >> I suspect this is why the old code was saving the full register range. > > > I think it saved the entire range because it didn't know any better. No. read_register_bytes() was intentionally changed from NUM_REGS to NUM_REGS+NUM_PSEUDO_REGS. I've encountered architectures that use memory mapped register locations as part of their ABI and hence, rely on those locations being saved. I suspect that the m69hc11 falls into this category (but it isn't the target I've in mind). Anyway, the branch now defaults to saving just the first [0 .. NUM_REGS). A target is free to replace this with code that saves an arbitrary register set in the range [0 .. NUM_REGS+NUM_PSEUDO_REGS) range. I should note that core gdb knows none of this. It just asks for a register cache to be saved / restored. >> - disallow writes to a saved copy of the register cache > > > I don't see that this matters, see below. What should the regcache do with a write to a saved register cache when the write is ment to go to memory? Given that GDB never even tries to write to a saved cache, I think formalizing this, and disallowing writes to a saved cache, is reasonable. >> If this isn't done, there is a problem with keeping the cooked registers coherent. > > > No, the cooked registers can never be incoherrent if you just consider > them as view-ports onto a register-cache set. That is, they have no > persistent state in themselves. Remember, cooked registers map onto both raw registers and memory. If cooked registers are not saved, gdb will need to start saving chunks of memory. A saved copy of the register cache is simply that, a snapshot. It just needs to ensure that the saved value of all cooked registers (involved in the ABI) are available. How it does this, well you don't want to know :-) > I really think we need to break this implicit link between the raw regs > and part of the cooked regs, it just causes no-end of confusion. It's > fine if we want to say that some cooked regs are mapped 1:1 onto part of > the raw regcache, but that should/must be a back-end convenience, and not > part of gdb's fundamental design (that is asking for the r0 cooked view > may just happen to fetch the raw r0 register that is at offset zero in the > regcache, but nothing in GDB-core should assume this). BTW, it turns out that nothing in core GDB is assuming this (ignoring the CONVERTABLE mess). Elena's e500 port maped everything onto a totally cooked register and nothing noticed. Core gdb just deals with cooked registers (or their ulgh offset). Cooked vs raw only appears: - in the register cache (where it needs to know what to access when) (but the core is clueless to this) - in the target back-end where it needs to map cooked registers onto raw registers or the register cache Long term, core gdb should find itself only refering to frame_register*() > If you are trying to just add some code that optimizes the storing of > registers back to the inferior, then surely the easiest way to do this is > to have a further 'inferior' set of values that we never update, then when > we need to update a value we check to see if the value we want to write > matches that which we know the inferior to have and suppress the write if > there is no change. I'm not. The objective is to hand a target that: - has registers mapped onto memory locations - has non ABI registers (should not be saved / restored) enough rope to hang themself while still keeping the common case (just save raw registers) simple. enjoy, Andrew