From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6868 invoked by alias); 11 Aug 2009 22:29:27 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 6858 invoked by uid 22791); 11 Aug 2009 22:29:26 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org To: Jan Kratochvil Cc: Dodji Seketeli , GDB/Archer list Subject: Re: [RFC] Proposal for a new DWARF name index section References: <4A7FE28D.4050901@redhat.com> <20090810143804.GA8671@host0.dyn.jankratochvil.net> <20090810182136.GA25301@host0.dyn.jankratochvil.net> From: Tom Tromey Reply-To: Tom Tromey Date: Tue, 11 Aug 2009 22:29:00 -0000 In-Reply-To: <20090810182136.GA25301@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Mon\, 10 Aug 2009 20\:21\:36 +0200") 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 X-SW-Source: 2009-q3/txt/msg00119.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> * I do not find the symbols reading much slow myself (working _on_ Jan> small GDB). Jan> * People complaining it is slow usually use IDEs which use rather file:line Jan> based breakpoints, don't they? (As it was discussed on RH IRC today.) Jan> = Assuming the C++ people do not put breakpoints on static out-of-scope Jan> functions by name. Thanks for bringing this up. I think there are a few different use cases to consider. My reason for adding "break function" to list is just that it is such a common CLI operation. This current proposal is a way to fix the index problem, which is one necessary step. It is not the only necessary step, though -- we must also change gdb to take advantage of the index. This probably means some kind of surgery on partial symbol tables (ideally I'd like to get rid of them, but we'll see). Jan> We have concluded the currently missing information is for: Jan> * static functions (are they really needed for the file:line IDE usecases?) Jan> * inlined functions which have no concrete out-of-line instance Jan> (the same file:line IDE usecase question) Jan> IMO not for: Jan> * static non-function symbols are deprecated (backward GDB Jan> compatibility only) Ok. This is where I disagree, for reasons I won't repeat :) Jan> * Fallback to the full read-in only for: Jan> * static functions in out of the language (compiler) scope Jan> * inlined functions which have no concrete out-of-line instance Jan> * reference to a non-existing symbol This is another thing I don't like. It means that a typo in a "break" command will cause gdb to pause while it scans a lot of debuginfo. This also means that any attempt to set a pending breakpoint will require a full scan. Jan> As a summary GDB could already give (with proper non-existing Jan> patches) in the common usecases acceptable performance even based Jan> just on the existing DWARF indexes, couldn't it? I did not think Jan> so before this mail thread. It could do better than it does today, but still not as good as we could do with a few extensions. The extensions are cheap on the gcc side (already done IIUC) and because there is no gdb patch yet, equally cheap there. Tom