From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4908 invoked by alias); 20 Jul 2009 19:56:02 -0000 Received: (qmail 4885 invoked by uid 22791); 20 Jul 2009 19:56:02 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_21,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jul 2009 19:55:55 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n6KJtUVF018708; Mon, 20 Jul 2009 15:55:30 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n6KJtT4g016170; Mon, 20 Jul 2009 15:55:29 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n6KJtPGT030376; Mon, 20 Jul 2009 15:55:28 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 206A33782DD; Mon, 20 Jul 2009 13:43:32 -0600 (MDT) To: Joel Brobecker Cc: Paul Hilfinger , gdb-patches@sourceware.org Subject: Re: RFC: lazy partial symbol table reading References: <20090325223211.GH9472@adacore.com> <20090326011605.GJ9472@adacore.com> From: Tom Tromey Reply-To: Tom Tromey Date: Mon, 20 Jul 2009 21:36:00 -0000 In-Reply-To: <20090326011605.GJ9472@adacore.com> (Joel Brobecker's message of "Wed\, 25 Mar 2009 18\:16\:05 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-07/txt/msg00497.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: I was merging the trunk to this branch today, and wondered whatever happened with this conversation... Joel> I think I need to discuss the principle of this patch internally with Joel> the other AdaCore GDB engineers, in particular with Paul Hilfinger. [...] Joel> Basically, what I'm worried about is creating a big pause once Joel> the debugging session has started. For instance, if the user tries Joel> to print the value of variable that's not found in the local scope Joel> (basically, a global variable), the next thing we do is search all Joel> symbols in all symtabs/psymtabs. Or even more common: Inserting Joel> a breakpoint on a function ("break function_name"). Again, we search Joel> all symtabs/psymtabs. This is necessary, because we need to handle Joel> homonyms. Yes, this is a problem, even for C. My canonical test case is attaching to a running OO.o Writer process, with all debuginfo installed. This patch greatly speeds up the initial attach. If I do "thread apply all bt full", this is also reasonably speedy -- but there is one particular point at which there is a long pause while gdb reads debuginfo. I looked a little bit into reading some debuginfo in the background. My idea was that gdb would spawn a worker thread to process only the largest debuginfo, because that is more likely to be needed and also because it is more likely to cause a noticeable pause when it is read. This turns out to be a bit involved, and since it was really a Plan B idea for me I dropped it. Joel> If we have a way of having all symbol names available without creating Joel> the symtabs (the .debug_pubnames section), then I think we have the cake Joel> and eat it too: We only have to create the psymtab for the CUs that Joel> we need. In fact, one could argue that we actually no longer need Joel> the partial symtab anymore... Yeah. I'd also like to parse just single CUs and also get rid of partial symbol tables when using DWARF. I think this is Plan A to fix this problem. My understanding (I think based on comments I've seen or email messages in the archives) is that this is a direction desired by other gdb maintainers as well. I haven't looked to see how much work it really is, though. pubnames are difficult at the moment because gcc has pubname generation bugs. So, we can't rely on the contents of this section. And even once gcc is fixed... how will we know we can rely on it then? Also gcc only just started generating pubtypes (except on Mac OS, where it has done so for a while). Finally, there's the private names issue I mentioned upthread. One solution is to also emit debug_privnames and debug_privtypes (needed?) for gdb's use. I'm hoping to get somebody here at Red Hat to fix the gcc problems. But, I don't know when. Tom