This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]