This is the mail archive of the mailing list for the GCC 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: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

On 05/18/2012 07:34 PM, wrote:
The motivation and new dwarf attributes and tags all stem from the debug
fission project as described at

Right. Not sure why I missed the pubtypes bits on that page before...

The code I removed doesn't deal with omitting individual entries.
Instead, it decides whether to emit the pubtypes section at all

Ah, yes, I see.

What are these attributes for? Is there a proposal to add them?

The entire motivation for this patch, including the proposed new attributes is at:

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?

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.

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.

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?

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.


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