This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [wip/cagney_regbuf-20020515-branch] Introduce regcache_move()
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Richard dot Earnshaw at arm dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 18 May 2002 15:08:38 -0400
- Subject: Re: [wip/cagney_regbuf-20020515-branch] Introduce regcache_move()
- References: <200205181117.MAA27270@cam-mail2.cambridge.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.
(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