From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10070 invoked by alias); 26 Aug 2002 18:25:46 -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 10060 invoked from network); 26 Aug 2002 18:25:45 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 26 Aug 2002 18:25:45 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 2B23210AAA; Mon, 26 Aug 2002 14:23:51 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15722.29238.818092.258790@localhost.redhat.com> Date: Mon, 26 Aug 2002 11:29:00 -0000 To: Kevin Buettner Cc: Elena Zannoni , Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [patch/wip] Save/restore cooked registers In-Reply-To: <1020826172622.ZM31173@localhost.localdomain> References: <3D692D27.4010003@ges.redhat.com> <1020826155511.ZM30766@localhost.localdomain> <15722.22357.397126.473082@localhost.redhat.com> <1020826172622.ZM31173@localhost.localdomain> X-SW-Source: 2002-08/txt/msg00853.txt.bz2 Kevin Buettner writes: > 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. > Yes. I was thinking about this other problem I encountered: http://sources.redhat.com/ml/gdb-patches/2002-08/msg00689.html > 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?) > The pseudo register write function is written so that it preserves the upper bits. If you use that technique you should be safe. Elena > > 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