This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFA] New register definition interface


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]