Re: [rfa] gdbserver 1/n - PBUFSIZ

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>]

On Thu, Jul 19, 2001 at 04:13:55PM -0400, Andrew Cagney wrote:
> > The things I've been discussing w.r.t. qRegisters and such need to be done,
> > but they also need to be done properly, and I certainly won't have time to
> > do enough testing before 5.1.  It's possible to make gdbserver work in
> > roughly the right way, such that it will be friendly to the new work when
> > that's ready, without all the intrusive changes.  I'm going to try to do
> > that in time for 5.1.
> 
> 
> (Urgency can be a dangerous thing |8-)

Or a useful thing :)  What I'm doing right now is a little tedious, but
fairly simple.

> I think a simple summary of your plan is that you would like to strip as 
> many layers of gdbserver as possible so that it supplies a raw _ptrace_ 
> buffer to GDB as the G-packet.
> 
> Correct?

No.  That was one of my worse ideas.  We've got existing formats, based
on the internal register cache, for each target gdbserver supports. 
I'm separating the numbers gdb uses to address the register cache
(PC_REGNUM, for instance - multiarched on PPC and others) from where in
the remote packet they actually are.

The side effect of this is that it's an awful lot of code with no
immediate effect; the format of the packets does not change.  Thus I
can postpone the more complicated gdb-side work until later.  I'm doing
the gdbserver side only right now.

> > Here's the first bit.  PBUFSIZ is used as an array initializer, but defined
> > in terms of REGISTER_BYTES - which might not be a constant, and which I'd
> > rather hide anyway.  Later on, the design I'm hashing out for gdbserver's
> > register cache will make it very easy to find the maximum value of
> > REGISTER_BYTES, and we can make PBUFSIZ flexible again; for now, I made it
> > "big enough".
> 
> 
> If I'm correct above, why not just ask your backend how big it thinks 
> that register buffer is (via a function call).  For some targets it 
> looks like it is just (sizeof (inferior_registers) + sizeof 
> (inferior_fp_registers)) for others it is a little bit more tricky but 
> nothing more.

Well, the other issue is that it's currently assumed to be a constant. 
It's used for, e.g., an array at the top of main().  I could make it a
variable and change all the arrays to alloca(), I suppose, but I'm not
thrilled with that either.

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