Re: A better register interface

[Andrew Cagney <ac131313@cygnus.com>]

Peter Reilley wrote:
> 
> I have a request for a feature that I have needed.
> I would like to have a target API that allowed the
> target code to parse the reg name string and return
> the reg value if it existed or an error if it did not
> exist.   The same for a write register API.
> 
> In the case of the PowerPC, there are SPR registers
> that vary from one processor implementation to another.
> The SPR address space is 2K, but is only sparsely populated.
> Too many to include in NUM_RAW_REGISTERS.   If they could be
> created on the fly, the problem would be solved.
> Then, the "info reg" command would only print
> the defined registers but the SPR registers
> would still be accessible.

I would expect your case to be handled roughly as follows:

	o	NUM_RAW_REGISTERS would cover all
		the potential SPR registers.
		(2k is nothing :-)

	o	your target would only suply values
		for registers that the CPU really has
		(there is already a mechanism for
		indicating that a raw register isn't
		available).

		For instance it might use raw_register_name()
		to reverse lookup "spr0" to determine where
		in the buffer to put "spr0"'s data.

	o	core-gdb in conjunction with the cooked
		interface would, knowing your CPU's ISA,
		just display the SPR registers applicable
		to your ISA.

		It would use its knowledge of the mapping
		between cooked (PSW and raw spr0) and the ABI
		to construct the registers you're interested in.

It would consist of roughly:

	core-gdb
	    \
	  cooked-regs   your-target
	      \		/
	     raw-regs-buffer

Because there is a clear decoupling between the target and the
cooked-regs, it becomes possible to do things like:

	o	change the target IF
		(for instance the G packet)
		with out changing the actual ISA

	o	change the cooked regs IF
		(for instance another CPU)

Andrew