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

Richard Earnshaw
2002-05-18T11:18:00Z

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.