From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17709 invoked by alias); 31 Mar 2011 02:59:31 -0000 Received: (qmail 17699 invoked by uid 22791); 31 Mar 2011 02:59:30 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 31 Mar 2011 02:59:20 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2V2xJgu031962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Mar 2011 22:59:19 -0400 Received: from anchor.twiddle.home (ovpn-113-143.phx2.redhat.com [10.3.113.143]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p2V2xIoX010417; Wed, 30 Mar 2011 22:59:18 -0400 Message-ID: <4D93EE06.6000501@redhat.com> Date: Thu, 31 Mar 2011 06:22:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dodji Seketeli CC: Jan Kratochvil , GCC Patches Subject: Re: [PATCH] PR debug/47471 (set prologue_end in .debug_line) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg02141.txt.bz2 On 03/30/2011 11:19 AM, Dodji Seketeli wrote: > First, it avoids emitting two consecutive .loc that are identical. > Strictly speaking that should fix this issue in this particular case. What's the compatibility strategy? I.e. how does gdb tell that we're not using the double-loc mechanism? Does it scan the line ops and if you see any prologue_end marks assume that double-loc is not in effect? Are you actually going to be able to delete any code within gdb, due to the need to interpret older debug info? > I have noticed that the end_prologue debug hook was being called, but > the dwarf back-end hasn't implemented it (on non-vms platforms). Is > there a particular reason for not implementing this? Also, I have > noticed that the patch causes the prologue_end directive to be emitted > even when we compile with optimizations. I am not sure how right that > would be. Well, the main problem with the existing end_prologue hook is the definition of the "end of the prologue". The hook you see is called *after* the last insn that was emitted by gen_prologue. I believe that the hook you want would be called *before* the first insn that was originally emitted after NOTE_INSN_FUNCTION_BEG. (Note that under certain conditions, the parameters need to be spilled to their canonical locations, and other similar "prologue-like" stuff happens after gen_prologue, and before the "real" function begins.) Stop me now if I'm mistaken in this understanding of what gdb needs. Without instruction scheduling, and without the need for parameter spills, etc, these two definitions are (nearly) the same. I.e. the existing hook would likely work for -O0 -g, for many parameter lists. On the other end, the definition the compiler uses for "begin the epilogue" is also *before* the first insn that was emitted by gen_epilogue. And again I believe that what you want is *after* the last insn that had been part of the main function body. One possibility for noticing the debugger-definition of end of prologue is simply to mark the first line number of the function. None of the gen_prologue or parameter spill instructions will have location information attached (I believe). Thus the first insn that does generate a line number ought to be the first "active" insn of the function. Presumably one could do something similar at the ends of the function; though that scan may be a tad more complicated. Another problem is that we're not supporting these other features without assembler support. Which is silly. I'm going to go ahead and re-vamp how we're recording line number tables for direct output. That should allow us to generate more-or-less equivalently capable .debug_line output by hand. r~