On 05/21/2012 02:39 PM, Cary Coutant wrote:
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 would expect the linker to start by processing the pubnames/pubtypes
sections, and then if it wants to look through the CUs as well it
already knows which ones it can skip.
The presence or absence of an attribute seems like a fragile way to
determine whether or not particular debug info is sufficiently reliable.
If a consumer wants to make decisions based on changing behavior in
different versions of a producer, it could look at the DW_AT_producer
string.
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.
Hmm. Looking at the code, it seems that the pubtypes entries for these
types will point to the main CU, but with the offset in the type_unit,
so a consumer trying to follow the pointer will find garbage. If you
want to have a pubtypes entry, it needs to point to a type skeleton to
avoid crashing standard-conforming consumers.
The DWARF standard says that pubnames is for names with global scope;
this change would add namespace-scope statics as well.
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.
OK.
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").
OK.
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".
Yes, I agree that we want to put "some_function" in pubnames. I still
don't see how putting the anonymous namespace itself in pubnames helps
at all. As far as pubnames is concerned, the anonymous namespace should
be transparent, and "some_function" should appear unqualified.
Jason
