RFC: Optimization to write_register_bytes()
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".
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:
map pseudo <->
| register |
| cache |
map random cache
bytes to target
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
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