[Bug symtab/24820] .debug_names has incorrect contents

["tromey at sourceware dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=24820

--- Comment #12 from Tom Tromey <tromey at sourceware dot org> ---
Thanks for your notes.

My impression is that ranges can't reliably be reconstructed
from just the top DIE, but that a full scan must be done.
I'm not really sure about this -- possibly this is only true
for older compiler or something.  But gdb supports some truly 
awful crud so maybe we're stuck.

If it does work, we could certainly implement it though.
That would solve the language problem as well... it's not
great to have to scan abbrevs and whatnot like that, but meh,
that's DWARF for you.

About the hash table:

gdb_index is basically just a hash table.  It explicitly uses
the gdb canonicalized form of symbols.  This makes it possible
to do lookups.  I think completion is done by walking all the names.  

For debug_names (after this bug is fixed), though, the scanner
creates the "cooked" internal form (same that the DWARF scanner
creates).  This lets us share data structures, lookup code, etc.
This code doesn't use a hash table at all, so adding one seemed
like extra work.  And since canonicalization isn't really solved
in the spec or in the written hash table, we'd have to do some
kind of secondary backward map (from canonical form to lookup form)
to use it.

(It's not just gcc that doesn't canonicalize names btw, there's
another bug from some other vendor in this area.)

For the linkage name flag:

I see gdb uses this in two spots.

One spot is when constructing the full name of an entry.  There's
probably some test where a linkage name is in some scope, and this
approach was expedient.  We could just register these without parents.

However, it's also used in gdb's post-scanning finalization step.
This is gross but some languages don't emit DWARF hierarchical forms.
So, for instance, for Ada gdb will synthesize the package names for
a fully-qualified symbol.

Also it isn't reliable to look for _Z for linkage names.  This works
for C++ and to some extent Rust (Rust is / will be switching mangling
schemes), but not for Go, Ada, Fortran.

-- 
You are receiving this mail because:
You are on the CC list for the bug.