Re: parcelling up struct gdbarch

[Daniel Jacobowitz <dmj+@andrew.cmu.edu>]

On Tue, Jul 17, 2001 at 01:46:48PM -0400, Andrew Cagney wrote:
> 
> > I think that's acceptable.  The ptrace buffer meets some important
> > criteria:
> >  - it rarely changes, except perhaps to grow (SSE, altivec).
> >  - We already have to have code to parse it (in order for native gdb
> >    to work) although this code may not be easily cross-friendly
> 
> 
> See other e-mail about signals/events having similar problems.

[I really need to think email out before I send it a little more, I
said the exact opposite of the above further down.  Oh well.]

> There are two cases:
> 
> 	o	GDB talking to one of those old stubs
> 
> 	o	GDB talking to a not yet written stub
> 
> Even if someone did magic a new stub, GDB would still need to be able to 
> talk to all the old stubs.  Consequently, I'll only look at old stubs.

Right.  Depending how this shapes out we may want a protocol extension
for new stubs to do it better, but that's not the issue here.

> With that in mind, I think, the G-packet <-> raw register mapping 
> shouldn't be per gdbarch hard-coded but instead driven by something the 
> user can specify on the command line.  Short term, some sort of 
> hardwiring might be accepted.
> 
> Refering back to that figure:
> 
>    G-packet registers
>      |
>    raw registers
>      |
>    cooked registers
> 
> If raw registers are given names independant of the user visible cooked 
> registers then, something as silly as:
> 
> 	0:gpr0,4;1:gpr1,4;4;3:spr0;8;4;...
> 
> would even work.

I don't understand why you say that we would need more than one
G-packet format per gdbarch.  Why?  Compatibility with different stubs? 
That seems like the wrong approach.  We've currently got one G-packet
format per definition of the register cache, and we've got one of those
per gdbarch, right?

I don't really understand what you mean by that string, either what the
fields or supposed to be or what it is supposed to define.

> John S. Kallal submitted a patch: ``[PATCH] Add remote P packet ...'' 
> It needed to be split in two (cleanup VS change) and along with a few 
> other tweeks.

OK, I see it.  The change will need to be completely redone after
whatever we decide for this, of course.

> > Rather than letting ideas continue to bounce around, how's this:
> >  - add an arch request to GDB and gdbserver.  It seems more natural for
> > gdbserver to send its architecture and gdb acknowledge if it
> > understands; but a qArch would work too.
> 
> 
> See the multi-arch white paper.  It notes both alternatives. qArch is 
> probably more inline with other parts of the protocol.  I don't think 
> you need to do this to solve the current problems.

I'm about to go read this more thoroughly.

Sure, we don't NEED it to solve this problem.  However, it would be a
logical extension at this point in time.  I'll address it separately.

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