Re: re: .debug_pubtypes

[davea at quasar dot engr dot sgi dot com (David B Anderson)]

|
|>|Which is not to say that the spec is not a little confused. In the second
|>|paragraph of that same section, it goes on to explain the use of qualified
|>|names in the cases of static data members of a C++ structure/class/union
|>|(which makes sense) as well as member functions. Seems to me this contradicts
|>|the earlier description that says the table describes (only) "objects".
|>|
|>|Again, am I missing something or is there a new DWARF proposal lurking here...>
|>Recall that 'static data members' are in in fact
|>fully objects (exactly one per executable).
|>And as we all know, visible globally (when properly qualified
|>with namespace::class).
|>
|>Since I know you know this, I'm wondering if I'm missing
|>the real question.
|
|As I said, the rule makes sense for objects -- and, yes, I know that static
|data members are effectively global objects. No problem/question there.
|
|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.

IMO, pubnames was always intended to record all global function
definitions.  Member functions being just one example.
Not just C/C++ 'object' definitions.

Objects is not being used, here , in the precise
way it is used in C or C++, but in a more general way.   IMO. 


davea@sgi.com