Re: New Proposal: Global Types section

[Jason Merrill <jason at cygnus dot com>]

>>>>> Michael Eager <eager@eagercon.com> writes:

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

The optimization as implemented in gcc (since 2.95) is only used when we
can be sure that there will be at least one object file with the concrete
definition.  If this were to fail due to a bug, it just looks like an
incomplete type.

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

The optimization only applies to classes.

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

That won't work between shared objects.  You could use FORM_ref_addr with a
link-time optimization as I had been discussing before, but that involves a
lot more mechanism.

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

gcc doesn't use opaque types; we just emit debug info as though the class
in question were incomplete in a given translation unit, and use the
support that is (presumably) already in the debugger for finding elsewhere
a complete definition of an incomplete class.

As Ron points out, the usefulness of the proposed section is independent of
this optimization.

>>>>> David B Anderson <davea@quasar.engr.sgi.com> writes:

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

I don't see why you couldn't define it in every .o where you emit complete
debugging info for the class.  A consumer looking for the name would just
scan .debug_typenames until it finds a match, and go with the first one it
sees.  Similarly for .debug_pubnames, in the case of weak symbols.

I see the proposed section as being just as useful (or not) as
.debug_pubnames; when the user gives the debugger a name that it doesn't
already know about, what does it do?  The debugger can start by scanning
these sections to find a definition; if that fails, it has to look through
the actual debug info.

gdb doesn't currently use .debug_pubnames.  gcc emits AT_sibling between
top-level DIEs that have children, so scanning the interesting DIEs is
reasonably fast, though using pubnames would probably be faster.

Jason