From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126219 invoked by alias); 28 Dec 2019 23:23:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 126211 invoked by uid 89); 28 Dec 2019 23:23:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.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=feels, Temporary X-HELO: mail-wm1-f66.google.com Received: from mail-wm1-f66.google.com (HELO mail-wm1-f66.google.com) (209.85.128.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 28 Dec 2019 23:23:14 +0000 Received: by mail-wm1-f66.google.com with SMTP id p9so11224166wmc.2 for ; Sat, 28 Dec 2019 15:23:13 -0800 (PST) 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=mBBRicMYV4IMGxWCzHEyqVBthD9DaKK2mUp/YyCPuq8=; b=c7pP9SwVnL4oUaXmhsCBaSKCKCs/rPzLKoTAmr4sLL5zpmeMCxZ80HgAnA/3tlIB2X G+yjKvglLhZapqoP651wTBaXSAdD3kEP9209w/xqInEQRe9xwnT96E6T3HhuzcckI6y+ 8zYeh8oyXzarTQMKlsjoyAJq/JJteRUf4OMFKJRr7r10zW+Q31MarUfpRqfLFTqrRwQZ nTEIta0s+rLfQJDxIAYAbdc9KNBsRjEo8OJHbbh23g2EcaFfOPe0a/WJ6s5idJn789BP GvV4L+C83MrAk4n/J4MuSXbmlS4PXijruQWW0YHKJCMLMaO9RzqrTtm6MoQJeQa2Uw3A qGIw== Return-Path: Received: from localhost (host86-186-80-236.range86-186.btcentralplus.com. [86.186.80.236]) by smtp.gmail.com with ESMTPSA id v14sm39310055wrm.28.2019.12.28.15.23.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 28 Dec 2019 15:23:11 -0800 (PST) Date: Sat, 28 Dec 2019 23:23:00 -0000 From: Andrew Burgess To: Bernd Edlinger Cc: Christian Biesinger , "gdb-patches@sourceware.org" Subject: Re: [PATCH 3/3] gdb: Better frame tracking for inline frames Message-ID: <20191228232310.GO3865@embecosm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fortune: secretary plugged hairdryer into UPS 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-12/txt/msg01058.txt.bz2 * Bernd Edlinger [2019-12-28 10:02:40 +0000]: > On 12/26/19 11:33 PM, Andrew Burgess wrote: > > * Christian Biesinger [2019-12-26 07:24:39 +0100]: > > > >> On Mon, Dec 23, 2019, 02:51 Andrew Burgess > >> wrote: > >> > >> > This commit improves GDB's handling of inline functions when there are > >> > more than one inline function in a stack, so for example if we have a > >> > stack like: > >> > > >> > main -> aaa -> bbb -> ccc -> ddd > >> > > >> > And aaa, bbb, and ccc are all inline within main GDB should (when > >> > given sufficient debug information) be able to step from main through > >> > aaa, bbb, and ccc. Unfortunately, this currently doesn't work, here's > >> > an example session: > >> > > >> > (gdb) start > >> > Temporary breakpoint 1 at 0x4003b0: file test.c, line 38. > >> > Starting program: /project/gdb/tests/inline/test > >> > > >> > Temporary breakpoint 1, main () at test.c:38 > >> > 38 global_var = 0; > >> > (gdb) step > >> > 39 return aaa () + 1; > >> > (gdb) step > >> > aaa () at test.c:39 > >> > 39 return aaa () + 1; > >> > (gdb) step > >> > bbb () at test.c:39 > >> > 39 return aaa () + 1; > >> > (gdb) step > >> > ccc () at test.c:39 > >> > 39 return aaa () + 1; > >> > (gdb) step > >> > ddd () at test.c:32 > >> > 32 return global_var; > >> > (gdb) bt > >> > #0 ddd () at test.c:32 > >> > #1 0x00000000004003c1 in ccc () at test.c:39 > >> > #2 bbb () at test.c:26 > >> > #3 aaa () at test.c:14 > >> > #4 main () at test.c:39 > >> > > >> > >> How come only #1 is printing the address? > > > > Well..... > > > > For inline frames the sal returned by find_frame_sal has a symtab and > > line set, but doesn't have the pc or end fields set. > > > > If we then look at frame_show_address it seems specifically designed > > to return false for precisely the case we're discussing. > > > > I agree with you that it seems odd that we only get the address for #1 > > in this case. I considered this patch: > > > > ## START ## > > > > diff --git a/gdb/stack.c b/gdb/stack.c > > index 22820524871..ce85a1183f0 100644 > > --- a/gdb/stack.c > > +++ b/gdb/stack.c > > @@ -327,7 +327,7 @@ frame_show_address (struct frame_info *frame, > > gdb_assert (inline_skipped_frames (inferior_thread ()) > 0); > > else > > gdb_assert (get_frame_type (get_next_frame (frame)) == INLINE_FRAME); > > - return false; > > + return frame_relative_level (frame) > 0; > > } > > > > return get_frame_pc (frame) != sal.pc; > > > > ## END ## > > > > The addresses are printed more now, there's a few test failures that > > would need to be checked first. > > > > Hmm.... > > In the case of inline functions the call stack would behave odd > with this patch. > > Since the inline frames all share the same PC, the value is redundant, > still different source line location is presented for each. > Also when stepping in the inner frame, all inlined frames would > also change the PC, so you get the impression that the inlined function > is now called from a slightly different place. > > It might be more useful to add an info to the call stack, > that a frame was inlined instead? > > #0 iii () at dw2-inline-many-frames.c:145 > #1 inlined in hhh () at dw2-inline-many-frames.c:115 > #2 inlined in ggg () at dw2-inline-many-frames.c:77 > #3 inlined in fff () at dw2-inline-many-frames.c:92 > #4 0x0000000000401226 in eee () at dw2-inline-many-frames.c:155 > #5 0x0000000000401209 in ddd () at dw2-inline-many-frames.c:135 > #6 inlined in ccc () at dw2-inline-many-frames.c:84 > #7 inlined in bbb () at dw2-inline-many-frames.c:108 > #8 inlined in aaa () at dw2-inline-many-frames.c:60 > #9 inlined in main () at dw2-inline-many-frames.c:125 I really want to like this idea, as I agree showing the address feels less useful, and somehow marking the inline nature of things feels like a good thing, but I'm put off by this: #9 inlined in main () ... The 'inlined in main' is telling us about frame #8, right? And this feels weird too. Not sure I have any better suggestions though. Thanks, Andrew > > > > Bernd. > > > Ideally I would like to keep changing this behaviour separate from > > this patch series, but I do think this might be something we should > > consider changing. > > > > Thanks, > > Andrew > > >