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: [patch/wip] Save/restore cooked registers



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




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