Re: more on gdb server

Re: more on gdb server

[Quality Quorum]

On 18 Jul 2001, J.T. Conklin wrote:

> > > I know HP were once playing with ideas that would have eliminated any 
> > > copying because they were finding memory read/write performance using 
> > > ptrace (or what ever) lacking.
> > 
> > I would suppose they had something truly unusual - debuggin is going with 
> > the pace of human reaction to debugging events and I can hardly imagine
> > that network performance over local loop interface would be a factor here.
> 
> Remember that GDB may be issuing many low level commands for each high
> level (CLI) command.  For example, a single step or next command may
> issue several step instruction, fetch registers, and store registers
> commands.  On some large programs, some interactive commands are
> beyond the interactive threshold (something like .3 seconds?  I can't
> remember the commonly quoted figure), this additional overhead would
> only make it worse.
> 
> Also note that oftentimes it's not a human driving the debugging
> session, but user defined functions that grovel through data
> structures, call inferior functions, etc.

I still have hard time to beleive that there is an issue here.

>         --jtc

Thanks,

Aleksey

Re: more on gdb server

[Daniel Jacobowitz]

On Wed, Jul 18, 2001 at 03:40:57PM -0400, Quality Quorum wrote:
> On 18 Jul 2001, J.T. Conklin wrote:
> 
> > > > I know HP were once playing with ideas that would have eliminated any 
> > > > copying because they were finding memory read/write performance using 
> > > > ptrace (or what ever) lacking.
> > > 
> > > I would suppose they had something truly unusual - debuggin is going with 
> > > the pace of human reaction to debugging events and I can hardly imagine
> > > that network performance over local loop interface would be a factor here.
> > 
> > Remember that GDB may be issuing many low level commands for each high
> > level (CLI) command.  For example, a single step or next command may
> > issue several step instruction, fetch registers, and store registers
> > commands.  On some large programs, some interactive commands are
> > beyond the interactive threshold (something like .3 seconds?  I can't
> > remember the commonly quoted figure), this additional overhead would
> > only make it worse.
> > 
> > Also note that oftentimes it's not a human driving the debugging
> > session, but user defined functions that grovel through data
> > structures, call inferior functions, etc.
> 
> I still have hard time to beleive that there is an issue here.

Consider software watchpoints, already almost uselessly slow.  Consider
single-stepping over a single line of code consisting of forty or four
hundred machine instructions.  There can be a significant overhead.

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

Re: more on gdb server

[Quality Quorum]

On Wed, 18 Jul 2001, Daniel Jacobowitz wrote:

> On Wed, Jul 18, 2001 at 03:40:57PM -0400, Quality Quorum wrote:
> > On 18 Jul 2001, J.T. Conklin wrote:
> > 
> > > > > I know HP were once playing with ideas that would have eliminated any 
> > > > > copying because they were finding memory read/write performance using 
> > > > > ptrace (or what ever) lacking.
> > > > 
> > > > I would suppose they had something truly unusual - debuggin is going with 
> > > > the pace of human reaction to debugging events and I can hardly imagine
> > > > that network performance over local loop interface would be a factor here.
> > > 
> > > Remember that GDB may be issuing many low level commands for each high
> > > level (CLI) command.  For example, a single step or next command may
> > > issue several step instruction, fetch registers, and store registers
> > > commands.  On some large programs, some interactive commands are
> > > beyond the interactive threshold (something like .3 seconds?  I can't
> > > remember the commonly quoted figure), this additional overhead would
> > > only make it worse.
> > > 
> > > Also note that oftentimes it's not a human driving the debugging
> > > session, but user defined functions that grovel through data
> > > structures, call inferior functions, etc.
> > 
> > I still have hard time to beleive that there is an issue here.
> 
> Consider software watchpoints, already almost uselessly slow.  Consider
> single-stepping over a single line of code consisting of forty or four
> hundred machine instructions.  There can be a significant overhead.

I would say that it is a stong case to make protocol a tiny little bit
more rich :).

> Daniel Jacobowitz                           Carnegie Mellon University

Thanks,

Aleksey

Re: more on gdb server

[Andrew Cagney]

> Consider software watchpoints, already almost uselessly slow.  Consider
>> single-stepping over a single line of code consisting of forty or four
>> hundred machine instructions.  There can be a significant overhead.
> 
> 
> I would say that it is a stong case to make protocol a tiny little bit
> more rich :).


Step out of range already does this for this case.

	Andrew

Re: more on gdb server

[Quality Quorum]

> I know HP were once playing with ideas that would have eliminated any 
> copying because they were finding memory read/write performance using 
> ptrace (or what ever) lacking.

I would suppose they had something truly unusual - debuggin is going with 
the pace of human reaction to debugging events and I can hardly imagine
that network performance over local loop interface would be a factor here.

> 
> enjoy,
> 	Andrew

Thanks,

Aleksey
 

more on gdb server

[Quality Quorum]

Hi, 

I am not sure I am right about it, but it seems quite a neat idea to use
gdbserver as a primary interface even for a local debugging. It is cheap
resource wise and will provide for a neat separation of debugger per se
and (target dependable) target control code.

Thanks,

Aleksey

Re: more on gdb server

[Stan Shebs]

On Tuesday, July 17, 2001, at 11:57 AM, Quality Quorum wrote:

> Hi,
>
> I am not sure I am right about it, but it seems quite a neat idea to use
> gdbserver as a primary interface even for a local debugging. It is cheap
> resource wise and will provide for a neat separation of debugger per se
> and (target dependable) target control code.

I'm not convinced that the overhead is negligible.  You're
inserting an additional program and network stack trip in one
of the two known time-critical parts of GDB.  I think it should
be *possible* to use gdbserver all the time, but I'd want to see
encouraging performance numbers before advocating that we commit
to using it.  (Having gdbserver functional on all native configs
is kind of a prerequisite too. :-) )

Stan

Re: more on gdb server

[Quality Quorum]

On Tue, 17 Jul 2001, Stan Shebs wrote:

> On Tuesday, July 17, 2001, at 11:57 AM, Quality Quorum wrote:
> 
> > Hi,
> >
> > I am not sure I am right about it, but it seems quite a neat idea to use
> > gdbserver as a primary interface even for a local debugging. It is cheap
> > resource wise and will provide for a neat separation of debugger per se
> > and (target dependable) target control code.
> 
> I'm not convinced that the overhead is negligible.  You're
> inserting an additional program and network stack trip in one
> of the two known time-critical parts of GDB. 

We can run it over UNIX sockets if performance is going to be an issue,
however, I strongly doubt it - we are running our GUI this way and
performance is not so bad.


> I think it should
> be *possible* to use gdbserver all the time, but I'd want to see
> encouraging performance numbers before advocating that we commit
> to using it.  (Having gdbserver functional on all native configs
> is kind of a prerequisite too. :-) )

As I told I am not sure about it and there is work involved, however,
it would make for a much cleaner design.
 
> 
> Stan
> 

Thanks,

Aleksey

Re: more on gdb server

[Daniel Jacobowitz]

On Tue, Jul 17, 2001 at 05:25:08PM -0700, Stan Shebs wrote:
> On Tuesday, July 17, 2001, at 11:57 AM, Quality Quorum wrote:
> 
> > Hi,
> >
> > I am not sure I am right about it, but it seems quite a neat idea to use
> > gdbserver as a primary interface even for a local debugging. It is cheap
> > resource wise and will provide for a neat separation of debugger per se
> > and (target dependable) target control code.
> 
> I'm not convinced that the overhead is negligible.  You're
> inserting an additional program and network stack trip in one
> of the two known time-critical parts of GDB.  I think it should
> be *possible* to use gdbserver all the time, but I'd want to see
> encouraging performance numbers before advocating that we commit
> to using it.  (Having gdbserver functional on all native configs
> is kind of a prerequisite too. :-) )

I'd be more interested in making it possible to run the testsuite using
a native gdbserver; unless someone else does (or is it already possible
and just not well-documented?) I'll look in to this.

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