Re: RFC: Two small remote protocol extensions

Andrew Cagney
2002-05-02T20:13:31Z

> 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

Joint. I think the consensus was that the advantages of a more robust
mechanism (some will laugh at the very suggestion that the GDB protocol
is even vaguely robust :-) outway the disadvantages of having the
protocol synchronous.

> replies. However, I'd like to add another point of view.

At one level I agree with you completly, unfortunatly the remote
protocol, as it stands, just don't work that way :-( The ``O'' packet
while ``a good idea at the time'' (sarcasm) just doesn't cut it when it
comes to providing something that is reliable.

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

Optional or not, it needs to be reliable. You need to be able to run a
test cases 1000 times and have it pass 1000 times.

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

Hmm, I think you're trying to combine several disjoint features into a
single mechanism.

Feature #1 is notify GDB of [remote] thread create/delete events.
Feature #2 is allow some [remote] threads to continue running while
others (just current?) have stopped.

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

Yes, feature #2 above.

enjoy,
Andrew