From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11278 invoked by alias); 10 Feb 2015 10:52:43 -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 11264 invoked by uid 89); 10 Feb 2015 10:52:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f180.google.com Received: from mail-ob0-f180.google.com (HELO mail-ob0-f180.google.com) (209.85.214.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 10 Feb 2015 10:52:42 +0000 Received: by mail-ob0-f180.google.com with SMTP id vb8so31001680obc.11 for ; Tue, 10 Feb 2015 02:52:40 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.232.65 with SMTP id f62mr14382808oih.116.1423565560070; Tue, 10 Feb 2015 02:52:40 -0800 (PST) Received: by 10.76.62.9 with HTTP; Tue, 10 Feb 2015 02:52:39 -0800 (PST) In-Reply-To: <54D4EEDC.1070307@redhat.com> References: <54B87E5B.1090502@redhat.com> <54B88149.1040906@redhat.com> <54B94F4D.4040009@redhat.com> <54B97854.7040007@redhat.com> <54C296B5.4050506@redhat.com> <54C7FA41.8010903@redhat.com> <54C92A59.4070401@redhat.com> <54C92A80.80306@redhat.com> <54C92FA8.9040005@redhat.com> <54CBEB69.3000401@redhat.com> <54CBFFE7.1010003@redhat.com> <54CC1885.5010105@redhat.com> <54CDC625.8070902@redhat.com> <54CEEBD5.7090608@redhat.com> <54CEF9FE.6020107@redhat.com> <54D2B907.1040309@redhat.com> <54D3CE5A.1000609@redhat.com> <54D4159F.4090601@redhat.com> <54D4C95D.8040000@redhat.com> <54D4EEDC.1070307@redhat.com> Date: Tue, 10 Feb 2015 10:52:00 -0000 Message-ID: Subject: Re: [debug-early] C++ clones and limbo DIEs From: Richard Biener To: Aldy Hernandez Cc: Jason Merrill , gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00617.txt.bz2 On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez wrote: > >>> + && DECL_CONTEXT (snode->decl) >>> + && TREE_CODE (DECL_CONTEXT (snode->decl)) != FUNCTION_DECL) >> >> >> I think this should be !decl_function_context (snode->decl), in case >> there's a class or BLOCK between the symbol and its enclosing function. > > > Done, also for the iteration through reachable functions. > >> >>> dwarf2out_type_decl (tree decl, int local) >>> + /* ?? Technically, we shouldn't need this hook at all, as all >>> + symbols (and by consequence their types) will be outputed from >>> + finalize_compilation_unit. >> >> >> Note that we also want to emit debug info about some types that are not >> referenced by symbols, such as when a type is used in a cast. > > > Fair enough. I've removed the comment. > >>> +/* Perform any cleanups needed after the early debug generation pass >>> + has run. */ >>> + >>> +static void >>> +dwarf2out_early_finish (void) >> >> >> Since this is also called from dwarf2out_finish, let's call it something >> more descriptive, say, flush_limbo_dies? > > > I was actually thinking of using dwarf2out_early_finish() to mop things up > as we generate early (or stream out) other auxiliary tables (pubname_table, > pubtype_table, file_table, etc). More details on that later. If so, can I > leave it as is? > > How is this version? No regressions on guality. Target libraries build > fine. Finally having a look at the patch. And indeed - this is how I thought it should work. Of course I wonder why you need to separate handling of functions and variables. What breaks if you emit debug info for functions before the first analyze_functions () call? I also wonder why you restrict it to functions with a GIMPLE body. I'd have expected for a TU like void foo (int, int); int main() { return 0; } to be able to do (gdb) start (gdb) ptype foo and get a prototype for foo? (ok, that may be -g3 stuff) Likewise for struct foo { int i; }; int main () { return 0; } and I realize that this needs frontend support - the middle-end really only gets "reachable" stuff reliably. Thus for -g3 we may end up retaining (or adding) some FE calls to early_global{_decl,_type}? (not that I care about the above cases in practice, but in theory?) Thanks for doing all this work! Richard.