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

Andrew Cagney
2002-05-18T19:08:31Z

> 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