* cooked regcache -> frame
@ 2003-05-21 15:12 Andrew Cagney
2003-05-21 20:03 ` Jim Blandy
0 siblings, 1 reply; 2+ messages in thread
From: Andrew Cagney @ 2003-05-21 15:12 UTC (permalink / raw)
To: gdb
[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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: cooked regcache -> frame
2003-05-21 15:12 cooked regcache -> frame Andrew Cagney
@ 2003-05-21 20:03 ` Jim Blandy
0 siblings, 0 replies; 2+ messages in thread
From: Jim Blandy @ 2003-05-21 20:03 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-05-21 20:03 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-21 15:12 cooked regcache -> frame Andrew Cagney
2003-05-21 20:03 ` Jim Blandy
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).