From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9781 invoked by alias); 10 Dec 2009 21:54:21 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 9770 invoked by uid 22791); 10 Dec 2009 21:54:19 -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: Project Archer Subject: Initial psymtab replacement results Reply-To: tromey@redhat.com Date: Thu, 10 Dec 2009 21:54:00 -0000 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/msg00089.txt.bz2 This week I added a new command to gdb to let me dump the .debug_gnu_index section from psymtabs. This way I was able to instrument the OO.o .debug files without recompiling the world. (If you want to try this out, let me know. It required some obscure and probably bogus BFD hacks to make objcopy not barf when splicing the new section into the .debug files.) The summary is, this approach seems solid. Here are timings for a simple "attach" to a running OO.o writer, with full debuginfo installed. These are representative figures, but there is some noise. GDB Time === =================================== CVS 26.05user 2.53system 1:08.86elapsed F11 5.29user 1.09system 0:22.01elapsed (The F11 gdb includes the delayed-symfile branch.) Branch 10.64user 0.81system 0:22.63elapsed Threaded 11.26user 0.87system 0:19.16elapsed I can shave another 5 seconds off the new branch by assuming that the .debug_gnu_index section has canonicalized C++ names. This is significant, but I think it isn't a deal-breaker. I don't have an explanation for why reading the index in a background thread isn't faster than the above. I didn't look into it yet. The other test is "thread apply all bt full". This requires a lot of symbol reading and is the bane of the delayed-symfile branch. These numbers come from "maint time 1" in gdb. GDB Time === ========= CVS 1.824723 F11 27.235860 Branch 1.695742 I didn't time this with the threaded branch but I would expect numbers similar to the branch. The threading only helps hide reading the index, nothing else. Future work I'm planning on this branch: * Test out using pubnames + pubtypes instead of the new section. I remain skeptical about this but it seems important to be sure. * Fix the remaining bugs. I still haven't implemented the needed Ada hook. * Change gdb to an "expand first" model. Right now it will search symtabs and only then expand psymtabs looking for a match. This yields inconsistent behavior, depending on what was already read. This task would change gdb to expand matching psymtabs (or CUs) first, then do symtab searching. I may do this as a completely separate change (I can't remember offhand why I thought I needed this change for this particular project). * Investigate the threading stuff some more. This is the lowest priority. Your comments are welcome. Tom