This is the mail archive of the
mailing list for the GDB project.
The REG_NUM and REGISTER_BYTES problem
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: gdb at sources dot redhat dot com
- Date: Fri, 30 Nov 2001 22:23:02 -0500
- Subject: The REG_NUM and REGISTER_BYTES problem
This is one of those ``in the beginning there was a VAX and life was
good'' stories. Rather than start that way, lets try something
different, in the beginning there was an m68k, er no, never mind ...
Each GDB architecture defines two constants:
NUM_REGS -> number of ``real registers''
REGISTER_BYTES -> number of byte the real registers occupy
The problem is that this pair is very heavily entrenced in the way GDB
views the world - they have come to mean a lot more. For instance:
o A G packet is REGISTER_BYTES in size
and can contain only NUM_REG registers.
If, for some reason, you have a lot of
``real registers'' (i586 has the potential
for 4 billion) then you're a bit stuffed.
o The regcache is REGISTER_BYTES in size.
o The generic inferior function call code
assumes that, to save the target state,
it just needs to slurp REGISTER_BYTES from
the target stack and it can fetch any NUM_REG
from that saved state.
If you only think a subset of those
registers should be saved or if you want
to save both registers and memory then
your out of luck.
These problems come to a head when you try to do things like:
o increase the number of ``real registers''
with out increasing the G packet size.
o increase the size of the regcache via
REGISTER_BYTES without forcing up the
size of that G packet.
o Add registers that you don't want saved/restored.
To address this, I intend changing regcache and remote.c so that they
treat all registers equal (don't differentiate between real and psuedo
registers). Instead, regchace reserves space for all of them, and
remote.c will fetch any of them when so asked. Exactly what to do with
all that potential regcache space being the responsibility of the target
By doing this, the immdiate restriction of not being able to expand the
number of registers is lifted. While some of REGISTER_BYTES and
NUM_REGS special effects will remain, they won't be causing GDB's
ability to handle large register sets.