cooked regcache -> frame

cooked regcache -> frame

[Andrew Cagney]

[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

Re: cooked regcache -> frame

[Jim Blandy]

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