Re: [wip/cagney_regbuf-20020515-branch] Introduce regcache_move()

[Andrew Cagney <ac131313@cygnus.com>]

> ac131313@cygnus.com said:
> 
>> I suspect RichardE will come up with something for
>> {read,write}_register_bytes :-) 
> 
> 
> Hmm, no.  The more I look into read/write_register bytes the more that I'm 
> forced to the conclusion that it is just irredeemably broken when used by 
> gdb-core.
> 
> Consider executing the following statement on an ARM debug session with 
> the arm_apcs_32 variable set to zero.
> 
> (gdb) set $pc=main
> 
> In this mode the register r15 (the real PC register) is a combination of 
> the two pseudo registers $pc and $cpsr (the program status register), but 
> gdb-core doesn't know anything about this.
> 
> However, gdb-core currently performs the above asignment in valops.c by 
> using the write_register_bytes call with REGISTER_BYTE($pc) as the offset 
> into the regcache.  REGISTER_BYTE(reg) must always return something useful 
> or gdb will just crash, so we are forced to return the address of the raw 
> R15 value in the cache.

(cf other post containing reference to OP_REGISTER - OP_REGISTER needs 
to be replaced by something using register indexes and offsets)

There is a ``work around'' for this immediate problem.

I'm going to add a register_bytes() method to regcache that makes the [0 
.. NUM_REGS + NUM_PSEUDO_REGS) contigious and returns an offset based on 
that assumption.

write_register_bytes(), with the suggested change, will convert the 
offset back to a regnum and call write_register_gen() with that.

> Write_register_bytes will then overwrite the raw value in the cache 
> without any regard to the masking operations that should be occuring when 
> updating R15; the CPSR bits in the PC are just clobbered and we are left 
> with a broken value in the R15 register.
> 
> Conclusion: write_register_bytes is so broken that if gdb-core continues 
> to use it I shall have to have separate cache entries for the different 
> bits of R15 and then make the target code do the merging -- this is 
> substantially what the existing code in CVS does, but what I've been 
> trying to move away from (since currently two regcache entries can refer 
> to R15).

It's not dead yet.  ``struct regcache'' eliminates one of its two uses. 
  Hopefully making the next step easier.

Rock warning: GDB uses the above to handle (with limited success) values 
that cross two registers.  For instance a long long in two adjacent long 
registers.  See value_from_register().

Andrew