From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17648 invoked by alias); 20 Nov 2009 17:25:34 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 17632 invoked by uid 22791); 20 Nov 2009 17:25:33 -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: Cary Coutant Cc: Dodji Seketeli , "GDB\/Archer list" Subject: Re: [RFC] Proposal for a new DWARF name index section References: <4A7FE28D.4050901@redhat.com> <4A8D8868.3010302@redhat.com> Reply-To: Tom Tromey Date: Fri, 20 Nov 2009 17:25:00 -0000 In-Reply-To: (Cary Coutant's message of "Tue, 17 Nov 2009 15:45:59 -0800") 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/msg00065.txt.bz2 >>>>> "Cary" == Cary Coutant writes: >> As a follow up to this proposal, I have opened an enhancement request in >> the gcc bugzilla at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130 . Cary> Sorry for jumping in late to this discussion It is no problem at all, thanks for replying. Cary> It seems to me that the .debug_pubnames/pubtypes/aranges sections were Cary> created specifically so that the debugger could have fast access Cary> without having to pre-read all the debug info, so the idea of creating Cary> a new section rather than fix the one we already have is questionable. Yes, I agree it would be ideal not to do this. Cary> I don't see why the first three can't be fixed simply by changing gcc Cary> to emit those names into .debug_pubnames. Forget the "pub" part of the Cary> section name -- the point of that index is so that the debugger can Cary> find every compilation unit that provides info on a name that can be Cary> typed unqualified into the debugger's UI. I don't think there's Cary> anything in the DWARF spec that *prohibits* the compiler from doing Cary> this True, though I think it is clearly implied. Cary> As for the fourth item, the index already points directly to the DIE Cary> that defines the name. It should be almost trivial to go lookup the Cary> tag of that DIE without actually triggering a full symbol table read, Cary> which should tell you exactly what you need to know. The pubnames Cary> index is already huge; the use cases you've mentioned don't seem to Cary> justify the extra redundancy. I think this is probably the most important problem; the rest I think are fixable by following your advice :-) GDB does actually use this tag info during lookups, before deciding whether or not to fully read a CU. (And think it is reasonable to assume that other debuginfo consumers would want to do so as well.) I agree we could read the DIE and look at the tag. However, that means disk access to read the DIE, and disk access to read in the abbrev table. That seems very expensive for what is supposed to be a quick index lookup. Cary> Now how will gdb know whether or not the pubnames index actually has Cary> all of this extra info? A suggestion to have gdb look at the producer Cary> string was shot down as ugly, but compare that to the alternative of Cary> using a non-standard index. The reason I think a non-standard index is better in this case is that its mere presence implies the DWARF producer is attempting to emit what we want to see. I think parsing the producer info is a problem for two reasons. First, it is a pain to keep a list of the known-good GCC versions. We can't just say "4.5 or better is good", because distro compilers back-port patches to older versions, etc. Second, reading the producer info means reading a DIE, which we'd rather avoid. I'm not sure about tying it to DWARF-4, I'll have to think about that. That requires less reading (no abbrevs), so it might not be as bad; but it does still mean reading some data per CU from disk -- and the extension index does not need that. Cary> Another alternative is just to have gdb use the pubnames index if Cary> it's present, and any name that isn't in the index simply won't be Cary> found without qualification. I think this won't work because GCC historically has emitted bad pubnames info. I've found that we do sometimes need to read a DIE to extract the line table, because GDB has a few searches that map over file names. I'm not sure what to do about this yet. I think I should probably implement your proposal and try to measure the difference. Tom