From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27771 invoked by alias); 31 Mar 2008 15:48:37 -0000 Received: (qmail 27758 invoked by uid 22791); 31 Mar 2008 15:48:37 -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, 31 Mar 2008 15:48:13 +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 m2VFmBZE003372 for ; Mon, 31 Mar 2008 08:48:11 -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, 31 Mar 2008 08:48:11 -0700 Received: from [147.11.233.126] ([147.11.233.126]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 08:48:11 -0700 Message-ID: <47F107A6.4070808@windriver.com> Date: Mon, 31 Mar 2008 16:49:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Re: Calling inferior functions and MI notification References: <200803271949.10914.vladimir@codesourcery.com> In-Reply-To: <200803271949.10914.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-03/txt/msg00279.txt.bz2 It would be helpful if *running event included a "reason" field. IDE's ususally track the command they just sent to determine the reason for resume event, but as it's an out-of-band record there is a possibility of a race condition which could break the IDE assumption. Cheers, Pawel Vladimir Prus wrote: > Hello, > presently, when a GDB command calls an inferior function, for > example: > > -data-evaluate-expression foo() > > the MI frontend is not informed in any way. So, should the function > get stuck, the user will not even understand that inferior is running, > and will have hard time figuring that he should click the "interrupt" > button, or whatever. > > Ideally, the output should be like this: > > (gdb) -data-evaluate-expression foo() > *running,thread-id="1" > *stopped > ^done,result="100" > > However, I believe that making such a change will immediately break both KDevelop > and Eclipse CDT -- because whenever they see *stopped, a full refresh of everything > is done. If any variable object involves function call, *stopped will be emitted > again, and cause another refresh. At least, I cannot see anything protecting > from that. > > So, we have two solutions: > 1. Just don't emit those notification for inferior function calls. > 2. Don't emit them by default. Provide a command to enable this new > behaviour. > > Comments or better suggestions? > > - Volodya > > > >