Re: [patch/wip] Save/restore cooked registers

[Andrew Cagney <ac131313@ges.redhat.com>]

>> 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.

No.  read_register_bytes() was intentionally changed from NUM_REGS to 
NUM_REGS+NUM_PSEUDO_REGS.

I've encountered architectures that use memory mapped register locations 
as part of their ABI and hence, rely on those locations being saved.  I 
suspect that the m69hc11 falls into this category (but it isn't the 
target I've in mind).

Anyway, the branch now defaults to saving just the first [0 .. 
NUM_REGS).  A target is free to replace this with code that saves an 
arbitrary register set in the range [0 .. NUM_REGS+NUM_PSEUDO_REGS) range.

I should note that core gdb knows none of this.  It just asks for a 
register cache to be saved / restored.

>> - disallow writes to a saved copy of the register cache
> 
> 
> I don't see that this matters, see below.

What should the regcache do with a write to a saved register cache when 
the write is ment to go to memory?

Given that GDB never even tries to write to a saved cache, I think 
formalizing this, and disallowing writes to a saved cache, is reasonable.

>> 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.

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.

A saved copy of the register cache is simply that, a snapshot.  It just 
needs to ensure that the saved value of all cooked registers (involved 
in the ABI) are available.   How it does this, well you don't want to 
know :-)

> 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).

Cooked vs raw only appears:

- in the register cache (where it needs to know what to access when) 
(but the core is clueless to this)

- in the target back-end where it needs to map cooked registers onto raw 
registers or the register cache

Long term, core gdb should find itself only refering to frame_register*()

> 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:

- has registers mapped onto memory locations

- has non ABI registers (should not be saved / restored)

enough rope to hang themself while still keeping the common case (just 
save raw registers) simple.

enjoy,
Andrew