From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17671 invoked by alias); 15 Dec 2009 23:39:10 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 17662 invoked by uid 22791); 15 Dec 2009 23:39:09 -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> <20091214230947.GA31362@caradoc.them.org> Reply-To: Tom Tromey Date: Tue, 15 Dec 2009 23:39:00 -0000 In-Reply-To: <20091214230947.GA31362@caradoc.them.org> (Daniel Jacobowitz's message of "Mon, 14 Dec 2009 18:09:47 -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/msg00107.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> Or you could drag another bit of GDB into this century, and use Daniel> SQLite or some other in-process database. I played with this a bit today. In particular I changed my gdb to dump an SQLite database from the psymtabs. I used this schema: CREATE TABLE IF NOT EXISTS index_version (version INTEGER); CREATE TABLE IF NOT EXISTS objfile (name, mtime INTEGER, size INTEGER, inode INTEGER); CREATE TABLE IF NOT EXISTS cus (offset INTEGER UNIQUE); CREATE TABLE IF NOT EXISTS filenames (cu INTEGER REFERENCES cus (offset), name, is_primary INTEGER); CREATE TABLE IF NOT EXISTS symbols (cu INTEGER REFERENCES cus (offset), name NOT NULL, psym_domain INTEGER, psym_class INTEGER, is_public INTEGER); CREATE INDEX IF NOT EXISTS byname ON symbols (name); CREATE TABLE IF NOT EXISTS addresses (cu INTEGER REFERENCES cus (offset), low INTEGER, high INTEGER); The 'byname' index really slows down populating the database. It took more than a minute to write out the database for gdb. However, without the index, name lookups are extremely slow (as in, I can count to 2 seconds when running a select command in sqlite3). Maybe I'm misusing SQLite somehow, I'll try to look at this a little more. I'm not an SQL wizard, so if I've done something weird, please let me know, as I'm sure there was no good reason for it. The other issue is that the resulting database is very big. For example, the database for gdb is 72M, but the gdb executable itself is 119M. I didn't write the reader side of this yet, but that won't be too bad. I guess one idea would be to write the database in a background thread. Or just not write it at all by default. Daniel> Mappable data structures are tricky; one thing I'd definitely Daniel> insist on is host neutrality. IMO that is not optional. Yeah, that does make it trickier. I'm starting to get a bit discouraged by this project. I think at this point we've got strikes against all the ideas: * .debug_pub*. These require DWARF extensions and GCC bug fixes, don't work nicely with comdat or the other (planned) post-processors. * .debug_gnu_index. Pretty much the same problems except that we're also inventing it ourselves. * Mappable data structure. A pain to make host-independent; and I suspect that would kill performance. * SQLite. Too big and too slow to create. I suppose we could write out the equivalent of .debug_gnu_index, only not as an ELF section, and not as a mappable data structure. We already know that will perform adequately. This won't meet all of my goals but it would definitely help some use cases. Maybe I can add code to do a psymtab-like scan of .debug_info in a background thread. That might make "gdb gdb" feel faster. I think we ought to change GCC to drop the .debug_pub* sections (and maybe .debug_aranges), at least on Linux. AFAIK they aren't used by anything, and indeed are barely usable due to historic bugs -- so they are just wasting time and space. Let me know what you think, Tom