From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11344 invoked by alias); 12 Feb 2007 22:07:31 -0000 Received: (qmail 11326 invoked by uid 22791); 12 Feb 2007 22:07:30 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 12 Feb 2007 22:07:25 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 8A48B48CCB2; Mon, 12 Feb 2007 17:07:23 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02767-01-9; Mon, 12 Feb 2007 17:07:23 -0500 (EST) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 4330248CBC2; Mon, 12 Feb 2007 17:07:23 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id D131634C099; Mon, 12 Feb 2007 14:08:28 -0800 (PST) Date: Tue, 13 Feb 2007 03:25:00 -0000 From: Joel Brobecker To: Kishore Paul Cc: Daniel Jacobowitz , gdb@sourceware.org Subject: Re: vCont packets for next and step Message-ID: <20070212220828.GF3372@adacore.com> References: <45D0DDDA.301@freescale.com> <20070212214040.GA23093@caradoc.them.org> <45D0E31E.8030802@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45D0E31E.8030802@freescale.com> User-Agent: Mutt/1.4.2.2i 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-02/txt/msg00095.txt.bz2 > Should the gdb host not be sending multiple vCont step packets for next, > just like it does for step? I don't know about the "vCont" packet because I'm unfamiliar with the remote protocol. However, the answer to your question about steps is that the debugger will stop stepping as soon as it has reached a different line. The only exception to that is when the stepi makes us land inside a function call, in which case the debugger sets a breakpoint at the return address and does a continue until we reach it. You might find the output of "set debug infrun 1" very useful. -- Joel