The REG_NUM and REGISTER_BYTES problem

[Andrew Cagney <ac131313 at cygnus dot com>]

Hello,

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

Simple eh?

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 
architecture.

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.

Thoughts?

Andrew