From: Daniel Jacobowitz <drow@false.org>
To: Richard Earnshaw <rearnsha@gcc.gnu.org>
Cc: gdb@sourceware.org
Subject: Re: RFC: Available registers as a target property
Date: Thu, 19 May 2005 01:00:00 -0000 [thread overview]
Message-ID: <20050519010013.GA27885@nevyn.them.org> (raw)
In-Reply-To: <1116408515.15608.40.camel@pc960.cambridge.arm.com>
On Wed, May 18, 2005 at 10:28:35AM +0100, Richard Earnshaw wrote:
> On Tue, 2005-05-17 at 20:32, Daniel Jacobowitz wrote:
>
> > /* If this flag is set, GDB should save and restore this register
> > around calls to an inferior function. */
> > int save_restore;
>
> Why would the target care about this? It seems to be more a property of
> an ABI than the target.
>
> In the (IMO) unlikely case that we really want to keep this, I think it
> should have a 'not-my-responsibility-to-decide' setting.
This isn't the conventional callee-saved vs. caller-saved decision. GDB
needs to handle bogus functions so it should save/restore all "normal"
registers, but there may be some registers in a system for which this
behavior is inappropriate. Perhaps there's a better name for this if I
invert the meaning... For instance, a debugger should probably not muck
with cp15 registers across a function call, even if they're not marked
readonly, to allow the user to modify them explicitly.
I'm trying to express the concept of save_reggroup/restore_reggroup for
target specified registers. Have you got another idea of how to do it?
Maybe it's not necessary after all?
--
Daniel Jacobowitz
CodeSourcery, LLC
next prev parent reply other threads:[~2005-05-19 1:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-06 16:20 Daniel Jacobowitz
2005-05-07 10:25 ` Eli Zaretskii
2005-05-07 16:19 ` Daniel Jacobowitz
2005-05-07 19:37 ` Eli Zaretskii
2005-05-09 15:37 ` Daniel Jacobowitz
2005-05-09 20:58 ` Eli Zaretskii
2005-05-07 16:04 ` Mark Kettenis
2005-05-09 16:20 ` Daniel Jacobowitz
2005-05-09 15:57 ` Paul Brook
2005-05-09 16:32 ` Daniel Jacobowitz
2005-05-09 21:33 ` Chris Zankel
2005-05-09 23:07 ` Daniel Jacobowitz
2005-05-10 0:23 ` Chris Zankel
2005-05-10 21:08 ` Daniel Jacobowitz
2005-05-12 23:35 ` Chris Zankel
2005-05-17 14:03 ` Daniel Jacobowitz
2005-05-10 0:54 ` Ramana Radhakrishnan
2005-05-10 21:14 ` Daniel Jacobowitz
2005-05-17 19:32 ` Daniel Jacobowitz
2005-05-18 9:29 ` Richard Earnshaw
2005-05-19 1:00 ` Daniel Jacobowitz [this message]
2005-05-20 14:54 ` Richard Earnshaw
2005-05-09 22:39 Paul Schlie
2005-05-10 0:03 Paul Schlie
2005-05-10 11:12 Paul Schlie
2005-05-17 23:08 Paul Schlie
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=20050519010013.GA27885@nevyn.them.org \
--to=drow@false.org \
--cc=gdb@sourceware.org \
--cc=rearnsha@gcc.gnu.org \
/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