From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10615 invoked by alias); 1 May 2008 17:00:13 -0000 Received: (qmail 10604 invoked by uid 22791); 1 May 2008 17:00:12 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 May 2008 16:59:55 +0000 Received: (qmail 24341 invoked from network); 1 May 2008 16:59:53 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 May 2008 16:59:53 -0000 From: Vladimir Prus To: Pawel Piech Subject: Re: MI non-stop interface details Date: Thu, 01 May 2008 17:00:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb@sources.redhat.com References: <200804261939.37635.vladimir@codesourcery.com> <4819F4D4.4010305@windriver.com> In-Reply-To: <4819F4D4.4010305@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200805012059.50679.vladimir@codesourcery.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00007.txt.bz2 On Thursday 01 May 2008 20:50:28 Pawel Piech wrote: =20=20=20=20=20=20 > > In DSF-GDB there _is_ a central place where commands are sent, this is > > where the protocol state is adjusted using -thread-select. However, the > > --thread option is being added to many but not all commands, so the same > > mechanism that adds the -thread-select could not be reused to add > > --thread option. Instead each command which accepts --thread that would > > need to be adjusted to use the --thread, but only when in non-stop > > debugging mode. >=20=20=20=20=20 >=20 > This is not actually. The plan is for eery command will accept --thread.= =20=20 > Those that don't have any use of it will ignore it. The only command, > at the moment, for which the meaning of --thread is not yet clear, and for > which the frontend might have to have custom decision logic, is --exec-co= ntinue. >=20 > - Volodya >=20=20=20 > That's helpful.=A0 Unfortunately UI clients that want to have a wide use= r base still=20 > need to worry about old GDB versions which do not support -thread, and t= hat was my=20 > first point in this thread.=A0 As I've seen on this mailing list there a= re users out=20 > there still on GDB 5.x.=A0 I expect it will take several=20 > years before support for GDB 6.8 and prior is not so important.=20=20=20= =20 And where's the issue? On startup, issue -list-features. If you get error, = this is old GDB. If the output of -list-features does not include "thread-option", this= version of GDB does not support --thread (and don't not support non-stop, either). The= n, you can make appropriate runtime decisions. It seems better to me to make such = global decision right after starting GDB, rather than guessing things from output = of *stopped, and other indirect mechanisms. [Note that "thread-option" is not yet produced by -list-features, because t= he support for --thread is not yet in FSF tree] - Volodya