RFC: Two small remote protocol extensions

[Andrew Cagney]

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

enjoy,
Andrew

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