From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26967 invoked by alias); 16 Jan 2015 16:32:03 -0000 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 Received: (qmail 26950 invoked by uid 89); 16 Jan 2015 16:32:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 16 Jan 2015 16:31:56 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0GGVsY2012343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 16 Jan 2015 11:31:54 -0500 Received: from [10.10.116.16] ([10.10.116.16]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0GGVrCM025454; Fri, 16 Jan 2015 11:31:54 -0500 Message-ID: <54B93CF5.9080107@redhat.com> Date: Fri, 16 Jan 2015 16:38:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Richard Biener CC: Aldy Hernandez , gcc-patches Subject: Re: [debug-early] C++ clones and limbo DIEs References: <54B87E5B.1090502@redhat.com> <54B88149.1040906@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-01/txt/msg01411.txt.bz2 On 01/16/2015 05:55 AM, Richard Biener wrote: > I'd hope that in the very distant future all early DIEs would be "created" > by the frontends (that is, dwarf2out.c wouldn't walk into parents/siblings > so much). Are you thinking that the front end would immediately call a debug hook for every block, local variable and such, or just for higher level entities? > I hoped we wouldn't need the limbo list at all ... that is, parent DIEs > are always present when we create children. I think that should > work in principle if the frontends would create DIEs while parsing. So create the function DIE as soon as we see the declaration? That seems reasonable. Then that would be the point of early debug, not later at EOF. > Note that dwarf2out forces parent DIE creation in some cases > but not in some others - it would be interesting to sort out which > parent DIEs it thinks it cannot create when we create the DIE > for a sibling. Maybe it's just poor ordering of early_global_decl > calls? Agreed. Jason