From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28569 invoked by alias); 14 Jun 2018 13:22:51 -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 28543 invoked by uid 89); 14 Jun 2018 13:22:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Jun 2018 13:22:49 +0000 Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 9D12BACBF; Thu, 14 Jun 2018 13:22:46 +0000 (UTC) Subject: Re: Change inline frame breakpoint skipping logic (Re: [PATCH] Ensure captured_main has unique address) To: Pedro Alves , gdb-patches@sourceware.org Cc: Keith Seitz References: <20180612150620.wloegrt5dgpdugi2@localhost.localdomain> From: Tom de Vries Message-ID: <58a758b7-e4b4-4fee-c7cb-be5a2ab344e6@suse.de> Date: Thu, 14 Jun 2018 13:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00358.txt.bz2 On 06/12/2018 07:38 PM, Pedro Alves wrote: > On 06/12/2018 04:06 PM, Tom de Vries wrote: >> Hi, >> >> atm selftest.exp fails for me. >> >> One of the reasons is that after setting a breakpoint in captured_main, we >> stop at: >> ... >> Breakpoint 1, captured_main_1 (context=) at src/gdb/main.c:492 >> ... >> while selftest_setup expects to stop at captured_main. >> >> The problem is that captured_main_1 has been inlined into captured_main, and >> captured_main has been inlined into gdb_main: >> ... >> $ nm ./build/gdb/gdb | egrep ' [tT] .*captured_main|gdb_main' | c++filt >> 000000000061b950 T gdb_main(captured_main_args*) >> ... >> >> The reason that we seem to be stopping at inline function captured_main_1 has >> probably something to do with commit "Don't elide all inlined frames", > > Yes, sounds like it. But the selftest.exp explicitly asks to stop > at "captured_main", not "captured_main_1", so I'm thinking that > it's gdb's behavior that might be wrong: > > (top-gdb) b captured_main > Breakpoint 3 at 0x792f99: file src/gdb/main.c, line 492. > (top-gdb) r > Starting program: build/gdb/gdb > > Breakpoint 3, captured_main_1 (context=) at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:492 > 492 lim_at_start = (char *) sbrk (0); > (top-gdb) > > With the patch below, we instead get: > > (top-gdb) b captured_main > Breakpoint 6 at 0x791339: file src/gdb/main.c, line 492. > (top-gdb) r > Starting program: build/gdb/gdb > > Breakpoint 6, captured_main (data=) at src/gdb/main.c:1147 > 1147 captured_main_1 (context); > (top-gdb) > > and: > > (top-gdb) b captured_main_1 > Breakpoint 7 at 0x791339: file src/gdb/main.c, line 492. > (top-gdb) r > Starting program: build/gdb/gdb > Breakpoint 7, captured_main_1 (context=) at src/gdb/main.c:492 > 492 lim_at_start = (char *) sbrk (0); > (top-gdb) > Agreed, that's a better solution. > Note that both captured_main and captured_main_1 resolved to the > same address, 0x791339. Right. I played around a bit with this, and set breakpoints on captured_main and captured_main_1. If I set a breakpoint on captured_main_1, we have captured_main unknown: ... Breakpoint 2, captured_main_1 (context=) at /home/vries/gdb_versions/devel/src/gdb/main.c:492 492 lim_at_start = (char *) sbrk (0); (gdb) p captured_main No symbol "captured_main" in current context. (gdb) p captured_main_1 $1 = {void (captured_main_args *)} 0x61b959 ... But If I set a breakpoint on captured_main instead, we have captured_main_1 unknown: ... Breakpoint 3, captured_main (data=) at /home/vries/gdb_versions/devel/src/gdb/main.c:1147 1147 captured_main_1 (context); (gdb) p captured_main $2 = {void (void *)} 0x61b959 (gdb) p captured_main_1 No symbol "captured_main_1" in current context. ... And if I set a breakpoint on both, captured_main_1 seems to take precedence (independent of the order used to set the breakpoint): ... Breakpoint 1, captured_main_1 (context=) at /home/vries/gdb_versions/devel/src/gdb/main.c:492 492 lim_at_start = (char *) sbrk (0); (gdb) p captured_main_1 $1 = {void (captured_main_args *)} 0x61b959 (gdb) p captured_main No symbol "captured_main" in current context. ... I don't understand the underlying mechanisms well enough to decide whether this is a problem or not, but I thought I just mention it. > The gdb.base/inline-break.exp testcase > currently does not exercise that, but the new test added by the > patch below does. That new test fails without the patch and passes > with the patch. No regressions on x86-64 GNU/Linux. WDYT? > AFAICT, the patch looks ok (just one nit below). > +/* A static inlined function that is called by another static inlined > + function. */ > + > +static inline ATTR int > +func_callee (int x) > +{ > + return x * 23; > +} > + > +/* A static inlined function that calls another static inlined > + function. The body of the function is a simple as possible so that > + both functions are inlined to the same PC address. */ > + > +static int inline ATTR ? > +func_caller (int x) > +{ > + return func_callee (x); > +} > + Thanks, - Tom