This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Proposal for a new DWARF name index section

> As a follow up to this proposal, I have opened an enhancement request in
> the gcc bugzilla at .

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]