From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6487 invoked by alias); 11 Jun 2014 10:01:01 -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 6470 invoked by uid 89); 11 Jun 2014 10:01:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 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:00:32 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1WufKW-0001jz-JF from Hafiz_Abid@mentor.com ; Wed, 11 Jun 2014 03:00:28 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jun 2014 03:00:28 -0700 Received: from EU-MBX-02.mgc.mentorg.com ([169.254.3.61]) by SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) with mapi id 14.02.0247.003; Wed, 11 Jun 2014 11:00:27 +0100 From: "Abid, Hafiz" To: Ken Mandelberg , "Paul_Koning@dell.com" CC: "gdb@sourceware.org" Subject: RE: Remote Debugging with NEXT Command Date: Wed, 11 Jun 2014 10:01:00 -0000 Message-ID: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg00035.txt.bz2 > -----Original Message----- > From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On > Behalf Of Ken Mandelberg > Sent: 10 June 2014 22:21 > To: Paul_Koning@dell.com > Cc: gdb@sourceware.org > Subject: Re: Remote Debugging with NEXT Command >=20 > 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 restori= ng > the content, repeatedly. That's a lot more round trips but it requires l= ess > stub magic. > > > > paul > > > > >=20 > 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, >=20 > When gdb is just trying to get to the next statement in the current funct= ion > with NEXT, it sends the stub a bunch of SI's, which is the problem since = its so > slow. >=20 > I can put more logic in the stub, but I can't change what gdb does, and g= db > doesn't give the stub any indication that it is doing NEXT. >=20 Have you looked at the range stepping? It might be what you are looking for. https://sourceware.org/gdb/onlinedocs/gdb/Continuing-and-Stepping.html#rang= e-stepping Regards, Abid