gdb/122: Register Cache Cleanup

[ac131313 at cygnus dot com]

>Number:         122
>Category:       gdb
>Synopsis:       Register Cache Cleanup
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 06 19:58:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     ac131313@cygnus.com
>Release:        unknown-1.0
>Organization:
>Environment:

>Description:
Register Cache Cleanup (below from Andrew Cagney)

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
        bytes       
             |
            \|/
        ------------
        | register |
        |  cache   |
        ------------
            /|\
             |
        map random cache
        bytes to target
        dependent i-face
            /|\
             |
       target dependent
        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) dependent
                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:

        virt<->cache
                Modifying an mmx register may involve
                scattering values across both FP and
                mmpx specific parts of a buffer

        cache<->target
                When writing back a SP it may need to
                both be written to both SP and USP.


Hmm,

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.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: