This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]