Re: [patch/wip] Save/restore cooked registers

[Elena Zannoni <ezannoni@redhat.com>]

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