From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13393 invoked by alias); 11 Jun 2014 10:26:23 -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 13383 invoked by uid 89); 11 Jun 2014 10:26:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Jun 2014 10:26:21 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1WufjW-0003ve-6F from Luis_Gustavo@mentor.com ; Wed, 11 Jun 2014 03:26:18 -0700 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jun 2014 03:26:17 -0700 Received: from [172.30.3.151] (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.2.247.3; Wed, 11 Jun 2014 03:26:17 -0700 Message-ID: <53982EC5.7080502@codesourcery.com> Date: Wed, 11 Jun 2014 10:26:00 -0000 From: Luis Machado Reply-To: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ken Mandelberg , CC: Subject: Re: Remote Debugging with NEXT Command References: <53977260.9080700@mathcs.emory.edu> <2133A63B-319A-4185-BC0F-C9C9CEDBD575@dell.com> <539776CD.50104@mathcs.emory.edu> In-Reply-To: <539776CD.50104@mathcs.emory.edu> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00036.txt.bz2 On 06/10/2014 10:21 PM, Ken Mandelberg wrote: > 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. If the code only moved in a specific direction, this logic/optimization of just continuing to a specific next statement's associated address would work just fine. In practice, though, code can jump around and go back, like branches, loops and optimized code. Therefore GDB needs to do individual instruction-steps in order to sense line number changes. When it detects such a change, it will stop and let the user know. The next line could be 200 lines above, or a single line below. It is hard to predict. Skipping functions is easier though, you just continue to its return address and that's it. It is an area that could probably be improved. Range-stepping is a step towards that goal. Luis