Re: re: .debug_pubtypes

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

Ron Brender writes 
|>sgi has always emitted and used (in WorkShop and dbx).
|>	.debug_pubnames.
|>Because pubnames is intended for *definitions* there is
|>normally no case where a name appears there in two different objects
|>(say in building an executable from a group of objects).
|> .debug_pubnames seems useful and productive.
|
|The statement that "pubnames is intended for *definitions*" seems contrary
|to the DWARF spec, which reads (section 6.1.1/p49):
|
|   "The table consists of sets of variable length entries, each set describing
|   the names of global objects whose definitions or declarations [emphasis
|				     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|   added] are represented by debugging information entries owned by a
|   compilation unit."
|
|Am I missing something someplace else?

No you are not missing anything. But the declaration part is
simply useless and I don't think it remotely sensible
to emit pubnames for declarations-which-are-not-definitions.

Maybe someone else can come up with a reason. I hope
sgi never emits pubnames on declaration-only.


|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.

Somehow it's up to the compilation system to deal with
finding the way to implement this.

|>We also emit the following sections that are extensions:
|>Each is in pubnames format.
|> .debug_weaknames  (weak names, per Sys V)
|> .debug_funcnames  (static (file local) function names)
|> .debug_typenames  (C++ global type (class) names)
|> .debug_varnames   (static (file local) variable names)
|
|Hmmm, this raises a separate side issue. The original DWARF2 folks perhaps
|should have "reserved" all section names beginning with the prefix "debug_".
|Or perhaps adopted a vendor extension naming convention such as was done for
|other things. As it stands, if we (the current DWARF group) try to add some
|new section (with any name actually, with or without a "debug_" prefix) we
|run the risk of colliding with someone's DWARF extensions which already use
|that name. In this case the name .debug_typnames was proposed -- maybe
|that was "luck" or maybe Jim knew about the SGI usage -- but we have no
|way to assure non-collisions for all future time.
|
|I doubt there is any good solution to this problem at this point in time.
|The best I can think of is to promise to ourselves and others that we
|will change the name of any "new" DWARF section we adopt to avoid a conflict
|if discovered prior to completion of the DWARF revision/review.
|
|A recommended naming convention (such as using a prefix a la ".debug_sgi_"
|or ".sgi_debug_") might still be worth considering.

I believe that Joel Silverstein said that the then-constituted
SysV ABI committee had granted to dwarf2 all section names
beginning with .debug_

I admit that SGI was taking a chance, simply naming new sections
as we did, but what the heck -- for MIPS we are the ABI so
we could get away with it.

For IA-64 we are NOT generating the above! We are just
generating the standard dwarf2 sections.  I fixed the filter in
the code generator section-output handler to make sure the
extension sections don't sneak out of the back-end :-) (except
for MIPS output of our compilers, which will continue to have
these extensions forever).

Section naming is really mainly outside the purview of the dwarf2
committee, and that's fine with me :-)

Regards,
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/