From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13579 invoked by alias); 14 Dec 2009 22:40:02 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 13550 invoked by uid 22791); 14 Dec 2009 22:40:01 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org From: Tom Tromey To: Daniel Jacobowitz Cc: archer@sourceware.org Subject: Re: Initial psymtab replacement results References: <20091211235901.GA16889@caradoc.them.org> Reply-To: Tom Tromey Date: Mon, 14 Dec 2009 22:40:00 -0000 In-Reply-To: <20091211235901.GA16889@caradoc.them.org> (Daniel Jacobowitz's message of "Fri, 11 Dec 2009 18:59:01 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2009-q4/txt/msg00100.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> I still strongly support the idea of a debugger-specific cache, Daniel> for the reasons below. There's prior art (according to Paul P.); we Daniel> know this approach is practical. Thanks for replying. If we look at this as a gdb-specific format, then I suspect that is actually a harder sell for Fedora. It means more space and another post-processing pass when making the debuginfo RPMs. I'd hope this is surmountable, but it would be preferable to hide the metadata processing somehow, because then we can involve fewer parties. Having gcc generate it in a .debug section achieves this pretty nicely, especially as gcc already generates these sections (more or less). The other big drawback I see with the caching approach is that it means that the first time will still be slow -- even with a system-wide cache this will be true for the objfiles that a user changes during development. I understand the compiler problem. If we had a program to rewrite the appropriate DWARF sections, would that address the problems you have? It seems to me that it would. FWIW if we were going to do our own cache, I wouldn't put it in a form like .debug_gnu_index or .debug_pub*. I'd just have gdb write out a mappable data structure. One definite positive about the branch is that these changes are a lot simpler now. The psymtab stuff is mostly isolated, and writing a new "back end" is reasonably self-contained. Tom