Re: [RFA] Basic structure to describe register formats

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Feb 01, 2002 at 04:50:17PM -0500, Andrew Cagney wrote:
> >On Fri, Feb 01, 2002 at 04:10:16PM -0500, Andrew Cagney wrote:
> >
> >>Almost approved,  I've been pokeing at random targets that once worked 
> >>and they have now all been broken by multi-arch.
> >>
> >
> >>>@@ -0,0 +1,28 @@
> >>>+name:arm
> >>>+resume:r11,sp,pc
> >>>+4:r0
> >>>+4:r1
> >>>+4:r2
> >
> >>
> >>
> >>My only quarm is with this.  It extends the G packet definition a little 
> >>- lines with a leading letter get ignored just like comments and blanks. 
> >>Correct?
> >
> >
> >Do we even have such a definition?  I didn't think we did yet.
> 
> 
> We have what I posted a while back :-)
> 
> 
> >If so, then yes, I think that's a good extension.  Also I would commit
> >it with the number in bits rather than bytes.
> 
> 
> You mean - 32:r1?
> 
> I think the ``4'' indicates 4*2 hex digits.  Digit pairs ordered either 
> big or little endian.  Yes it could be bits, however, the value would 
> always need to be divisible by 8.

No, I don't think it needs to be divisible by 8.  If it did I wouldn't
feel the need to represent the 8.

For instance:
 - ia64 has 1-bit registers that we currently transmit as either bytes
or words, IIRC.
 - someone mentioned recently working on a non-8-bit target for GDB,
but he wasn't quite ready to contribute it.

But it will be divisible by 8 for now, so we'll just ignore that for
the moment.

> >>Any way I think EXPEDITE to better word for describing what is to be 
> >>done with those registers.  SID uses that word to describe this exact 
> >>same list.
> >
> >
> >That's a good word for what's going on here, I quite like it.  OK with
> >that change?
> 
> 
> Yes.
> 
> done.

Committed with updates.  I settled on putting both the header and shell
script in with the data files for now, unless we decide we need them
somewhere else.


Next, code to use them.  Did you reach a decision about preserving
existing targets?  I would like to:
  - Mark OBSOLETE, or perhaps CURRENTLY OBSOLETE, NEEDS WORK the other
  (non-Linux in this pass) targets.
  - Fix Linux targets cleanly.
  - Get at least *BSD fixed soon, which should not be hard.
  - Accompanying changes to configury at each stage.

It'll save me a lot of general aggravation to do it the way I outline
above, and I think that was the consensus, but I'd like to know before
I sit down and do it.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer