Re: debug/8095: missing dwarf info for parent class

[Daniel Jacobowitz <drow@mvista.com>]

The following reply was made to PR debug/8095; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@mvista.com>
To: tom.horsley@ccur.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Mon, 30 Sep 2002 16:38:12 -0400

 On Mon, Sep 30, 2002 at 12:45:44PM -0000, tom.horsley@ccur.com wrote:
 > 
 > >Number:         8095
 > >Category:       debug
 > >Synopsis:       missing dwarf info for parent class
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Mon Sep 30 05:46:05 PDT 2002
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     tom.horsley@ccur.com
 > >Release:        gcc 3.2
 > >Organization:
 > >Environment:
 > redhat linux null beta
 > >Description:
 > I get the impression that g++ probably attempts to optimize the dwarf it generates to avoid generating masses of debug info for types that are not referenced in a compilation unit.
 > 
 > That is all well and good, but it appears to go too far,
 > leaving out parent classes even when it does generate the info for a derived class.
 > 
 > If a type is "used", parent classes of that type should also be counted as "used".
 > >How-To-Repeat:
 > Any old C++ program with more than one level of class heirarchy will demonstrate this. Declare some instances of the most derived class, but never refer to the base class in the source code any place other than the derviced class declaration. The resulting dwarf will have no information about the members of the parent class.
 > 
 > There is some chance you can find the parent definition in another compilation unit if it happens to be used there, but there are no guarantees you'll be able to find it anywhere. This makes symbolic debugging a bit difficult if you actually want to look at the base class members.
 
 You need to be more precise.  Not "any old C++ program" demonstrates
 this.  Here's a counterexample:
 
 struct A {
  int x;
 };
 
 struct B : public A {
   int z;
 };
 
 B b;
 
  <1><25>: Abbrev Number: 2 (DW_TAG_structure_type)
      DW_AT_sibling     : <7f>   
      DW_AT_name        : A      
      DW_AT_byte_size   : 4      
      DW_AT_decl_file   : 1      
      DW_AT_decl_line   : 1      
 
  <1><9d>: Abbrev Number: 2 (DW_TAG_structure_type)
      DW_AT_sibling     : <f7>   
      DW_AT_name        : B      
      DW_AT_byte_size   : 4      
      DW_AT_decl_file   : 1      
      DW_AT_decl_line   : 5      
  <2><a7>: Abbrev Number: 13 (DW_TAG_inheritance)
      DW_AT_type        : <25>
      DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
      DW_AT_accessibility: 1     (public)
 
 
 Please provide a test case.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer