From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8530 invoked by alias); 24 Aug 2019 03:36:38 -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 8522 invoked by uid 89); 24 Aug 2019 03:36:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:ca3b5f7, H*i:sk:ca3b5f7 X-HELO: mail-lf1-f45.google.com Received: from mail-lf1-f45.google.com (HELO mail-lf1-f45.google.com) (209.85.167.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 24 Aug 2019 03:36:36 +0000 Received: by mail-lf1-f45.google.com with SMTP id h27so2608737lfp.2 for ; Fri, 23 Aug 2019 20:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W2Q49SNQh+qLP7IUKBuHBjr8ZfArH1kS31DzP5WmFpw=; b=BqpSqtNtFpkVMLS5Zzk8v5+igGvWfEJduV+Ll4leX1k2JwaFjSzVes33kprqcFsmKZ ivArhvcXAfZSs53XlFyd1E/jgXp+W4oS7te1jOMf0u0+RcvpSLUMQaMRLTVC5wlGIBQU VaLTpezrZJHOnJPrjAMsPLvxwCN7GX7JZEPQTd8zOqqP48slNrfICf7thF9JcahzRVek MhqMQnLzhmqqoPNELfb42+3jVkeK4B/zI1dSiJoGFHhhCv2mvwOcmVbpXzBB5UUR17kh YSBYzzuQk+25lgnCVUnNQZb7cg6STnPatodF/q0zHDQSx59C1MyY7gEWTKg9OqIdEG4+ y4jQ== MIME-Version: 1.0 References: <20190818041556.GA11323@host1.jankratochvil.net> <20190818090556.GA19968@host1.jankratochvil.net> In-Reply-To: From: William Tambe Date: Sat, 24 Aug 2019 03:36:00 -0000 Message-ID: Subject: Re: gdb command "next" wrongly working as command "step" To: Pedro Alves Cc: Jan Kratochvil , gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-08/txt/msg00034.txt.bz2 On Fri, Aug 23, 2019 at 4:54 PM Pedro Alves wrote: > > On 8/23/19 10:33 PM, William Tambe wrote: > > On Sun, Aug 18, 2019 at 4:06 AM Jan Kratochvil > > wrote: > >> On Sun, 18 Aug 2019 10:31:54 +0200, William Tambe wrote: > >>> Can I have suggestions of locations within the gdb code where I could > >>> put breakpoints to trace where the issue I am having is occurring ? > >> Check what "set debug infrun 1" says and grep the sources for the displayed > >> messages. > >> > > Using "set debug infrun 1", I can see that GDB stops only after > > printing the following message: > > infrun: stepped to a different line. > > When the above event happens, GDB has stepped inside the function, > > which is obviously going to be on a different line; however, I am > > expecting GDB to step over the function. > > Do a backtrace at this point. GDB should see the caller in frame #1. > Sounds like it doesn't. It does. My backtrace appear to be working properly. See below example listing from using "next" at a line where a function is used; it also show the output of "bt" before and after using "next". The decoded instructions is a lot of noise, but I am hoping you could see that I have a working backtracing, but yet "next" is working as though it was "step". (gdb) b _puts_r Breakpoint 1 at 0x1688: file ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c, line 73. (gdb) r Starting program: a.out Breakpoint 1, _puts_r (ptr=0x8b48 , s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 73 size_t c = strlen (s); c7 2e => 0x00001688 <_puts_r+24>: cpy %2, %fp 9f 2c 0x0000168a <_puts_r+26>: inc8 %2, -4 8c 18 0x0000168c <_puts_r+28>: li8 %1, 0xc8 # -56 b8 1e 0x0000168e <_puts_r+30>: add %1, %fp f2 21 0x00001690 <_puts_r+32>: st32 %2, %1 c7 1e 0x00001692 <_puts_r+34>: cpy %1, %fp 9c 1c 0x00001694 <_puts_r+36>: inc8 %1, -52 ea 11 0x00001696 <_puts_r+38>: ld32 %1, %1 e0 d0 0x00001698 <_puts_r+40>: gip %sr a2 d0 be 01 00 00 0x0000169a <_puts_r+42>: inc32 %sr, 446 d8 fd 0x000016a0 <_puts_r+48>: jl %rp, %sr 8c 38 0x000016a2 <_puts_r+50>: li8 %3, 0xc8 # -56 b8 3e 0x000016a4 <_puts_r+52>: add %3, %fp ea 33 0x000016a6 <_puts_r+54>: ld32 %3, %3 f2 13 0x000016a8 <_puts_r+56>: st32 %1, %3 (gdb) bt #0 _puts_r (ptr=0x8b48 , s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 #1 0x0000184a in puts (s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:129 #2 0x0000132e in main (argc=1, argv=0x3fff000) at helloworld.c:5 (gdb) n strlen (str=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/string/strlen.c:54 54 const char *start = str; c7 1e => 0x00001866 : cpy %1, %fp 9f 18 0x00001868 : inc8 %1, -8 c7 2e 0x0000186a : cpy %2, %fp 9f 24 0x0000186c : inc8 %2, -12 ea 32 0x0000186e : ld32 %3, %2 f2 31 0x00001870 : st32 %3, %1 (gdb) bt #0 strlen (str=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/string/strlen.c:54 #1 0x000016a2 in _puts_r (ptr=0x8b48 , s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 #2 0x0000184a in puts (s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:129 #3 0x0000132e in main (argc=1, argv=0x3fff000) at helloworld.c:5 (gdb) > > Or to be more accurate, use "stepi" to step to the first instruction > of the called function, and run "bt" there. I have also tried using "stepi" to step to the first instruction of the called function. "bt" works correctly. > > As Jan said, for "next" to work properly, backtrace/unwinding must work > properly. When "next" behaves like "step", the most frequent reason > is that unwinding is broken. "next" does a "backtrace" to detect whether > you've stepped into called function, and if you did, then it continues > execution to the address where the called function returns. > > Thanks, > Pedro Alves