From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18342 invoked by alias); 29 Nov 2004 17:50:11 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18326 invoked from network); 29 Nov 2004 17:50:06 -0000 Received: from unknown (HELO pluton.ispras.ru) (83.149.199.253) by sourceware.org with SMTP; 29 Nov 2004 17:50:06 -0000 Received: (qmail 9727 invoked from network); 29 Nov 2004 17:50:00 -0000 Received: from unknown (HELO truba.ispras.ru) (83.149.198.41) by pluton.ispras.ru with SMTP; 29 Nov 2004 17:50:00 -0000 Received: from truba.ispras.ru (root@localhost) by truba.ispras.ru (8.13.1/8.13.1) with SMTP id iATHl9AN007727 for ; Mon, 29 Nov 2004 20:47:09 +0300 Received: from ispserv.ispras.ru (ispserv [83.149.198.72]) by truba.ispras.ru (8.13.1/8.13.1) with ESMTP id iATHl8ro007717; Mon, 29 Nov 2004 20:47:08 +0300 Received: from kite.ispras.ru (kite.ispras.ru [83.149.198.52]) by ispserv.ispras.ru (8.12.8/8.12.8) with ESMTP id iATHoEDA021871; Mon, 29 Nov 2004 20:50:14 +0300 Date: Mon, 29 Nov 2004 19:59:00 -0000 From: Konstantin Karganov Reply-To: Konstantin Karganov Organization: ISP RAS Message-ID: <13730878711.20041129205245@ispras.ru> To: Andrew Cagney CC: gdb@sources.redhat.com Subject: Re[2]: (a?)synchronous stepping commands in gdb MI, a week later In-reply-To: <41AB43C8.7050500@gnu.org> References: <3616850089.20041129165854@ispras.ru> <41AB43C8.7050500@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SpamTest-Info: Profile: Formal (168/041127) X-SpamTest-Info: Profile: Detect Standard No RBL (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release SMTP-Filter Version 2.0.0 [0125], KAS/Release X-SW-Source: 2004-11/txt/msg00259.txt.bz2 Hello Andrew, >> Does anyone know why the "-exec-*" commands family in GDB MI is >> declared asynchronous but in fact behaves synchronously (blocking the >> interface until the execution completes)? > Asynchronous behavior depends on an asynchronous backend. At present > only ``target async-remote'' is asynchronous (and then there's doubt > that it still works), hence the behavior you're seeing. So it's just obsolete documentation, that states asynchronous behavior? Or there are plans to add asynchronous commands later? One more question: when the execution of "next" (or "step") command in GDB is interrupted is there a way to know where it would stop if not interrupted? Or, maybe, the way to continue the execution of interrupted GDB command as if there was no interrupt?.. Thanks a lot. -- Best regards, Konstantin