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

[Richard Earnshaw <rearnsha@arm.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.

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).

R.