[rfa] gdbserver 1/n - PBUFSIZ

[rfa] gdbserver 1/n - PBUFSIZ

[Daniel Jacobowitz]

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.

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".

OK to commit?

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

2001-07-19  Daniel Jacobowitz  <drow@mvista.com>

	* gdbserver/server.h: Make PBUFSIZ a constant.

Index: server.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/server.h,v
retrieving revision 1.3
diff -u -r1.3 server.h
--- server.h	2001/03/06 08:21:44	1.3
+++ server.h	2001/07/19 18:28:05
@@ -81,6 +81,9 @@
 
 /* Buffer sizes for transferring memory, registers, etc.  Round up PBUFSIZ to
    hold all the registers, at least.  */
+/* FIXME - REGISTER_BYTES is not known at this time.
 #define	PBUFSIZ ((REGISTER_BYTES > MAXBUFBYTES (2000)) \
 		 ? (REGISTER_BYTES * 2 + 32) \
 		 : 2000)
+*/
+#define PBUFSIZ 4096

Re: [rfa] gdbserver 1/n - PBUFSIZ

[Andrew Cagney]

> 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-)

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?


> 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.

	Andrew

Re: [rfa] gdbserver 1/n - PBUFSIZ

[Daniel Jacobowitz]

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

Re: [rfa] gdbserver 1/n - PBUFSIZ

[Daniel Jacobowitz]

On Thu, Jul 19, 2001 at 06:13:35PM -0400, Andrew Cagney wrote:
> >> I take it you've also got a few more steps planned, can you give a quick 
> >> sketch of where you're going?
> > 
> > 
> > Short term: enough to make gdbserver compile on any targets it still
> > currently builds on (I have no clue which these are, for lack of test
> > hosts on many of the types) as well as more Linux targets.  If you're
> > willing, I'd like to do this somewhat messily and before the release of
> > 5.1.  It doesn't matter too much to me, since I've got no real
> > compunctions about shipping a CVS snapshot instead, but it goes against
> > my instincts to let gdbserver out the door building on so many fewer
> > targets than it did in 5.0.
> 
> 
> Where's the fire?  I know there is going to be a gdb 5.2 or 5.1.1 
> because of all the on-going C++ work.  I think getting it right is more 
> important than getting something that looks right.  Get it half right 
> and it it will stay that way for years.

Yes, that's true.  I'm going to need gdbserver to work in the
relatively short-term future, though.  I'm perfectly willing to let it
slip past 5.1 (and at this stage it seems inevitable).  Especially
since no one seems to be concerned with gdbserver having broken.

> > What I envision from here, longer term:
> >   - gdbserver registers cleanup.  This will mean precisely defining,
> >     according to present usage, the register packets of every
> >     gdbserver-supported target, or at least the ones I can test or
> >     find someone to test for me.  A lot of documentation; a lot of
> >     duplicate code elimination in gdbserver.  I'm also going to try to
> >     define the gdbserver register layout in such a way that GDB can use
> >     it too (possibly by your flexible string description approach, or
> >     just a shared structure).
> 
> 
> Just FYI, structures have compiler compatibility problems.

I didn't mean something sent over the wire; I meant a source file that
could be linked into both gdb and gdbserver.

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

Re: [rfa] gdbserver 1/n - PBUFSIZ

[Daniel Jacobowitz]

On Thu, Jul 19, 2001 at 01:21:18PM -0700, Daniel Jacobowitz wrote:
> > > 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.

[How -do- you manage to reply to one of my messages with the subject
and References: of another? :)]

Would you prefer I make PBUFSIZ non-constant and change the arrays to
alloca(), or simply make it a large constant?  Something's got to give
:)

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

Re: [rfa] gdbserver 1/n - PBUFSIZ

[Andrew Cagney]

> 
> [How -do- you manage to reply to one of my messages with the subject
> and References: of another? :)]


Que? Mozilla?


> Would you prefer I make PBUFSIZ non-constant and change the arrays to
> alloca(), or simply make it a large constant?  Something's got to give
> :)


I would suggest malloc().

	Andrew