This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
The regcache abstraction (Was Re: PATCH ARM initial support for different floating-point models)
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Richard dot Earnshaw at arm dot com, gdb at sources dot redhat dot com
- Date: Wed, 20 Feb 2002 16:44:52 +0000
- Subject: The regcache abstraction (Was Re: PATCH ARM initial support for different floating-point models)
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot 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 (®buf[REGISTER_BYTE (ARM_F0_REGNUM)], valbuf);
> > else
> > memcpy (valbuf, ®buf[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.