Re: .debug_pubtypes

[Michael Eager <eager at eagercon dot com>]

I think that Dave makes a good point.  

The general philosophy for Dwarf has been to provide the information
which is necessary to debug a program.  This is the first hurdle:
is this information necessary to achieve this goal.

If the information is already available, then enhancements or changes to 
Dwarf which make it easier to do this have to meet a higher standard.  This
second hurdle: does the benefit outweigh the costs/consequences.

There are costs and consequences which need to be taken into account.
If the extension is optional, the debugger must still correctly process
files which do not have this extension.  (Otherwise you really have two
standards, one with the extension and one without.  Or you de facto make
the optional extension no longer optional.)  What is the additional cost of 
compilers/assemblers/linkers to modify them to use the extension?   Can or 
will compilers be able to generate both the base information and the extension 
compatibly?  (I recall a compiler which could both directly generate object as 
well as assembly.  Unfortunately, they were different.)  What are the 
consequences to having two different ways of describing a program?

This isn't to say that optional extensions should not be adopted, just
that the supporting justification needs to be compelling.

David B Anderson wrote:
> 
> 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


-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077