From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32403 invoked by alias); 30 Jul 2007 06:40:05 -0000 Received: (qmail 32395 invoked by uid 22791); 30 Jul 2007 06:40:04 -0000 X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.176) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Jul 2007 06:40:02 +0000 Received: by wa-out-1112.google.com with SMTP id l35so1769078waf for ; Sun, 29 Jul 2007 23:40:00 -0700 (PDT) Received: by 10.114.192.1 with SMTP id p1mr5279253waf.1185777600580; Sun, 29 Jul 2007 23:40:00 -0700 (PDT) Received: by 10.115.79.20 with HTTP; Sun, 29 Jul 2007 23:40:00 -0700 (PDT) Message-ID: <4414a3a80707292340v1e8918edp204ea680f61823c2@mail.gmail.com> Date: Mon, 30 Jul 2007 08:14:00 -0000 From: congli To: gdb@sourceware.org Subject: Re: Why does gdb implement 'next' command with a series of "vCont;s"? MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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-07/txt/msg00206.txt.bz2 There is an error in my example. When I issue a 'next' command at line 6, the step_range_end should be the first instruction of line 7, 0x8048372, not 804836f. > I have a simple test program (x86 platform), debug it from > a remote machine. First, let the program stop at line 6, > then issue a 'next' command. I have set the 'debug remote' > option, and the command line output is: > > 6 j = i + 1; > (gdb) n > Sending packet: $m45e2ca,1#8e...Ack > Packet received: 55 > Sending packet: $M45e2ca,1:cc#6e...Ack > Packet received: OK > Sending packet: $m8048364,1#3b...Ack > Packet received: c7 > Sending packet: $M8048364,1:cc#1b...Ack > Packet received: OK > Sending packet: $m464005,1#fd...Ack > Packet received: 55 > Sending packet: $M464005,1:cc#dd...Ack > Packet received: OK > Sending packet: $m496014,1#02...Ack > Packet received: 55 > Sending packet: $M496014,1:cc#e2...Ack > Packet received: OK > Sending packet: $vCont;s#b8...Ack > Packet received: T0505:887a80bf;04:607a80bf;08:6e830408; > Sending packet: $vCont;s#b8...Ack > Packet received: T0505:887a80bf;04:607a80bf;08:6f830408; > Sending packet: $vCont;s#b8...Ack > Packet received: T0505:887a80bf;04:607a80bf;08:72830408; > ... > > this is the objdump of line 6 and line 7 of my program: > > j = i + 1; > 804836b: 8b 45 f4 mov 0xfffffff4(%ebp),%eax > 804836e: 40 inc %eax > 804836f: 89 45 f8 mov %eax,0xfffffff8(%ebp) > k = j + 1; > 8048372: 8b 45 f8 mov 0xfffffff8(%ebp),%eax > 8048375: 40 inc %eax > 8048376: 89 45 fc mov %eax,0xfffffffc(%ebp) > > As you can see, line 6 of my program consists of three assembly > instructions. gdb implements the 'next' command by three "vCont;s", > and stop at the first instruction of line 7, which address is > 0x8048372. > > My question is, when I issue the 'next' command, gdb already > know the 'step_range_end' is 0x804836f, why not implement the > 'next' command by set a breakpoint at 0x804836f and then issue > "vCont;c"? When the program meet the breakpoint at 0x804836f, > we can do a single "vCont;s" to the first instruction of > line 7, 0x8048372. > > This implementation of 'next' command will decrease network > traffic and make the command more efficient, especially when > there is a lot of assembly instructions within one C souce line. > But why does gdb take the "vCont;s" method? > > Thanks. >