Re: [RFA] New register definition interface

[Andrew Cagney <ac131313 at cygnus dot com>]

Nick Duffek wrote:
> 
> On 13-Jan-2001, Andrew Cagney wrote:
> 
> >I know your code (unfortunatly) won't handle every case (new more bizare
> >cases turn up every day)
> 
> True.  But I am hoping that the new interface will gradually replace the
> old and that it will be easy to modify for more bizarre cases.

I'm actually hopeing that your code can be kept faily simple - just
handling the relativly sane cases.

> >[...regarding functions that check REGISTER_LIST...]
> >I think these should be made virtual so that your, or any other, code
> >can just drop in..
> 
> I can remove the REGISTER_LIST references from regcache.c and parse.c as
> follows:
> 
>   1. Create new gdbarch.sh methods REAL_REGISTER, PSEUDO_REGISTER, etc.
>      to replace those functions in regcache.c and parse.c.
> 
>   2. Default those new gdbarch.sh methods to non-regs.c versions, and
>      override them for architectures that opt for regs.c (i.e., in
>      regs_init_finish()).
> 
> Is that what you're suggesting?

Yes.  If the old registers[] code is ever deleted then it is easy to
do.  If another register implementation is created then it can just drop
in.

Inline with this, like *-out et.al. should reg.c be called ???-reg.c
(and not ``new-regs'' :-).

> However, I can't remove the REGISTER_LIST references from regs.c itself.

Obviously :-)

> regs_init_start (<gdbarch>) initializes a structure containing information
> specific to <gdbarch>, and as far as I can tell, there's no other way to
> attach that structure to <gdbarch>.

The gdbarch_data() or gdbarch_memory() stuff should do what you need. 
Just put the REGISTER_LIST in one of them.
Hmm, there might be a race condition on this - gdbarch_data()
initialized too late.  If there is such a problem then the interface
should be fixed.

> >Did you get VALUE_REGNO() -> VALUE_REGNUM() in that rename?
> 
> No, the rename was local to regcache.c.

I was't expecting you to.  I'll add it to my things TODO one day list.

> >The code doesn't appear to help how GDB handles register values in
> >expressions and assignments (grep for VALUE_REGNO).  Have you thought
> >about that?
> 
> By "help", do you mean "distinguish between target number and debugging
> info number"?

No.  The problem is that the code assumes that a register stored on the
stack can be described using a single address and a length.  That is so
far from reality that it is dangerous.  The consequence is that pseudo
registers can't always be included in expressions.

There should be methods for reading/writing such registers (a bit like
get saved frame reg but different - you can't save a ``struct frame'').

> The regs.c interface supports that distinction, but I haven't yet tried
> removing the assumption throughout GDB that those two numbers are the
> same.  Most register numbers throughout GDB are target numbers, so I think
> it makes sense to adopt register target numbers as abstract register
> handles and replace debugging info numbers with a gdbarch.sh method like
> REGISTER_DEBUG_NUMBER (regnum).

That is already handled by the *_REG_TO_REGNUM methods.  GDB converts
debug-info register numbers into REGNUMs.

	Andrew