Re: New Proposal: Global Types section

[Michael Eager <eager at eagercon dot com>]

1) What if the object file which has the concrete definitions is not
   included in the executable?  (I've seen many products which are 
   built differently depending on options, day of the week, etc.)

2) What is the name of the type you are looking up in this new table?
   E.g., the name of the type in "struct A * p[10]"?  or "vector<T>".
   Or "struct A * (f)(struct A *)".  In other places in Dwarf, the type 
   names are purely descriptive; it appears that your lookup would require 
   that they be parsed in some fashion.

3) Can't the same result be obtained using FORM_ref_addr to the actual type
   def?  You would need to have a relocated address. 

I've never been very happy with opaque types.  They always seem to be well 
understood until one discovers that they were well understood in different
ways by different tools.

James Cownie wrote:
> 
> The Problem
> -----------
> 
> Although not true in C, in C++ all types with the same name in a
> program must (by definition of the standard) represent the same type.
> 
> Some compilers (notably CompaQ C++ on Linux/Alpha) exploit this to
> achieve compression of the DWARF by only emitting the full definition
> of a type into the DWARF once. In all other places they emit an opaque
> type, whose only useful content is a name and a byte size.
> 
> There is currently no simple way within DWARF of finding the concrete
> definitions of types, so one is forced to scan all of the top level
> entities in every compilation unit and parse the type definitions (at
> least to the level of knowing their names).
> 
> This is exactly the same problem as is addressed for global data and
> function symbols by the ".debug_pubnames" section.
> 
> The Solution
> ------------
> 
> By analogy with the ".debug_pubnames" section, I propose an optional
> ".debug_pubtypes" section. This is identical to the ".debug_pubnames"
> section in format, but the names are the names of global types defined
> in the relevant .debug_info section.
> 
> This section would only be be generated by DWARF producers which were
> exploiting the optimisation described above to reduce DWARF size.
> 
> Edits
> -----
> (Working from the PDF document of 01/11/2000 4:38:43 pm)
> 
> Section 6.1 on page 37.
> 
> Add a third italicised paragraph.
> 
>   Similarly in languages in which the name of a type is guaranteed
>   always to refer to the same concrete type (such as C++), a compiler
>   may choose to elide type definitions in all compilation units except
>   one. In this case the debugger needs a rapid way of locating the
>   concrete type definition by name. As with the definition of global
>   data objects this would require a search of all the top level type
>   definitions in all of the compilation units in a program.
> 
> In the fourth paragraph change
>   "To make lookup of program objects by name" => "To make lookup of
>   program objects or types by name"
> 
>   Change "two different types" to "three different types"
> 
> In 6.1.1
>   Change the first sentence of first para
>   "For lookup by name," => "For lookup of global symbols by name"
> 
>   Before 6.1.2 add a new para
> 
>   For lookup of global types by name a table is maintained in a
>   spearate object file section called ".debug_pubtypes". This table is
>   identical in format to the ".debug_pubnames" section described
>   above, however it describes global top level type definitions,
>   rather than program objects.
> 
> That's all folks ;-)
> 
> -- Jim
> 
> James Cownie    <jcownie@etnus.com>
> Etnus, Inc.     +44 117 9071438
> http://www.etnus.com


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