This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] New register definition interface
- To: Nicholas Duffek <nsd at redhat dot com>
- Subject: Re: [RFA] New register definition interface
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Sat, 13 Jan 2001 00:19:01 +0930
- Cc: gdb-patches at sources dot redhat dot com
- References: <200101032042.PAA14850@nog.bosbc.com>
Nick, I'm afraid my response is a little hairy fairy and involves some
hand waving :-(
Looking through reg.[ch] I don't have any problems with it as a utility
that some targets can use to implement their register buffer.
What concerns me is that the code is widening the gdbarch interface so
that it accomodates a specific reg-cache implementation. I know your
code (unfortunatly) won't handle every case (new more bizare cases turn
up every day) so I think it would be better for a generic-reg.c to focus
on the common case and let the more esoteric architectures be handled on
a per-architecture basis.
Instead of pushing your implementation of the reg-cache up into the
gdbarch vector (the REGISTER_LIST method) I think things should be
tweeked so that your register implementation is pushed down a level.
Over time, the interface can be abstracted/simplified further and more
pushed into your and the old reg modules.
Looking at one of the functions:
real_register (int regnum)
{
- return regnum >= 0 && regnum < NUM_REGS;
+ if (REGISTER_LIST)
+ return regs_real (regnum);
+ else
+ return regnum >= 0 && regnum < NUM_REGS;
}
I think these should be made virtual so that your, or any other, code
can just drop in..
----
Did you get VALUE_REGNO() -> VALUE_REGNUM() in that rename?
----
The code doesn't appear to help how GDB handles register values in
expressions and assignments (grep for VALUE_REGNO). Have you thought
about that?
Andrew