This is the mail archive of the
mailing list for the GDB project.
Re: A better register interface
- To: Peter Reilley <micrio at mv dot com>
- Subject: Re: A better register interface
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 15 Feb 2001 21:15:16 -0500
- Cc: GDB Discussion <gdb at sources dot redhat dot com>
- References: <004a01c097b1$d149bc90$05d145cc@ppro>
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
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:
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)