From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25812 invoked by alias); 27 Apr 2008 15:38:42 -0000 Received: (qmail 25804 invoked by uid 22791); 27 Apr 2008 15:38:41 -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; Sun, 27 Apr 2008 15:38:20 +0000 Received: (qmail 20823 invoked from network); 27 Apr 2008 15:38:18 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Apr 2008 15:38:18 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: [MI] enabling non-stop mode Date: Mon, 28 Apr 2008 14:20:00 -0000 User-Agent: KMail/1.9.9 Cc: Nick Roberts , Vladimir Prus References: <200804262216.16948.vladimir@codesourcery.com> <18452.12385.71094.702844@kahikatea.snap.net.nz> In-Reply-To: <18452.12385.71094.702844@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200804271638.16646.pedro@codesourcery.com> X-IsSubscribed: yes 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-04/txt/msg00231.txt.bz2 [ Just a thought dump ] A Sunday 27 April 2008 08:50:57, Nick Roberts wrote: > > > > Probably, we can extend this to enable feature that are not MI > > > > proper, say: > > > > > > > > (gdb) -list-features > > > > ^done,features=3D[....,"non-stop",....] > > > > (gdb) -enable-feature non-stop > > > > ^done > > > > > > > > The only issue here is that non-stop mode availability in general > > > > depends on the target, so maybe we should have a separate commands > > > > to list "target" feature and then enable target features? > > > > > > Why not just use -gdb-set? > > > > > > maint set linux-async --> set linux-async --> -gdb-set > > > linux-async maint set non-stop --> set non-stop -->=20 > > > -gdb-set non-stop > > > > This will now allow the frontend to check if non-stop mode is supported > > at all. > > I mean list "non-stop" as a feature, which AFAICS just outputting a string > field, _and_ do: > > add_setshow_boolean_cmd ("non-stop",... > > I don't see the benefit of another MI command like -enable-feature and > that way non-stop mode can be more easily made available to CLI. That is how we have it implemented currently, although as a user command, not a maintenance command, since this is a setting the user will want to toggle, not just maintainers. Our current implementation has: (gdb) help show non-stop Show whether gdb controls the inferior in non-stop mode. Tells gdb whether to control the inferior in non-stop mode. Which does allow for some for of quering GDB support (not target support) of non-stop by parsing: Current GDB: =A0(gdb) show non-stop =A0Undefined show command: "non-stop". =A0Try "help show". GDB with non-stop support: =A0(gdb) show non-stop =A0Controlling the inferior in non-stop mode is off. (yes -- non-ideal, and ignores i18n issues) We can't always know if the target supports non-stop before the target is active -- think remote.c, where the stub will have to report if non-stop is supported -- we can't know if the stub supports non-stop before connecting to it. We'll want to be able to attach to a live system without stopping any particular thread, if the target supports that. Assuming the target supports it, the user will want to set non-stop mode before attaching to a running target, not after -- otherwise it may be too late, and some breakpoint may cause all threads to stop, before the user has a chance to set non-stop mode. We currently assume that changing all-stop<->non-stop modes can only be done while !target_has_execution. We could have just the global setting, and warn/error as soon as we detect the target doesn't support it. --=20 Pedro Alves