Re: New Proposal: Global Types section

[Michael Eager <eager at eagercon dot com>]

James Cownie wrote:
> 
> > 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.

How does the existing compiler decide whether to generate an opaque type or
the full type info?  Do you get two entries for "struct A" and "struct A *"?

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

Generate a hashed name?  This would seem to be the same for any use of FORM_ref_addr.

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

I guess that if you didn't support this new section, you could search the 
Dwarf file as you are doing now.  Unfortunately, this itself is an extension
to Dwarf, since there is nothing to suggest that a debugger should do this.

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