From: Jim Blandy <jimb@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: cooked regcache -> frame
Date: Wed, 21 May 2003 20:03:00 -0000 [thread overview]
Message-ID: <vt2k7ckt60v.fsf@zenia.red-bean.com> (raw)
In-Reply-To: <3ECB974E.9060902@redhat.com>
The frame seems like the right thing to me, too.
Andrew Cagney <ac131313@redhat.com> writes:
> [To think out loud - I'm refering to how GDB should work, not how it
> does work :-)]
>
> Ref: [RFA]: gdbarch FETCH_POINTER_ARGUMENT
> http://sources.redhat.com/ml/gdb-patches/2003-05/msg00329.html
> Ref: [multi-arch] The frame as the global parameter (long, important),
> http://sources.redhat.com/ml/gdb/2001-02/msg00335.html
>
>
> The [original] FETCH_POINTER_ARGUMENT code does things like:
>
> - return read_register (3 + i);
>
> and
>
> - CORE_ADDR stack = read_register (SP_REGNUM);
> - return read_memory_unsigned_integer (stack + (4 * (i + 1)), 4);
>
> that is, it relies on global state to determine the values. Global
> state is bad m'kay :-)
>
> There are a number of ways to fix this. All involve the addition of a
> context parameter, the problem though is which one.
>
> - the regcache
> While the most obvious it only solves half the problem. The regcache
> can provide the inner most registers, but not the memory. Adding
> memory access methods to the regcache ``feels wrong''. Also, the
> regcache limits things to the inner most frame.
>
> - the target
> But a target can have multiple threads
>
> - the frame
> A frame has registers, memory, architecture, and a thread
>
> - the thread
> A thread has registers and memory, architectures and
> frames. Unfortunatly, that was multiple frames (selected, current,
> ...) and multiple architectures (potentially one per frame ...) so
> while it looks good it is really only useful for an operation that
> applies to the inner most frame :-/
>
> Hence, I think, increasingly the frame, and not the regcache or thread
> should be the context parameter of choice (note that this idea isn't
> new, it's just becomming more visible, ref above).
>
> But isn't a frame creation expensive? After all, the last thing WFI
> (the state machine that handles things like single step, and calls
> this code) needs is an expensive frame create operation. Fortunatly,
> frame creation is no longer expensive - on up-to-date architectures,
> it is a very cheap operation.
>
> What next?
>
> I guess I'll (unless someone else wants to :-) be re-visting all the
> architecture functions parameterized with a regcache to see if/where
> they should be re-parameterised with a frame. Fortunatly, unlike the
> registers[] to regcache conversion, this change would be
> mechanical. The obvious candiates for review are those that are
> reading reading register values from the inner most frame === the
> regcache.
>
> The other problem is register writes, and that, I think, deserves a
> separate post.
>
> Andrew
prev parent reply other threads:[~2003-05-21 20:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-21 15:12 Andrew Cagney
2003-05-21 20:03 ` Jim Blandy [this message]
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=vt2k7ckt60v.fsf@zenia.red-bean.com \
--to=jimb@redhat.com \
--cc=ac131313@redhat.com \
--cc=gdb@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).