From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 844 invoked by alias); 19 Mar 2008 16:51:10 -0000 Received: (qmail 834 invoked by uid 22791); 19 Mar 2008 16:51:09 -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; Wed, 19 Mar 2008 16:50:50 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jc1Uv-0001Li-Eq for gdb@sources.redhat.com; Wed, 19 Mar 2008 16:50:42 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 16:50:41 +0000 Received: from vladimir by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 16:50:41 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: -exec-step over a blocking function call Date: Wed, 19 Mar 2008 19:38:00 -0000 Message-ID: References: <47E13AAD.9050504@qnx.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/msg00163.txt.bz2 Aleksandar Ristovski wrote: > Hello, > > I have encountered a problem using MI interface. It is not very easy to > reproduce, hence no real test case, but I will try to describe what I am > seeing: > > This is the situation I have: > > (gdb) > -exec-step 1 > ^running > (gdb) > ~"Single stepping until exit from function SyncSemWait, \n" > ~"which has no line number information.\n" > > > Where SyncSemWait is a blocking function (as the name suggests, waiting for > semaphore). Gdb will just sit here since the inferior has several threads, > one > of which is reading stdin waiting for user input, and apparently input would > > unblock. But until it does, gdb is sitting here. The problem I am seeing is > that > often, while waiting for SyncSemWait to return IDE would issue additional mi > > commands which eventually make gdb crash or appear frozen (unresponsive). So which is that -- crash or appear frozen? In the majority of cases, GDB does not read or processes further MI commands while waiting for the target to stop (which it does in your case). And even if it accepts commands, there's just one allowed command -exec-interrupt. If the IDE attempts to any other command, the IDE has a bug. > > I am not sure how should gdb deal with this situation. Any ideas? Please check the spec of MI changes for async targets that I've posted yesterday. It would be great if the IDE developers also glance and make omments before I implement it all. - Volodya