>> The entire motivation for this patch, including the proposed new
>> attributes is at:
>>
>> http://gcc.gnu.org/wiki/DebugFission
>>
>> In particular, the section titled, "Building a GDB Index".
>
> OK, I've read that section and I still don't understand why the consumer
> would need a pointer from the CU to the pubnames section to build an index.
> If we're looking for something by name, we go from pubnames to the CU. If
> we're looking at the CU because we're in a function body, presumably we need
> to parse most of it anyway; is there really a significant benefit to having
> a separate "what names does this CU define" attribute? The index is all
> name->die lookup, isn't it?
The DW_AT_GNU_pubnames/pubtypes attributes serve two purposes: (1)
they let the linker know which CUs have pubnames & pubtypes sections,
and (2) they let us know that the pubnames and pubtypes are "reliable"
(relative to the incomplete sections that GCC has generated in the
past). When building the .gdb_index, the linker starts with the top
compile_unit DIE of the CU. If there are pubnames/pubtypes attributes,
it can go read those sections; otherwise, it needs to parse the whole
DIE tree (slow) to extract the information needed for .gdb_index. It
would be possible to use the pointer from the pubnames section to the
CU, but that's a reverse pointer, and it would take time to set up the
links to figure out which pubnames/pubtypes sections go with which
CUs.
> I'm also puzzled by what the proposal says about .debug_types. Why would a
> pubtypes entry point to a CU that doesn't actually have a definition of the
> type? Is it so that the consumer knows which .dwo to look in? Perhaps we
> could do something else with the sig8 instead of pointing to the wrong unit.
Yes, it's to find the .dwo. I never did anything to accomodate
.debug_types sections with .debug_pubtypes -- probably a more
substantial change to the format is in order, but I wanted to save
that for what I expect to be a complete revamping of the accelerated
lookup tables in DWARF.
>>> The DWARF standard says that pubnames is for names with global scope;
>>> this
>>> change would add namespace-scope statics as well.
>>
>> I am matching what gold and gdb do when building the gdb index.
>
> Ah. If that's what GDB wants I guess it makes sense, but I'd like to see
> reaction from the committee to this particular aspect. I haven't noticed it
> come up in the committee discussion of Fission.
We had some discussion in the DWARF workgroup during the DWARF 4
development about what should go into pubnames and pubtypes, but
didn't really settle on any specific wording change for the standard.
I think it was generally agreed that it's ultimately a
quality-of-implementation issue where the producer and consumer need
to agree on what's useful there. For the purposes of a debugger, the
only thing that really make sense is to have a name-to-CU index that
indexes all the names that a user might type at the user interface.
Without the fixes we're putting in here, the pubnames section has been
essentially useless, and has been ignored entirely by gdb -- to the
point that a change went in a year or so ago to disable the section by
default except for Darwin.
I anticipate further discussion of accelerated lookup in the DWARF 5
discussions, and I expect these tables to get a major overhaul. Until
then, I think it's reasonable to make use of them as best we can
without making any major structural changes.
>>> Why do we need pubtype entries for base types?
>>
>> Same as above--to make these addable to the index, which in turn makes
>> gdb faster. I'll add this to the note to Cary.
>
> Really? GDB wants to look up built-in types in the index rather than just
> knowing what "int" means?
It doesn't actually always mean the same thing, though. It might be
less surprising if you ask that about some other base type like
"double" (and consider that GCC has options like -fshort-double).
Also, GDB can narrow the set of CUs that it has to read sometimes by
knowing which CUs actually contain a declaration of a given base type
(again, it's easier to see the advantage for "double" than for "int").
>>> Why bypass the DECL_NAMELESS check?
>>
>> So objects within anonymous namespaces get pubnames:
>>
>> namespace { void some_function...
>
> Hmm, it would give the anonymous namespace itself a pubname, but I don't see
> how it would make any difference to objects within the namespace.
The items within an anonymous namespace need to be indexed so that a
GDB user can just type "some_function" instead of "(anonymous
namespace)::some_function".
-cary
