The regcache abstraction (Was Re: PATCH ARM initial support for different floating-point models)

[Richard Earnshaw <rearnsha@arm.com>]

> Hmm, I'm afraid you may have just stepped into the 
> write_register_bytes() bear trap :-( Have a look at the comments in 
> regcache.c for the history.
> 

Well if I was confused before, I'm totally flummoxed now.

The more I try to wade through the different legacy interfaces to that 
file the more confused I become...

> 
> > Index: arm-tdep.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/arm-tdep.c,v
> > retrieving revision 1.47
> > diff -p -r1.47 arm-tdep.c
> > *** arm-tdep.c	2002/02/19 13:57:35	1.47
> > --- arm-tdep.c	2002/02/19 19:14:40
> > *************** arm_extract_return_value (struct type *t
> > *** 2139,2145 ****
> >   			  char *valbuf)
> >   {
> >     if (TYPE_CODE_FLT == TYPE_CODE (type))
> > !     convert_from_extended (&regbuf[REGISTER_BYTE (ARM_F0_REGNUM)], valbuf);
> >     else
> >       memcpy (valbuf, &regbuf[REGISTER_BYTE (ARM_A1_REGNUM)],
> >   	    TYPE_LENGTH (type));
> 
> Here, unfortunatly, directly pokeing around the regcache buffer (a 
> parameter) is still the only way to do this.

Yep, this is awful, but that's what it has always done there (you quote 
the old code).


> >   	    TYPE_LENGTH (type));
> > *************** arm_store_return_value (struct type *typ
> > *** 2256,2270 ****
> >   {
> >     if (TYPE_CODE (type) == TYPE_CODE_FLT)
> >       {
> >         char buf[MAX_REGISTER_RAW_SIZE];
> >   
> > !       convert_to_extended (valbuf, buf);
> > !       /* XXX Is this correct for soft-float?  */
> > !       write_register_bytes (REGISTER_BYTE (ARM_F0_REGNUM), buf,
> > ! 			    MAX_REGISTER_RAW_SIZE);
> 
> I think your changes to this function can be rewritten to use 
> write_register_gen(REGNUM,BUF).

And you quote the old code again here.

> Need to be careful though.  If the code is assuming a floating point 
> value should be stored across multiple adjacent registers then the code 
> will need to be broken down into separate explicit writes.

I desperately need a high-level overview of how the regcache interface is 
*supposed* to work in the brave new world (ie without all the legacy 
interfaces lying around).  Let me start by trying to draw a little diagram 
to explain how I think it might work; then we can expand on that, or 
re-draw it as appropriate.

Lets start the model with four main units.  The inferior, the regcache, 
the MI routines and the tdep support.  The interfaces are then as follows:

          +--------------------------------+
          |          Inferior              |
          +--------------------------------+
                        ^ |
                        | | A
                        | v
          +--------------------------------+
          |          Regcache              |
          +--------------------------------+
                ^ |                ^ |
                | | B              | | C
                | v                | v
          +-------------+    +-------------+
          |     MI      |<==>|    Tdep     |
          +-------------+ D  +-------------+

That gives us three potential interfaces to the regcache, A, B and C.  In 
addition, there is an interface D, which is effectively the gdbarch vector.

Now, as I understand it, interface A is quite straight-forward and 
consists of three functions:

	supply_register()
	collect_register()
	set_register_cached()

[The last of these is needed because a target may be unable to recover 
some registers at certain times, and may need to tell the regcache that.]

This interface is used by the 'nat' code or anything else that talks to a 
target machine (ie it lies at the callee side of a target_ops vector).

However, after that it starts to become fuzzy.  The first problem is that 
it isn't completely clear whether the regcache should contain a raw cache 
of the physical registers, or some munged view of them.

I'd be inclined to argue the regcache should be pretty much a raw cache of 
the machine registers, and that interface B is therefore bogus (since it 
can't know how to interpret the information); therefore all accesses to 
the regcache by MI code should be, at least conceptually, via the tdep 
code using interface D.

Of course, it may be that many targets will have near identical routines 
for mapping D<->C and there's no reason why that shouldn't be extracted 
out so that the gdbarch vector can handle it cleanly.

So my questions are: Do we have interface B?  If so, why? what functions 
comprise C? and what functions comprise D?

> 
> enjoy,

Not a chance :-)

R.