From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24686 invoked by alias); 2 May 2002 16:39:37 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 24679 invoked from network); 2 May 2002 16:39:36 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 2 May 2002 16:39:36 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id F3F123D88; Thu, 2 May 2002 12:39:37 -0400 (EDT) Message-ID: <3CD16BC9.2010209@cygnus.com> Date: Thu, 02 May 2002 09:39:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions References: <20020502022543.GA22594@nevyn.them.org> <3CD15D5A.7020308@cygnus.com> <20020502155203.GA12647@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00012.txt.bz2 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.)