From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1484 invoked by alias); 7 Oct 2014 16:24:24 -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 1469 invoked by uid 89); 7 Oct 2014 16:24:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 07 Oct 2014 16:24:22 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s97GOHJQ008004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 7 Oct 2014 12:24:17 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s97GOG3J002512; Tue, 7 Oct 2014 12:24:16 -0400 Message-ID: <543413AF.4080401@redhat.com> Date: Tue, 07 Oct 2014 16:24:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Yao Qi , Peng Yu CC: "gdb@sourceware.org" Subject: Re: How step over a ass call command? References: <87r3ykt12e.fsf@codesourcery.com> In-Reply-To: <87r3ykt12e.fsf@codesourcery.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00015.txt.bz2 On 10/07/2014 03:19 PM, Yao Qi wrote: > Peng Yu writes: > >>>> Suppose that I use gdb with a binary file with source stripped. > > What do you mean by "a binary file with source stripped"? Did you > compile without debug information? My gdb (built from current git repo > for x86-linux target) works correctly for binary without debug info. > > (gdb) disassemble > Dump of assembler code for function main: > 0x08048406 <+0>: push %ebp > 0x08048407 <+1>: mov %esp,%ebp > => 0x08048409 <+3>: call 0x8048400 > 0x0804840e <+8>: mov $0x0,%eax > 0x08048413 <+13>: pop %ebp > 0x08048414 <+14>: ret > End of assembler dump. > (gdb) ni > 0x0804840e in main () > >>> Try nexti, which is defined as >>> Execute one machine instruction, but if it is a function call, proceed >>> until the function returns >> >> I am sorry. I meant to say "nexti" in my original email. "nexti" seems >> to the same as "stepi" when the source code is stripped. Is it >> supposed to be so? > > No, it looks a bug to me. What is your gdb version? or you can report > this bug here https://sourceware.org/bugzilla/ 0x1ea7 : mov %eax,(%esp) 0x1eaa : call 0x1f14 0x1eaf : mov 0x1180(%ebx),%ecx Doesn't look like GDB which function is at 0x1f14. "nexti" relies on being able to backtrace out of that "function", and check that the previous caller is still found at frame #1, to detect that a function call was done. So run to that "call" line, and then do "bt". And then do "stepi" to step that instruction instead of "nexti", and then do "bt" again. If the second backtrace doesn't have one extra frame, or if the frame that was frame #0 in the first backtrace is frame #1 in the second backtrace, then "nexti" won't work either. Thanks, Pedro Alves