From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12308 invoked by alias); 31 Mar 2008 16:55:50 -0000 Received: (qmail 12291 invoked by uid 22791); 31 Mar 2008 16:55:50 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 31 Mar 2008 16:55:30 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JgNI1-0003Hd-Qf for gdb@sources.redhat.com; Mon, 31 Mar 2008 16:55:22 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Mar 2008 16:55:21 +0000 Received: from ghost by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Mar 2008 16:55:21 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Calling inferior functions and MI notification Date: Mon, 31 Mar 2008 22:05:00 -0000 Message-ID: References: <200803271949.10914.vladimir@codesourcery.com> <47F107A6.4070808@windriver.com> <47F115EA.1060101@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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/msg00282.txt.bz2 Pawel Piech wrote: > Vladimir Prus wrote: >> Pawel Piech wrote: >> >> >>> 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. >>> >> >> Hello Pawel, >> >> can you clarify what the 'reason' field should contain? I think that in >> general, reporting the command that caused the run might be impossible. >> >> > Too bad, because that's what I had in mind.... Like I said, IDE's > including Eclipse usually solve this problem on their own, though the > solution is theoretically susceptible to a race condition in cases where > multiple interfaces are used to interact with GDB simultaneously. In what cases associating "*running" with a command is important? You still get "^running", so you know what the command started something. The "*running" can be used to update the state of the threads in UI. I'm actually thinking of making -thread-info report the operation that each running thread executes, like "step" or "finish" -- when that information is available. - Volodya