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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Cary" == Cary Coutant <ccoutant@google.com> 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