This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/wip] Save/restore cooked registers
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