Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, May 02, 2002 at 12:39:37PM -0400, Andrew Cagney wrote:
> I'm fairly sure that the archives have plenty of info on the ``O'' 
> packet and why/how it should be replaced.  One thread is ``gdb/remote - 
> I/O''.

Ah, I've found the thread.  I see that there was a rough consensus
(among just about everyone but J.T. Conklin, who I believe was remote
maintainer at the time?) about the disadvantages of asynchronous
replies.  However, I'd like to add another point of view.

These are threading information packets.  They are completely optional,
and I believe that they are of an appropriate nature for the
environments which support it; such systems generally:

  a) Should have no trouble implementing asynchronous responses.
	It needed about fifteen lines of code changed in gdbserver,
	so most Unix-alikes should be fine.  VxWorks could certainly
	do it as well.

  b) Desire the least-intrusive possible thread debugging.
	These aren't niche events; in a multithreaded application,
	thread creation and deletion can happen very frequently, and
	with a large number of running threads.  I've heard a lot
	of complaints about how much our intrusive thread debugging
	harasses scheduler priorities.

I'd rather ditch the notifications entirely than stop other threads;
I'll keep the notification code out of the FSF tree until we can figure
out a generally acceptable way to pass asynchronous status
notifications back to the client.  I really don't see the problem with
my suggestion, though.

Heck, if I can work out a way to do it safely, I intend to do
one-thread-stopped-only SVR4 shared library support also.  I've heard
that starting apache2 (multithreaded, and with all modules as DSOs)
takes several minutes instead of the second or two that it takes
without GDB attached.

> >No.
> >>
> >>Telling GDB of thread create/delete events is a good idea, but please, 
> >>do it synchronously (we've already got the ``O'' packet and that is bad 
> >>enough).
> >>
> >>Have you tried:
> >>	T00Thread....?
> >>for the create event.  (signal 0 is loosely defined as a non-event).
> >
> >
> >That defeats the point of a fast thread debugging package.  I do not
> >want to stop threads at creation/death events; I put in quite a lot of
> >work to avoid it.  That scales very badly.  The alternative was to just
> >report all thread events at the next stop, but it is much more
> >user-intuitive to do it immediately.
> 
> >Could you please explain why you are opposed to asynchronous
> >notification?  The 'O' packet doesn't seem to be "bad enough";
> >doing output notification synchronously just seems silly.
> >
> >(Note that they're still ack'd, like standard remote packets.  It's
> >just that the target isn't stopped.)
> 
> 
> 
> 
> 

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