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] |
No. read_register_bytes() was intentionally changed from NUM_REGS to NUM_REGS+NUM_PSEUDO_REGS.I suspect this is why the old code was saving the full register range.I think it saved the entire range because it didn't know any better.
What should the regcache do with a write to a saved register cache when the write is ment to go to memory?- disallow writes to a saved copy of the register cacheI don't see that this matters, see below.
Remember, cooked registers map onto both raw registers and memory. If cooked registers are not saved, gdb will need to start saving chunks of memory.If this isn't done, there is a problem with keeping the cooked registers coherent.
No, the cooked registers can never be incoherrent if you just consider them as view-ports onto a register-cache set. That is, they have no persistent state in themselves.
I really think we need to break this implicit link between the raw regs and part of the cooked regs, it just causes no-end of confusion. It's fine if we want to say that some cooked regs are mapped 1:1 onto part of the raw regcache, but that should/must be a back-end convenience, and not part of gdb's fundamental design (that is asking for the r0 cooked view may just happen to fetch the raw r0 register that is at offset zero in the regcache, but nothing in GDB-core should assume this).BTW, it turns out that nothing in core GDB is assuming this (ignoring the CONVERTABLE mess). Elena's e500 port maped everything onto a totally cooked register and nothing noticed. Core gdb just deals with cooked registers (or their ulgh offset).
If you are trying to just add some code that optimizes the storing of registers back to the inferior, then surely the easiest way to do this is to have a further 'inferior' set of values that we never update, then when we need to update a value we check to see if the value we want to write matches that which we know the inferior to have and suppress the write if there is no change.I'm not. The objective is to hand a target that:
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |