From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20303 invoked by alias); 26 Aug 2002 17:26:38 -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 20293 invoked from network); 26 Aug 2002 17:26:37 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 26 Aug 2002 17:26:37 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g7QHBhl10717 for ; Mon, 26 Aug 2002 13:11:43 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g7QHQQu13175; Mon, 26 Aug 2002 13:26:26 -0400 Received: from romulus.sfbay.redhat.com (IDENT:oupXiotU2xH7CQ9FNkLVAjs2FR6vo6Y8@romulus.sfbay.redhat.com [172.16.27.251]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g7QHQPe00966; Mon, 26 Aug 2002 10:26:25 -0700 Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g7QHQN931174; Mon, 26 Aug 2002 10:26:23 -0700 Date: Mon, 26 Aug 2002 11:21:00 -0000 From: Kevin Buettner Message-Id: <1020826172622.ZM31173@localhost.localdomain> In-Reply-To: Elena Zannoni "Re: [patch/wip] Save/restore cooked registers" (Aug 26, 12:29pm) References: <3D692D27.4010003@ges.redhat.com> <1020826155511.ZM30766@localhost.localdomain> <15722.22357.397126.473082@localhost.redhat.com> To: Elena Zannoni , Kevin Buettner Subject: Re: [patch/wip] Save/restore cooked registers Cc: Andrew Cagney , gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-08/txt/msg00851.txt.bz2 On Aug 26, 12:29pm, Elena Zannoni wrote: > Kevin Buettner writes: > > On Aug 25, 3:16pm, Andrew Cagney wrote: > > > > > The attached is work-in-progress to get gdb saving just a subset of > > > cooked registers when doing things like an inferior function call. > > > > Why is it necessary to save the cooked registers during an inferior > > function call? I would have thought that being able to save/restore > > raw registers would be sufficient. > > > > (Or did I miss a thread which explains this?) > > > > Kevin > > > On ppc the e500 general registers are pseudo (i.e.cooked). Those > are used in inferior function calls, for parameter passing. > I think this is part of the story. If I'm not mistaken, the pseudos on the e500 are synthesized from the raw registers without the need for outside sources such as memory. That being the case, saving the raw registers (or, more precisely, the cooked registers corresponding to the raw registers) should be sufficient. In fact, for the e500, I think we'll need to take care NOT to write back the pseudos since this could potentially cause information to be lost. It would depend upon the order in which things were done. If the pseudos are restored after the raw registers that they map onto, the most significant bits would likely be wiped out. (In this case the pseudos are narrower than the raw registers, right?) > Full explanation: > > http://sources.redhat.com/ml/gdb/2002-08/msg00196.html Yes, reading this explanation helped quite a lot. When a pseduo register's value is synthesized from sources outside of the raw register cache, e.g, from memory, we need to save these values. Later when writing them back, the reverse transformation will occur potentially writing memory (or those other outside sources). This makes sense to me. I've looked over Andrew's WIP patch. I haven't checked all the details, but the ideas seem sound and the interfaces look okay. I'd like to see the iterators better commented though. Kevin