From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65761 invoked by alias); 1 Sep 2019 19:06:14 -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 65746 invoked by uid 89); 1 Sep 2019 19:06:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=callback, wild, tambe, H*r:sk:gdb@sou X-HELO: mail-lj1-f193.google.com Received: from mail-lj1-f193.google.com (HELO mail-lj1-f193.google.com) (209.85.208.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 01 Sep 2019 19:06:12 +0000 Received: by mail-lj1-f193.google.com with SMTP id z17so10936875ljz.0 for ; Sun, 01 Sep 2019 12:06:12 -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=aL622ORcZzo+yPeps6aEXmicQZBgG8bLU0Xzq8oX134=; b=Yr9xeexbTRuKZ+5youJVksOoJutQD7MZpHEsVQC5yQ7wZFG3PO7PK3/B9TPqomkzik 46LZX3dY6MwgVh9KgXX1LxfR7wNlLzE6tgtgAhf3PnaKL1HDJ1GgqoEz4fDFMXIxlHwp yFbzWpq7nKn9hJ5WRLimo/r2yxEq5+XxSBOKriiYHT8ZnmmBtEUzrzXZ/jOX3sIkQur6 /oWZFUZWxumkqMmAEOxUXJNIrhO7CXhkRji+N3ShDYsxJL2lTzKT6AedauhMYWhfQEL7 74gAo3as7HDeMxgq7HGdR6uLuhEs2PC9F/euSHaJJKjk8a1BciQydEwTb+B0QbWQWxI7 oN7A== MIME-Version: 1.0 References: <20190818041556.GA11323@host1.jankratochvil.net> <20190818090556.GA19968@host1.jankratochvil.net> <07bcdea5-1eda-4412-36d3-2a8eac399089@redhat.com> In-Reply-To: <07bcdea5-1eda-4412-36d3-2a8eac399089@redhat.com> From: William Tambe Date: Sun, 01 Sep 2019 19:06: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-09/txt/msg00001.txt.bz2 On Mon, Aug 26, 2019 at 8:18 AM Pedro Alves wrote: > > On 8/25/19 8:04 PM, William Tambe wrote: > > 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 ? > > - You'll just have to debug gdb. Try to figure out why this code, inside > the "infrun: stepped into subroutine" block,seemingly isn't being reached: > > /* Set a breakpoint at callee's return address (the address > at which the caller will resume). */ > insert_step_resume_breakpoint_at_caller (frame); > > - I'd use "nexti" instead of "next" to try stepping over the > instruction that calls the subroutine, just to make it easier > to debug what goes wrong. I have debugged the issue that I am having to be originating from frame_id_eq(); see below patch that I apply to work-around the issue I am having; I am sure it is not the fix. frame_id_eq() is used to check whether two frames are identical, and in comparing the two frames it will compare whether the two frames have the same program-counter value. I caught GDB comparing two identical frames differing only by their program-counter values; where in one frame, the program-counter value would be at the first instruction of the line making the function-call, while in the other frame the program-counter value would be at the return-address from the function-call. I will guess that, when "next" is used, GDB does not always use the frame program-counter value after the jump-and-link instruction within the line making the function-call, but instead use the frame program-counter value of the first instruction of the line making function-call. To get the program-counter value of a frame, I see GDB calling the callback function (struct frame_unwind *)->prev_register(); and in my GDB port, that function returns the program-counter value after the jump-and-link instruction; I will guess that GDB does not always use that callback function to get the program-counter value of a frame; in that case, what would be the other function that GDB uses to get the program-counter value of a frame ? As mentioned above, here-after is patch that I apply to work-around the issue I am having. Any idea what I am missing in my GDB port such that I wouldn't need the patch below ? diff --git a/gdb/frame.c b/gdb/frame.c index d8b5f819f1..c75f8ead38 100644 --- a/gdb/frame.c +++ b/gdb/frame.c @@ -707,10 +707,14 @@ frame_id_eq (struct frame_id l, struct frame_id r) else if (l.stack_status != r.stack_status || l.stack_addr != r.stack_addr) /* If .stack addresses are different, the frames are different. */ eq = 0; +#if 0 + // ### Disabled for now; as .code addresses could be + // ### different while still being for the same frame. else if (l.code_addr_p && r.code_addr_p && l.code_addr != r.code_addr) /* An invalid code addr is a wild card. If .code addresses are different, the frames are different. */ eq = 0; +#endif else if (l.special_addr_p && r.special_addr_p && l.special_addr != r.special_addr) /* An invalid special addr is a wild card (or unused). Otherwise > > Thanks, > Pedro Alves