This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
Re: New Proposal: Global Types section
- To: jcownie at etnus dot com, DWARF2 at corp dot sgi dot com, BRENDER at gemevn dot zko dot dec dot com
- Subject: Re: New Proposal: Global Types section
- From: brender at gemevn dot zko dot dec dot com (Ron 603-884-2088)
- Date: Thu, 6 Apr 2000 10:18:43 -0400
- Reply-To: brender at gemevn dot zko dot dec dot com (Ron 603-884-2088)
>> 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.
I think this is the right idea, although I don't know what the actual
criteria is in detail.
FWIW, in Compaq C++ for Alpha Linux this "optimization" of the symbol table
size does happen by default for the typical -g option, but the user can force
full type (class) descriptions to always be emitted using -gall.
(IIRC & FWIW, essentially the optimization technique -- and -g choice -- is
used by Compaq C++ for Alpha Tru64 UNIX, which uses a STAB/eCOFF
representation.)
Ron