RFC: Optimization to write_register_bytes()

Andrew Cagney ac131313@cygnus.com
Thu May 4 20:46:00 GMT 2000

Fernando Nasser wrote:
> Andrew Cagney wrote:
> >
> > > (The Pentium MMX registers are aliased to the mantissa of the floating point
> > > registers)
> >
> > Can I guess that the bug is that there is no consistency between FP and
> > mmx registers and you're attempting to fix it by mapping the register
> > raw-size/offset of the mmx registers directly onto the FP registers?
> >
> It is not a bug.  That is Intel "design".
> Sorry.

By bug I was refering to how the current design of GDB's register cache
can't support configurations such as this.  On the grand scale of
hardware design, this intel features is pretty tame :-)

What follows is some pretty bad ASCII art ...

I would depict the current register architecture as something like:

	High GDB  -->	Low GDB
	    |		   |
	   \|/		  \|/
	    --- REG NR -----
    register + REGISTER_BYTE(reg_nr)
	|  extern register[]	|

where neither the high (valops.c et.al.) or low gdb (*-tdep.c) are
really clear on what mechanisms they should be using to manipulate that
buffer.   Further, much code assumes, dangerously, that registers are
contigious.  Having got mips-tdep.c to support multiple ABIs, believe
me, that is a bad assumption.  Finally, that register cache layout is
determined by the current remote/local target and _not_ the less
specific target ISA.  In fact, in many cases it is determined by the
somewhat arbitrary layout of the [gG] packets!

How I would like the register file to work is more like:

	  High GDB
       pseudo reg-nr
	map pseudo <->
	random cache
    	| register |
	|  cache   |
	map random cache
	bytes to target
	dependant i-face
       target dependant
	such as [gG] packet
	or ptrace buffer

The main objectives being:

	o	a clear separation between the low
		level target and the high level GDB

	o	a mechanism that solves the general
		problem of register aliases, overlaps
		etc instead of treating them as optional
		extras that can be wedged in as an after
		thought (that is a reasonable description
		of the current code).

		Identify then solve the hard case and the
		rest just falls out.  GDB solved the easy
		case and then tried to ignore the real
		world :-)

	o	a removal of the assumption that the
		mapping between the register cache
		and virtual registers is largely static.
		If you flip the USR/SSR stack register
		select bit in the status-register then
		the corresponding stack registers should
		reflect the change.

	o	a mechanism that clearly separates the
		gdb internal register cache from any
		target (not architecture) dependant
		specifics such as [gG] packets.

Of course, like anything, it sounds good in theory.  In reality, it
would have to contend with many<->many relationships at both the
virt<->cache and cache<->target level.  For instance:

		Modifying an mmx register may involve
		scattering values across both FP and
		mmpx specific parts of a buffer

		When writing back a SP it may need to
		both be written to both SP and USP.


Rather than let this like the last time it was discussed, just slip, I'm
first going to add this e-mail (+ references) to TODO.  I'd then like to
sketch out a broad strategy I think could get us there.

First thing I'd suggest is separating out the ``extern registers[]''
code so that we can at least identify what is using it.  At present
things are scattered across many files.  That way we can at least
pretend that there is a cache instead of a global array :-)

I'd then suggest someone putting up a proposal for the pseudo-reg /
high-level side interface so that code can be adopted to it.  For old
code, initially a blanket rename of write_register_bytes() to
deprecated_write_register_bytes() would help.

Following that would, finaly be the corresponding changes to the target.


PS: Fernando, sorry to hit you with this as a response.  You're simply
the latest in a long list of people (me included) that have had to
wrestle with the current register-cache design.  For as long as I can
remember people have been comming to grief with this code (just changing
REGISTER_NAMES[] to REGISTER_NAME() was a radical breakthrough :-).  I
would really like to set out something that is going to finally fix the

More information about the Gdb-patches mailing list