From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3480 invoked by alias); 25 Aug 2019 19:04:30 -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 2941 invoked by uid 89); 25 Aug 2019 19:04:30 -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*Ad:U*gdb, puts, HTo:U*palves X-HELO: mail-lf1-f65.google.com Received: from mail-lf1-f65.google.com (HELO mail-lf1-f65.google.com) (209.85.167.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 25 Aug 2019 19:04:28 +0000 Received: by mail-lf1-f65.google.com with SMTP id n19so10612968lfe.13 for ; Sun, 25 Aug 2019 12:04:28 -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=1d7TKa7AwlRu6q8JEa7vXgDtaBYDbdESSvePaovRkWo=; b=JBx4m5PKIBVHuzk0gD+5ejmu+MPAeeJFLiuznQZd57g5p/rTXwHzTOF4+3Q40w0sUh alklH0OV9a+iwtQvKyCZ96xMm6oiOe16AyRye+iHjJg9HDjlQlQiTQR7xZxhBAsWcUUy DfVHIjSXR5QtLvl6lK1eazlag4Xd8CQptO0kLDmorgQRUVJsX+5+I5VFlZ3TsuI06HxL l2JXbQFDtlifCHD79K3P/VZvRbBmQXk603m6/dp9OITll42Xd4BFSrI2EhzsvcMOT4HF TAi7RdNZKmUI2kJoX/6aB1EtBgTZV7BUFzaSC0pFgopmY+9iI4TdxjApiscaBP7tDLEw Vkyw== MIME-Version: 1.0 References: <20190818041556.GA11323@host1.jankratochvil.net> <20190818090556.GA19968@host1.jankratochvil.net> In-Reply-To: From: William Tambe Date: Sun, 25 Aug 2019 19:04: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/msg00036.txt.bz2 Please see below, less noisy GDB output showing a working backtrace where I can see the caller in frame #1; but yet GDB command "next" is working as though it was "step"; any suggestion where else I could look ? (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); (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; (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 On Fri, Aug 23, 2019 at 10:36 PM William Tambe wrote: > > 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