Re: PR debug/7081: emit DW_TAG_class_type and DW_TAG_interface_type

[Ian Lance Taylor <iant at google dot com>]

Jakub Jelinek <jakub@redhat.com> writes:

> On Wed, Dec 05, 2007 at 07:41:34AM -0800, Ian Lance Taylor wrote:
> > Alexandre Oliva <aoliva@redhat.com> writes:
> > 
> > > We've long output C++ classes and Java classes and interfaces as
> > > DW_TAG_structure_type.  This patch fixes it, with a different approach
> > > from the one proposed at
> > > http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01748.html
> > > 
> > > Instead of moving the declared-as-class bit from C++ into common
> > > trees, it introduces a langhook to let the language decide what is a
> > > class, what is an interface and what is a structure.
> > 
> > Offhand, I don't see how that could work with LTO.  Since we need to
> > add new functionality regardless, I'd rather see something which we
> > can support in LTO.
> 
> Why can't this work with LTO?  The type's full debug info will be in
> the emitted debug info, so the LTO frontend can just add its own
> language bits when parsing something special (e.g. DW_TAG_class_type,
> DW_TAG_interface_type in this case, or special info about Fortran
> deferred/assumed-{shape,size} etc. arrays, or whether DW_TAG_member
> (vs. DW_TAG_variable) was used, etc.), stick them in LTO's struct lang_type
> resp. struct lang_decl and then give back to the debugger using the
> langhook.
> That way this bloats only LTO compilations, languages which never need
> these don't need to waste bits in decls or types and languages which
> need it have it there already.

You're right, that could work.

In general I think it would be better for the middle-end to have a
better knowledge of these details.  That will permit generic
implementations of devirtualization, for instance.  But I won't block
this patch on those grounds.

Ian