From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24318 invoked by alias); 10 Jun 2014 21:21:27 -0000 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 Received: (qmail 24309 invoked by uid 89); 10 Jun 2014 21:21:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: cssun.mathcs.emory.edu Received: from cssun.mathcs.emory.edu (HELO cssun.mathcs.emory.edu) (170.140.150.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 10 Jun 2014 21:21:26 +0000 Received: from [170.140.150.64] (mathsunf [170.140.150.64]) by cssun.mathcs.emory.edu (8.13.8+Sun/8.13.8) with ESMTP id s5ALLMeu015776; Tue, 10 Jun 2014 17:21:22 -0400 (EDT) Message-ID: <539776CD.50104@mathcs.emory.edu> Date: Tue, 10 Jun 2014 21:21:00 -0000 From: Ken Mandelberg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul_Koning@dell.com CC: gdb@sourceware.org Subject: Re: Remote Debugging with NEXT Command References: <53977260.9080700@mathcs.emory.edu> <2133A63B-319A-4185-BC0F-C9C9CEDBD575@dell.com> In-Reply-To: <2133A63B-319A-4185-BC0F-C9C9CEDBD575@dell.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00034.txt.bz2 On 06/10/2014 05:12 PM, Paul_Koning@dell.com wrote: > > On Jun 10, 2014, at 5:02 PM, Ken Mandelberg wrote: > >> I'm doing remote gdb deugging to a stub implemented on the target over tcp. SI works and NEXT works well enough skipping over a function call. >> >> What can be very slow is NEXT from one C statement to the next. >> >> When NEXT skips over a function call it implements it by setting a breakpoint at the return address. >> >> When NEXT skips from one C statement to the next, it does it by doing repeated SI's. This forces the target to send back a bunch of state at >> each SI. This is slow and very slow if the C statement actually has a loop in it. >> >> Is there any way around this other than carefully avoiding NEXT in the worst cases and manually setting breakpoints/CONT? > > If your stub supports breakpoints, it will take less work for GDB to do the stepping. Basic stepping involves placing break instructions and restoring the content, repeatedly. ThatÂ’s a lot more round trips but it requires less stub magic. > > paul > > Yes, the stub supports breakpoints. Thats why NEXT through a function call works so well. gdb is smart enough to ask the stub to set a breakpoint at the return address, When gdb is just trying to get to the next statement in the current function with NEXT, it sends the stub a bunch of SI's, which is the problem since its so slow. I can put more logic in the stub, but I can't change what gdb does, and gdb doesn't give the stub any indication that it is doing NEXT.