From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28956 invoked by alias); 7 Sep 2007 05:43:17 -0000 Received: (qmail 28943 invoked by uid 22791); 7 Sep 2007 05:43:16 -0000 X-Spam-Check-By: sourceware.org Received: from esparsett.troll.no (HELO esparsett.troll.no) (62.70.27.18) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Sep 2007 05:43:11 +0000 Received: from esparsett.troll.no (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5598774288 for ; Fri, 7 Sep 2007 07:43:08 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by esparsett.troll.no (Postfix) with ESMTP id 3E7CE7418E for ; Fri, 7 Sep 2007 07:43:08 +0200 (CEST) From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb@sourceware.org Subject: Re: MI: "^running" issues Date: Fri, 07 Sep 2007 05:54:00 -0000 User-Agent: KMail/1.9.6 References: <200709041653.22357.ghost@cs.msu.su> <200709062241.01815.ghost@cs.msu.su> In-Reply-To: <200709062241.01815.ghost@cs.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709070742.59544.apoenitz@trolltech.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: 2007-09/txt/msg00067.txt.bz2 On Thursday 06 September 2007 20:41:01 Vladimir Prus wrote: > > Those are always bugs, and we fix them when we find them, but yes that > > did happen - hasn't happened in a while though. What happens more > > often now for us is that we rely a lot on calling functions to inspect > > opaque data types when the target stops. This often goes bad - people > > right data inspectors that can deadlock for instance... So it's > > useful to have some "resync with gdb" action that check's gdb's state > > and does the right thing based on what it is. > > You mean, calling functions in the program? Then, presumably if they > hang, you get to interrupt their execution and somehow restore program > context? Why do you need to know if inferior is running, in this case? > As soon as you call a function in program, program is running ;-) For a while. Then it may stop. Most times you get a notice. Sometimes you don't. Sometimes (most notably gdb/cygwin) the notice gets mangled with whatever output the called "data dumper function" produces and it is no more recognizable by the "result parser". Sometimes "old" output arrives after calling into the inferior. Some of the scenarios might point to bugs in the Gui, some might not. In any case, there are lots of reasons why one might want a method to get absolute state information out of Gdb at "random" times. > > > I presume this is only relevant when gdb is combined with some other > > > code in the same process? Last time I've asked about this, I was > > > told that it not supported, because gdb does fancy things with > > > signals, or something like that. It works well enough for simple cases. Most troubles I have had so far is with memory allocation and result passing on Windows. So if one manages to do the work without dynamic allocations and finds a way that does not mangle "data dumper output" with ordinary gdb output, the method is fairly robust. Most notably it also works when the data dumper segfaults. Of course, having a "real" interpreter within Gdb would be really nice... Andre'