From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32097 invoked by alias); 4 Oct 2013 06:49:46 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 32087 invoked by uid 89); 4 Oct 2013 06:49:45 -0000 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; Fri, 04 Oct 2013 06:49:45 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_00,GARBLED_BODY,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VRzCm-00071o-5m from Yao_Qi@mentor.com ; Thu, 03 Oct 2013 23:49:40 -0700 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Oct 2013 23:49:39 -0700 Received: from qiyao.dyndns.org (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; Thu, 3 Oct 2013 23:49:39 -0700 Message-ID: <524E64AB.5040807@codesourcery.com> Date: Fri, 04 Oct 2013 06:49:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: ILG.Robert CC: "gdb-patches@sourceware.org" Subject: Re: Extending RSP with vCont;n and vCont;f References: <7E3A266F5548C442BC08FA3038B5197C68449231@ATFKEX06.bachmann.at> In-Reply-To: <7E3A266F5548C442BC08FA3038B5197C68449231@ATFKEX06.bachmann.at> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00126.txt.bz2 On 10/02/2013 11:08 PM, ILG.Robert wrote: > void > _initialize_remote (void) > { > @@ -12168,6 +12274,34 @@ > &setlist, > &showlist); > > + add_setshow_boolean_cmd ("next-stepping", class_run, > + &use_next_stepping, _("\ > + Enable or disable next stepping."), _("\ > + Show whether target-assisted next stepping is enabled."), _("\ > + If on, and the target supports it, when skipping over a source line, GDB\n\ > + tells the target to skip the next instruction itself instead of\n\ > + of issuing multiple single-steps. This speeds up source level\n\ > + stepping. If off, GDB always issues slower stepping mechanisms\n\ > + instead, even if next stepping is supported by the target. The default is on."), Due to lack of description of these two packets, I have to understand them from the help message of the command. IIUC, it is similar to range-stepping, vCont;r except that start and stop address are not provided to the stub. That means vCont;n requires a smarter stub to know enough line table information to decide where to stop. An alternative to me is to teach your stub understand range stepping. > + set_next_stepping, > + show_next_stepping, > + &setlist, > + &showlist); > + > + add_setshow_boolean_cmd ("finish-stepping", class_run, > + &use_finish_stepping, _("\ > + Enable or disable finish stepping."), _("\ > + Show whether target-assisted finish stepping is enabled."), _("\ > + If on, and the target supports it, when stepping out of a function, GDB\n\ > + tells the target to step out of the corresponding stack frame itself.\n\ > + This speeds up source level stepping. If off, GDB issues slower\n\ > + stepping mechanisms instead, even if finish\n\ > + stepping is supported by the target. The default is on."), GDB inserts a momentary breakpoint, resume the inferior and wait when command "finish" is executed. I don't think GDB emits a large number of RSP packets in this process. Do you have an experiment that vCont;f packet improves performance to some extent? -- Yao (齐尧)