Re: New Proposal: Global Types section

[James Cownie <jcownie at etnus dot com>]

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

Only the C++ compiler does this, and AFAICT it does it only for
classes.

What I believe that it does is to use an algorithm like the one used
for deciding where to generate a vtable to decide where to generate
complete, concrete class type information.

In all other compilation units it generates an opaque class
declaration which has the name but not much else at the time when it
needs to generate the class type itself.

As ever in DWARF, types which represent modified versions of the
original type will be encoded as a separate DIE which refers to the
original, named (but opaque) type, e.g.

0000829c  00000012 [12] (class)
0000829d           name:  "cplus_demangler_t"
000082af           byte size:  [68] 0000000000000068 (104)
000082b0  00000000 [00] (NULL)
...
0000e7d7  00000008 [08] (pointer)
0000e7d8           type:  ref: 0000829c (0000829c)
...

So, here we have a "cplus_demangler_t *" declaration, but no
tangible information about the contents of a cplus_demangler_t.

Fundamentally the DWARF to represent qualifiers to the type is
relatively small, so having that in each compilation unit is not a big
cost, whereas the DWARF for a full class (and all its base classes)
can be large, so only having that once may be a large saving.

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

I guess that the compiler folks find this unattractive in that it
would make it relatively easy (by using different compiler debug
flags, for instance) to generate a binary image which wouldn't link
simply because the relevant type info fixup was missing in the DWARF.


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

I don't see any behaviour of a debugger as being an extension to
DWARF. DWARF is a file format specification. How you generate it or
use it is not specified by the DWARF specification. The DWARF spec
states what bits go in a file and what semantics should be associated
with that pile of bits. 

Of course, we need to be concerned that the specification is easy to
use, but that doesn't mean that we can specify at all how people
choose to use it !

Of course, there is one other reason for having this section even in
absence of the optimisation we're discussing, and that is to allow the
debugger to be able to find types by name when the user requests
that. (For instance by trying to cast some expression to a type which
is not yet visible).

This is exactly the same argument as for the .debug_pubnames section.

-- Jim 

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