The REG_NUM and REGISTER_BYTES problem

The REG_NUM and REGISTER_BYTES problem

[Andrew Cagney]

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

The REG_NUM and REGISTER_BYTES problem

[Andrew Cagney]

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

Re: The REG_NUM and REGISTER_BYTES problem

[Daniel Jacobowitz]

On Fri, Nov 30, 2001 at 10:23:02PM -0500, Andrew Cagney wrote:
> 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?

Well, how will this affect pseudo registers that we can provide but
that the remote stub can not?  I'm pretty sure there are some.  Is the
intent that such registers "should not" be fetched?

On the subject of the remote protocol, both you and I posted scripts to
generate a register packet description from a text file.  What're your
thoughts on adding one of those?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: The REG_NUM and REGISTER_BYTES problem

[Andrew Cagney]

> Well, how will this affect pseudo registers that we can provide but
> that the remote stub can not?  I'm pretty sure there are some.  Is the
> intent that such registers "should not" be fetched?

Hmm, yes, er, how can I put it?  Pseudo registers are a figment of GDB's 
vivid imagination?  Hmm, perhaphs not.

The theory is that core-GDB delegates _all_ responsibility for the 
resolution of such issues to the target architecture.  Or to put it 
another way, the target architecture is given enough rope to hang its 
self :-)

Yes, there are going to be registers that should not be fetched by 
remote.c from the target.  The trick is that register read/write should 
have already intercepted such register requests and mapped them onto 
real registers. (ok, I've simplified it a little :-)

Think of it as:

	user
	-> register read/write (maps cooked to raw)
	-> regcache read/write
	-> target fetch/store
	-> target.c
	-> map regnum to target regnum

provided register read/write is implemented correctly, the architecure 
is honky dorey.

To give a tangeable example, consider i386's MMX.  These 64 bit pseudo 
registers can be mapped onto 80 real FP registers.  The register 
read/write function map's MMX N register onto FP register M.

enjoy,
Andrew