From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28667 invoked by alias); 17 Nov 2009 23:46:59 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 28655 invoked by uid 22791); 17 Nov 2009 23:46:58 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <4A8D8868.3010302@redhat.com> References: <4A7FE28D.4050901@redhat.com> <4A8D8868.3010302@redhat.com> Date: Tue, 17 Nov 2009 23:46:00 -0000 Message-ID: Subject: Re: [RFC] Proposal for a new DWARF name index section From: Cary Coutant To: Dodji Seketeli Cc: "GDB/Archer list" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-SW-Source: 2009-q4/txt/msg00064.txt.bz2 > 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 . Sorry for jumping in late to this discussion, and please forgive me if I missed something important, but I was just talking about pubnames/pubtypes the other day with some other members of the DWARF committee, and your wiki page came up. It seems to me that the .debug_pubnames/pubtypes/aranges sections were created specifically so that the debugger could have fast access without having to pre-read all the debug info, so the idea of creating a new section rather than fix the one we already have is questionable. The deficiencies you've listed in this thread (and on the wiki) are: - No enumerators. - No entries for inline instances with no out-of-line instance. - No private names. - No information about whether a name is a function or variable, typedef or struct or union or enum. I don't see why the first three can't be fixed simply by changing gcc to emit those names into .debug_pubnames. Forget the "pub" part of the section name -- the point of that index is so that the debugger can find every compilation unit that provides info on a name that can be typed unqualified into the debugger's UI. I don't think there's anything in the DWARF spec that *prohibits* the compiler from doing this; if you're looking for language that requires the compiler to do that, I think you'll get the standard "DWARF is descriptive, not prescriptive" answer (the spec says what the DWARF means, not what a producer or consumer *must* do). The list of things for which the compiler uses this section should be a QOI issue between gcc and gdb or whatever other compiler/debugger pair you're interested in. (My first reaction was that a .debug_privnames section was perhaps a reasonable thing to add to DWARF-5, but then I started wondering what the difference really was between pubnames and privnames. As far as the debugger experience goes, I couldn't think of anything, so I'd prefer to think of "pubnames" as a list of names that a debugger user would want to type without qualification, regardless of the compiler's definition of the word "public". If a wording change in the DWARF spec would help there, I wouldn't have a problem with that.) As for the fourth item, the index already points directly to the DIE that defines the name. It should be almost trivial to go lookup the tag of that DIE without actually triggering a full symbol table read, which should tell you exactly what you need to know. The pubnames index is already huge; the use cases you've mentioned don't seem to justify the extra redundancy. Now how will gdb know whether or not the pubnames index actually has all of this extra info? A suggestion to have gdb look at the producer string was shot down as ugly, but compare that to the alternative of using a non-standard index. You could instead tie it to the switch to DWARF-4 and just check the section version number in the compilation unit header (the version number for .debug_pubnames isn't scheduled to change with DWARF-4, unfortunately). Another alternative is just to have gdb use the pubnames index if it's present, and any name that isn't in the index simply won't be found without qualification. -cary