From: Kevin Buettner <kevinb@redhat.com>
To: Elena Zannoni <ezannoni@redhat.com>, Kevin Buettner <kevinb@redhat.com>
Cc: Andrew Cagney <ac131313@ges.redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch/wip] Save/restore cooked registers
Date: Mon, 26 Aug 2002 11:21:00 -0000 [thread overview]
Message-ID: <1020826172622.ZM31173@localhost.localdomain> (raw)
In-Reply-To: Elena Zannoni <ezannoni@redhat.com> "Re: [patch/wip] Save/restore cooked registers" (Aug 26, 12:29pm)
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
next prev parent reply other threads:[~2002-08-26 17:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-25 12:23 Andrew Cagney
2002-08-26 9:05 ` Kevin Buettner
2002-08-26 9:31 ` Andrew Cagney
2002-08-26 10:26 ` Elena Zannoni
2002-08-26 11:21 ` Kevin Buettner [this message]
2002-08-26 11:25 ` Andrew Cagney
2002-08-26 13:52 ` Kevin Buettner
2002-08-26 11:29 ` Elena Zannoni
2002-08-26 12:04 ` Kevin Buettner
2002-08-28 7:42 ` Richard Earnshaw
2002-08-28 9:58 ` Andrew Cagney
2002-08-29 8:36 ` Elena Zannoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1020826172622.ZM31173@localhost.localdomain \
--to=kevinb@redhat.com \
--cc=ac131313@ges.redhat.com \
--cc=ezannoni@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox