From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78756 invoked by alias); 5 Sep 2019 11:59:35 -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 78748 invoked by uid 89); 5 Sep 2019 11:59:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.1 required=5.0 tests=AWL,BAYES_00,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=card, showing, Youll, You'll X-HELO: mail-wr1-f68.google.com Received: from mail-wr1-f68.google.com (HELO mail-wr1-f68.google.com) (209.85.221.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Sep 2019 11:59:33 +0000 Received: by mail-wr1-f68.google.com with SMTP id g7so2473090wrx.2 for ; Thu, 05 Sep 2019 04:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=nWeRJvjFGDazC9Ndaz0ixBn3iuGEOa03kaTwmfeyyMY=; b=coAlc4OLm2nUmh5l74j5v7vcQ3MYQo8C13kDTXwiCttuzTEun3gvxwF5Hm7sRdjSdC 5hMDH94EbontIwmgIzvoR5r6NBFPo2cPOpVMy2iDRj6OcNs+0u82FPlfVPhpvFjazIME nrO6SiviPSCYmz7qNonnxL6GLV8VDgUu1IkKCQBRCriz8WOs/mM6oTw11a1P42lUpQJb WeAzrhqQSu5GnwDwlL0xyDI/Zyr4WRC02lqd8Vhd3UhBWIdPY7/0Kz+B9XD+ksCuZqhB mooQM2qYbwGXVlW9edeCa3C7ZTczv8zRv3U1cLqLYnhoD5qhTRKbAZ/NlOU7+MaY0gGn 1nZQ== Return-Path: Received: from localhost (host86-161-16-231.range86-161.btcentralplus.com. [86.161.16.231]) by smtp.gmail.com with ESMTPSA id l2sm2645244wme.36.2019.09.05.04.59.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 05 Sep 2019 04:59:29 -0700 (PDT) Date: Thu, 05 Sep 2019 11:59:00 -0000 From: Andrew Burgess To: William Tambe Cc: Pedro Alves , Jan Kratochvil , gdb@sourceware.org Subject: Re: gdb command "next" wrongly working as command "step" Message-ID: <20190905115928.GM6076@embecosm.com> References: <20190818041556.GA11323@host1.jankratochvil.net> <20190818090556.GA19968@host1.jankratochvil.net> <07bcdea5-1eda-4412-36d3-2a8eac399089@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fortune: Your good nature will bring you unbounded happiness. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00008.txt.bz2 * William Tambe [2019-09-01 14:05:56 -0500]: > 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. >From this description, my guess is that your bug is in your implementation of the frame_this_id method. The frame_id of a function is (basically) made of a $sp and $pc value. The $sp should be the $sp on entry to the frame (or the frame base address, which is similar), and the $pc should be for the start of the function. It sounds to me (just a guess based on the above) that your frame_this_id method is just using the current $pc in the frame to build the frame id. This would explain the issues you are seeing. Thanks, Andrew > > 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