This is the mail archive of the dwarf2@corp.sgi.com mailing list for the dwarf2 project.


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

proposal .debug_pubnames definition




|>|It is the application of the same naming rule to *member functions* that
|>|I was asking about. I can't think of any sense in which these are objects
|>|of any kind (global or otherwise), or why one might want them (but not
|>|other functions) included in the pubnames section (along with "real" objects).
|>
|>Ah. Now I understand.  
|>
|>It is a bug in the document. IMO.
|>One I do not recall ever noticing.
|
|That explanation seems plausible.
|
|Perhaps you would be willing to prepare/submit a short proposal to fix it?


==============
Existing wording, section 6.1.1 Lookup By Name, page 49:

"The table consistes of sets of variable length entries,
each set describing the names of global objects whose definitions
or declarations are represented by  debugging information entries
owned by a single compilation unit."

===============
Motivation for change:

The above seems simply wrong.
In so far as 'objects' is meant in the C sense of objects, it
means data.  Whereas pubnames was intended for all
global things: objects and functions.
Including C++ member functions. Not including C static functions
as C static functions are not global names.

In addition, the reference to declarations is misleading.
If a declaration is not also a definition, there is no reason
to have it in pubnames. Pubnames is intended to help find, quickly,
the definition(s) of data objects and functions.

I cannot understand why finding declarations would be
valuable to a debugger (at least
in the specific sense of accelerated access being
valuable).  Comments anyone?

==================
Proposed wording to replace the original sentence:

"The table consistes of sets of variable length entries,
each set describing the names of global objects 
and functions whose definitions
are represented by  debugging information entries
owned by a single compilation unit."


In italics, in a paragraph following the end of the paragraph
containing the above, add:

	C++ member functions with a definition in the class
	declaration
	are definitions in every compilation unit
	containing the class declaration, but if there is no 
	concrete instantiation there is no reason to
	have a .debug_pubnames entry for the member function.


At least I cannot think why a pubnames entry would be of value for
such a member function with no concrete version.

davea@sgi.com

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