re: .debug_pubtypes

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

Ron (or his colleague) comments.
>One way to "test" whether .debug_pubtypes might
>be attractive in practice is to ask whether .debug_pubnames is actually
>produced and used by current DWARF generators and consumers.

I'll comment. Make what you will of it :-)

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.


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)

The concept in creating these was exactly what you would guess:
trying to make access to such things faster.

WorkShop, the gui debugger, uses these sections
(or anyway reads them in).

dbx (our non-gui debugger,based on the same
source as WorkShop) ignores these sections.
Because I ripped that out of dbx long ago as 
not-proven-productive :-)

They exist because someone who worked on Workshop
campaigned hard for them very early in the development
of the compiler suite.  Simply *assuming* that the
debugger could take good use of them and it would be a win.

There was never any real evidence their existence speeds up
any debugger, or even allows a real speedup at all.

Perhaps someone will generate such evidence. Volunteers?
Lacking evidence I am reluctant to support new 
 'performance-enhancing' sections.
Folks can certainly do their own extensions, as SGI has.

The debug_typenames idea suffers from the problem of deciding
where to create an entry for a given class: it is not so easy to
decide which .o to create it in 
since you don't want to create it in every .o
using the class (that is a problem
compilers have other reasons to solve, so perhaps it is a non-issue).

Here are some object section sizes for a real
production libc.so.1 compiled without -g:
[No]   Type                  Addr       Offset     Size        Name
       Link       Info       Adralgn    Entsize    Flags

[27]   SHT_MIPS_DWARF        0          0x15f0b7   0x7420d     .debug_info
       0          0          0x1        0          0x00000000 

[28]   SHT_MIPS_DWARF        0          0x1d32c4   0xe624      .debug_pubnames
       0          0          0x1        0          0x00000000 

[29]   SHT_MIPS_DWARF        0          0x1e18e8   0x93ec      .debug_weaknames
       0          0          0x1        0          0x00000000 

[30]   SHT_MIPS_DWARF        0          0x1eacd4   0x7406b     .debug_line
       0          0          0x1        0          0x00000000 

[31]   SHT_MIPS_DWARF        0          0x25ed3f   0x7400      .debug_aranges
       0          0          0x1        0          0x00000000 

[32]   SHT_MIPS_DWARF        0          0x26613f   0x3504      .debug_funcnames
       0          0          0x1        0          0x00000000 

[33]   SHT_MIPS_DWARF        0          0x269643   0x278a8     .debug_frame
       0          0          0x1        0          0x08000000 NOSTRIP 

[34]   SHT_MIPS_DWARF        0          0x290eeb   0xf94e      .debug_abbrev
       0          0          0x1        0          0x00000000 

Since libc.so is written in C, not C++, there is no .debug_typenames

Total size of the libc.so.1 file:  2930532 bytes, 0x2cb764.

davea@sgi.com