From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21000 invoked by alias); 5 May 2008 16:27:52 -0000 Received: (qmail 20991 invoked by uid 22791); 5 May 2008 16:27:52 -0000 X-Spam-Check-By: sourceware.org Received: from mail.windriver.com (HELO mail.wrs.com) (147.11.1.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 05 May 2008 16:27:25 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m45GROP5029957 for ; Mon, 5 May 2008 09:27:24 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 May 2008 09:27:23 -0700 Received: from [147.11.233.140] ([147.11.233.140]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 May 2008 09:27:23 -0700 Message-ID: <481F356B.2050800@windriver.com> Date: Mon, 05 May 2008 16:27:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Reporting non-stop support References: <200805042102.30612.vladimir@codesourcery.com> In-Reply-To: <200805042102.30612.vladimir@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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-05/txt/msg00043.txt.bz2 I just think this shows how important it is that the client be able to use the same protocol to communicate in either mode, and be able to use the event data alone to determine what state actually changed on the target. Cheers, Pawel Vladimir Prus wrote: > As discussed before, it would be nice if GDB could report if the current > target supports non-stop, so that frontend can act accordingly (even if > "accordingly" means saying "sorry, non-stop is not supported"). > However, it's a bit tricky, because until we do "run", the two > targets on the target stack are dummy target and exec_ops -- neither of > which, naturally, have any clue about non-stop. > > It's only when we do "run" when find_default_run_target is called, and > something reasonable is pushed to the target stack. Which means that > until we do "run", we don't know if the target supports non-stop, and > when we do "run", it's a bit too later to set non-stop mode. > > Any suggestions? > > - Volodya >