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

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

[Daniel Jacobowitz]

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

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

[bangerth]

Synopsis: missing dwarf info for parent class

State-Changed-From-To: feedback->closed
State-Changed-By: bangerth
State-Changed-When: Tue Apr 15 15:05:13 2003
State-Changed-Why:
    Seems as if we came to a conclusion

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8095

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

[Daniel Jacobowitz]

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

From: Daniel Jacobowitz <drow@mvista.com>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: gcc-bugs@gcc.gnu.org, tom.horsley@ccur.com, gcc-gnats@gcc.gnu.org
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Tue, 15 Apr 2003 09:35:43 -0400

 On Fri, Mar 14, 2003 at 03:58:32PM -0600, Wolfgang Bangerth wrote:
 > 
 > > > If there are ways to tie debug output to a certain member of a class (just
 > > > as we do for vtables), then I would say this is a good idea. If someone
 > > > doesn't like this, then compile your library with -g.
 > > 
 > > I guess that sounds pretty reasonable to me, too.
 > 
 > So shall I close the report then? Note that I couldn't verify that the 
 > debug info is actually emitted when the vtable is emitted -- could you 
 > check this?
 
 Yes, when the vtable is emited the debug information is also.  I think
 we can close this PR.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

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

From: Daniel Jacobowitz <drow@mvista.com>
To: Horsley Tom <Tom.Horsley@ccur.com>
Cc: Wolfgang Bangerth <bangerth@ticam.utexas.edu>, gcc-bugs@gcc.gnu.org,
	gcc-gnats@gcc.gnu.org
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Mon, 17 Mar 2003 09:18:29 -0500

 On Mon, Mar 17, 2003 at 07:59:02AM -0500, Horsley Tom wrote:
 > > > If there are ways to tie debug output to a certain member of a class
 > (just
 > > > as we do for vtables), then I would say this is a good idea. If someone
 > > > doesn't like this, then compile your library with -g.
 > > > 
 > > > But that's just my opinion.
 > > 
 > > I guess that sounds pretty reasonable to me, too.
 > 
 > I'm not sure the intent of my original bug report made it through
 > this discussion :-). I don't see why you'd always have to emit
 > debug info for every header file in every compilation unit.
 > Just emit debug info for types that are "used". The point of the
 > bug report was to say that the "this" variable should count
 > as "using" a type, and if a derived class is "used", then all its
 > base classes should be "used" as well (after all, there isn't
 > all that much difference between a base class and a member variable,
 > and you wouldn't leave out member variables just because they
 > weren't directly referenced would you?).
 > 
 > Of course I say this is total ignorance of how gcc decides to emit
 > debug info :-).
 
 The problem is that this causes debug info for that class to be emitted
 multiple times.  If you compile the source file that causes the base
 class to be emitted - there must be one, or your program won't link -
 then that file should have the debug info.
 
 I still need to verify that it' being output in the right place.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer

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

[Horsley Tom]

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

From: Horsley Tom <Tom.Horsley@ccur.com>
To: 'Daniel Jacobowitz' <drow@mvista.com>, Wolfgang Bangerth
	 <bangerth@ticam.utexas.edu>
Cc: gcc-bugs@gcc.gnu.org, Horsley Tom <Tom.Horsley@ccur.com>, 
	gcc-gnats@gcc.gnu.org
Subject: RE: debug/8095: missing dwarf info for parent class
Date: Mon, 17 Mar 2003 07:59:02 -0500

 > > If there are ways to tie debug output to a certain member of a class
 (just
 > > as we do for vtables), then I would say this is a good idea. If someone
 > > doesn't like this, then compile your library with -g.
 > > 
 > > But that's just my opinion.
 > 
 > I guess that sounds pretty reasonable to me, too.
 
 I'm not sure the intent of my original bug report made it through
 this discussion :-). I don't see why you'd always have to emit
 debug info for every header file in every compilation unit.
 Just emit debug info for types that are "used". The point of the
 bug report was to say that the "this" variable should count
 as "using" a type, and if a derived class is "used", then all its
 base classes should be "used" as well (after all, there isn't
 all that much difference between a base class and a member variable,
 and you wouldn't leave out member variables just because they
 weren't directly referenced would you?).
 
 Of course I say this is total ignorance of how gcc decides to emit
 debug info :-).

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

[Wolfgang Bangerth]

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

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gcc-bugs@gcc.gnu.org, <tom.horsley@ccur.com>, <gcc-gnats@gcc.gnu.org>
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Fri, 14 Mar 2003 15:58:32 -0600 (CST)

 > > If there are ways to tie debug output to a certain member of a class (just
 > > as we do for vtables), then I would say this is a good idea. If someone
 > > doesn't like this, then compile your library with -g.
 > 
 > I guess that sounds pretty reasonable to me, too.
 
 So shall I close the report then? Note that I couldn't verify that the 
 debug info is actually emitted when the vtable is emitted -- could you 
 check this?
 
 Thanks
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

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

[Daniel Jacobowitz]

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

From: Daniel Jacobowitz <drow@mvista.com>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: gcc-bugs@gcc.gnu.org, tom.horsley@ccur.com, gcc-gnats@gcc.gnu.org
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Fri, 14 Mar 2003 16:51:45 -0500

 On Fri, Mar 14, 2003 at 03:48:12PM -0600, Wolfgang Bangerth wrote:
 > 
 > > As I mentioned, I'd like more opinions...
 > 
 > Sorry, I understood this but just wanted to raise the issue again -- 
 > opinions will not come in if the question bitrots in gnats :-) (Which is 
 > not your fault -- you had asked, but received no answers.)
 > 
 > > what if the class is emitted
 > > in a shared library not compiled using debug info, etc.?  I guess the
 > > question is: we want to emit debug information for all used types. 
 > > Does inheriting from a type count as using it?  If so we should
 > > probably be emitting debug info for Multiple1 in the example in this
 > > PR.
 > 
 > This doesn't strike me as a particularly useful idea, since then you would 
 > have to emit debug info in every compilation unit that includes a certain 
 > header file. This might be a lot of duplication.
 > 
 > If there are ways to tie debug output to a certain member of a class (just
 > as we do for vtables), then I would say this is a good idea. If someone
 > doesn't like this, then compile your library with -g.
 > 
 > But that's just my opinion.
 
 I guess that sounds pretty reasonable to me, too.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer

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

[Wolfgang Bangerth]

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

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gcc-bugs@gcc.gnu.org, <tom.horsley@ccur.com>, <gcc-gnats@gcc.gnu.org>
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Fri, 14 Mar 2003 15:48:12 -0600 (CST)

 > As I mentioned, I'd like more opinions...
 
 Sorry, I understood this but just wanted to raise the issue again -- 
 opinions will not come in if the question bitrots in gnats :-) (Which is 
 not your fault -- you had asked, but received no answers.)
 
 > what if the class is emitted
 > in a shared library not compiled using debug info, etc.?  I guess the
 > question is: we want to emit debug information for all used types. 
 > Does inheriting from a type count as using it?  If so we should
 > probably be emitting debug info for Multiple1 in the example in this
 > PR.
 
 This doesn't strike me as a particularly useful idea, since then you would 
 have to emit debug info in every compilation unit that includes a certain 
 header file. This might be a lot of duplication.
 
 If there are ways to tie debug output to a certain member of a class (just
 as we do for vtables), then I would say this is a good idea. If someone
 doesn't like this, then compile your library with -g.
 
 But that's just my opinion.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

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

[Daniel Jacobowitz]

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

From: Daniel Jacobowitz <drow@mvista.com>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	nobody@gcc.gnu.org, tom.horsley@ccur.com, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Fri, 14 Mar 2003 16:33:41 -0500

 On Fri, Mar 14, 2003 at 09:19:18PM -0000, bangerth@dealii.org wrote:
 > Synopsis: missing dwarf info for parent class
 > 
 > Responsible-Changed-From-To: unassigned->drow
 > Responsible-Changed-By: bangerth
 > Responsible-Changed-When: Fri Mar 14 21:19:17 2003
 > Responsible-Changed-Why:
 >     Analyzed this PR
 > State-Changed-From-To: open->feedback
 > State-Changed-By: bangerth
 > State-Changed-When: Fri Mar 14 21:19:17 2003
 > State-Changed-Why:
 >     Daniel, what's the state of this? If debug generation is
 >     really tied to the definition of the first virtual non-
 >     abstract function, then I can't see how this could be
 >     wrong: no program can be linked without having such a 
 >     definition, so at one point or other, a definition has to
 >     be given, and then the executable also contains the debug
 >     information. Unfortunately, my versions of readelf seems
 >     to be too old to verify this myself.
 
 As I mentioned, I'd like more opinions... what if the class is emitted
 in a shared library not compiled using debug info, etc.?  I guess the
 question is: we want to emit debug information for all used types. 
 Does inheriting from a type count as using it?  If so we should
 probably be emitting debug info for Multiple1 in the example in this
 PR.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer

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

[bangerth]

Synopsis: missing dwarf info for parent class

Responsible-Changed-From-To: unassigned->drow
Responsible-Changed-By: bangerth
Responsible-Changed-When: Fri Mar 14 21:19:17 2003
Responsible-Changed-Why:
    Analyzed this PR
State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Fri Mar 14 21:19:17 2003
State-Changed-Why:
    Daniel, what's the state of this? If debug generation is
    really tied to the definition of the first virtual non-
    abstract function, then I can't see how this could be
    wrong: no program can be linked without having such a 
    definition, so at one point or other, a definition has to
    be given, and then the executable also contains the debug
    information. Unfortunately, my versions of readelf seems
    to be too old to verify this myself.
    
    W.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8095

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

[Daniel Jacobowitz]

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

From: Daniel Jacobowitz <drow@mvista.com>
To: Horsley Tom <Tom.Horsley@ccur.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Tue, 1 Oct 2002 15:06:44 -0400

 On Tue, Oct 01, 2002 at 08:02:44AM -0400, Horsley Tom wrote:
 > > -----Original Message-----
 > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
 > > Sent: Monday, September 30, 2002 4:38 PM
 > > To: tom.horsley@ccur.com
 > > Cc: gcc-gnats@gcc.gnu.org
 > > Subject: Re: debug/8095: missing dwarf info for parent class
 > >...
 > > Please provide a test case.
 > 
 > Weird. Every program I have exhibits this behavior. Here's
 > a random test program I picked this morning on my first try :-).
 > 
 > class Vtab1 {
 > public:
 >    Vtab1();
 >    Vtab1(int init_x);
 >    virtual
 >    ~Vtab1();
 >    virtual int
 >    GetX();
 > private:
 >    int x;
 > };
 > class Vtab2 {
 > public:
 >    Vtab2();
 >    Vtab2(int init_y);
 >    virtual
 >    ~Vtab2();
 >    virtual int
 >    GetY();
 > private:
 >    int y;
 > };
 > class Multiple1 : public Vtab1, public Vtab2 {
 > public:
 >    Multiple1(int init_x, int init_y, int init_z);
 >    virtual
 >    ~Multiple1();
 >    virtual int
 >    GetZ();
 > private:
 >    int z;
 > };
 > class Derived1 : public Multiple1 {
 > public:
 >    Derived1(int init_x, int init_y, int init_z);
 >    virtual
 >    ~Derived1();
 >    virtual int
 >    GetX();
 > private:
 >    int my_x;
 > };
 > Derived1::Derived1(int init_x, int init_y, int init_z)
 >  : Multiple1(init_x, init_y, init_z) {
 >    my_x = GetY();
 > }
 > Derived1::~Derived1() {
 >    return;
 > }
 > int
 > Derived1::GetX() {
 >    return my_x;
 > }
 > 
 > Using g++ 3.2 (Red Hat Linux Rawhide 3.2-1), if I compile
 > this as g++ -g -c d1.cpp and examine the dwarf in the d1.o file,
 > no symbols named "x","y", or "z" appear anywhere, and the
 > parent class info for Derived1 points to a DW_AT_declaration
 > for Multiple1, but there is no corresponding class definition
 > with a DW_AT_specification pointing to that Multiple1, so
 > no definition is available anywhere for the actual contents
 > of the parent classes, yet they are certainly used since
 > the type of the "this" pointer in the member functions
 > refers to them indirectly.
 
 OK.  The reason that debug info for (for example) Vtab1 is not emitted
 is because it contains unimplemented virtual functions which are not
 declared as abstract.  Thus the vtable for Vtab1 is not emitted, and
 the debug information appears to be tied to that.
 
 I could make a good argument that this isn't right.  Can a C++
 maintainer comment?
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer

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

[Horsley Tom]

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

From: Horsley Tom <Tom.Horsley@ccur.com>
To: 'Daniel Jacobowitz' <drow@mvista.com>, Horsley Tom
	 <Tom.Horsley@ccur.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: RE: debug/8095: missing dwarf info for parent class
Date: Tue, 1 Oct 2002 08:02:44 -0400 

 > -----Original Message-----
 > From: Daniel Jacobowitz [mailto:drow@mvista.com]
 > Sent: Monday, September 30, 2002 4:38 PM
 > To: tom.horsley@ccur.com
 > Cc: gcc-gnats@gcc.gnu.org
 > Subject: Re: debug/8095: missing dwarf info for parent class
 >...
 > Please provide a test case.
 
 Weird. Every program I have exhibits this behavior. Here's
 a random test program I picked this morning on my first try :-).
 
 class Vtab1 {
 public:
    Vtab1();
    Vtab1(int init_x);
    virtual
    ~Vtab1();
    virtual int
    GetX();
 private:
    int x;
 };
 class Vtab2 {
 public:
    Vtab2();
    Vtab2(int init_y);
    virtual
    ~Vtab2();
    virtual int
    GetY();
 private:
    int y;
 };
 class Multiple1 : public Vtab1, public Vtab2 {
 public:
    Multiple1(int init_x, int init_y, int init_z);
    virtual
    ~Multiple1();
    virtual int
    GetZ();
 private:
    int z;
 };
 class Derived1 : public Multiple1 {
 public:
    Derived1(int init_x, int init_y, int init_z);
    virtual
    ~Derived1();
    virtual int
    GetX();
 private:
    int my_x;
 };
 Derived1::Derived1(int init_x, int init_y, int init_z)
  : Multiple1(init_x, init_y, init_z) {
    my_x = GetY();
 }
 Derived1::~Derived1() {
    return;
 }
 int
 Derived1::GetX() {
    return my_x;
 }
 
 Using g++ 3.2 (Red Hat Linux Rawhide 3.2-1), if I compile
 this as g++ -g -c d1.cpp and examine the dwarf in the d1.o file,
 no symbols named "x","y", or "z" appear anywhere, and the
 parent class info for Derived1 points to a DW_AT_declaration
 for Multiple1, but there is no corresponding class definition
 with a DW_AT_specification pointing to that Multiple1, so
 no definition is available anywhere for the actual contents
 of the parent classes, yet they are certainly used since
 the type of the "this" pointer in the member functions
 refers to them indirectly.

debug/8095: missing dwarf info for parent class

[tom.horsley]

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

>Release-Note:
>Audit-Trail:
>Unformatted: