Re: New Proposal: Global Types section

[James Cownie <jcownie at etnus 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.)

You don't get to see the types, they remain opaque. This is a problem
with this whole optimisation. 

I'm not recommending this optimisation _at all_ I'm just trying to
make my life easier as a DWARF consumer who has to deal with a
compiler which has chosen to use it :-(

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

It's precisely the name which was given when the type was
declared. (Which probably limits the utility of this to structs,
classes, and enums, since IIRC they're the only types which have an
AT_Name). 

I'm certainly not proposing to parse it anywhere, just do a by name
lookup.

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

Maybe, but how does the compiler generate that given that the actual
type def is in some completely different file compiled at some
completely different time ?

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

I agree 100%.

As I said I'm not advocating this optimisation, but trying to live
with the fact that it already exists and is giving me grief !

Note, also, that this section is optional, you should only generate it
if you are using some type optimisation scheme.

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, Inc.     +44 117 9071438
http://www.etnus.com