From: Andrew Cagney <ac131313@redhat.com>
To: gdb@sources.redhat.com
Subject: cooked regcache -> frame
Date: Wed, 21 May 2003 15:12:00 -0000 [thread overview]
Message-ID: <3ECB974E.9060902@redhat.com> (raw)
[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
next reply other threads:[~2003-05-21 15:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-21 15:12 Andrew Cagney [this message]
2003-05-21 20:03 ` Jim Blandy
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=3ECB974E.9060902@redhat.com \
--to=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).