Re: cooked regcache -> frame

[Jim Blandy <jimb at redhat dot 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