From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9632 invoked by alias); 5 Oct 2012 15:18:31 -0000 Received: (qmail 9614 invoked by uid 22791); 5 Oct 2012 15:18:29 -0000 X-SWARE-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Oct 2012 15:18:22 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id q95FIG43007786; Fri, 5 Oct 2012 17:18:16 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id q95FID1J003796; Fri, 5 Oct 2012 17:18:13 +0200 (CEST) Date: Fri, 05 Oct 2012 15:18:00 -0000 Message-Id: <201210051518.q95FID1J003796@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: jan.kratochvil@redhat.com CC: gdb-patches@sourceware.org In-reply-to: <20121005124107.GA22927@host2.jankratochvil.net> (message from Jan Kratochvil on Fri, 5 Oct 2012 14:41:07 +0200) Subject: Re: [patch] entry values: Fix resolving in inlined frames References: <20121005124107.GA22927@host2.jankratochvil.net> 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 X-SW-Source: 2012-10/txt/msg00099.txt.bz2 > Date: Fri, 5 Oct 2012 14:41:07 +0200 > From: Jan Kratochvil > > Hi, > > Breakpoint 1, fn2 (y=, x=6) at gdb.arch/amd64-entry-value-inline.c:32 > 32 y = -2 + x; /* break-here */ > (gdb) info addr y > (gdb) bt > #0 fn2 (y=, x=6) at gdb.arch/amd64-entry-value-inline.c:32 > #1 fn3 (x=x@entry=6, y=y@entry=25) at gdb.arch/amd64-entry-value-inline.c:42 > #2 0x00000000004004af in main () at gdb.arch/amd64-entry-value-inline.c:48 > (gdb) info frame > Stack level 0, frame at 0x7fffffffdb68: > rip = 0x4005bc in fn2 (gdb.arch/amd64-entry-value-inline.c:32); saved rip 0x4004af > inlined into frame 1 > [...] > (gdb) set debug entry-values 1 > (gdb) p y > DW_OP_GNU_entry_value resolving expects callee fn1 at 0x4005a0 but the called frame is for fn3 at 0x4005b0 > > FAIL: > ----- > $1 = > PASS: > ----- > $1 = 25 > > (gdb) p/x $pc > $2 = 0x4005bc > (gdb) up > #1 fn3 (x=x@entry=6, y=y@entry=25) at gdb.arch/amd64-entry-value-inline.c:42 > (gdb) p/x $pc > $3 = 0x4005bc > > The problem is that DW_TAG_GNU_call_site <-> DW_OP_GNU_entry_value binding > exists between DW_TAG_subprogram, nor DW_TAG_inlined_subroutine as described > by Jakub Jelinek. This makes sense, when we look at DW_TAG_GNU_call_site and > we just unwind the current inlined frame we get the same PC - this is no new > information. > > TAILCALL_FRAME is a different case, while also an artificial frame the > sequence cannot be determined at compile time and the binding > DW_TAG_GNU_call_site <-> DW_OP_GNU_entry_value exists also for > TAILCALL_FRAMEs. Your explanation makes no sense to me, and unfortunately that extends to the comment you added in the code. > + /* Skip any inlined frames, entry value call sites work between real > + functions. They do not make sense between inline functions as even PC > + does not change there. */ I realize that you're not a native speaker, but a big part of the problem is that there are a lot of grammatical mistakes in your english. Can you get some help from a native speaker to make sure the comments in the code make sense?