This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: c++/1234: local variables in destructor ignored


The following reply was made to PR c++/1234; it has been noted by GNATS.

From: Jim Blandy <jimb@redhat.com>
To: mvanier@cs.caltech.edu
Cc: gdb-gnats@sources.redhat.com
Subject: Re: c++/1234: local variables in destructor ignored
Date: 04 Jun 2003 19:00:15 -0500

 I think this is a compiler bug.  It looks to me like the debugging
 info generated by the compiler doesn't tell GDB what it needs to know
 to be able to print local variables in the destructor.
 
 Michael, could you look at the debugging info in your program, and
 verify that it's as I describe here?  If so, then I think this is a
 G++ bug, not a GDB bug.
 
     $ cat foo.cc
     class Test {
     private:
         int *data;
     public:
         Test();
        ~Test();
     };
 
     Test::Test() {
         data = new int[1000];
     }
 
     Test::~Test() {
         int *t = data;
         delete [] t;
     }
 
 
     int main() {
         Test s;
 
         return 0;
     }
 
     $ $Gcc33B/g++ -g foo.cc -o foo
     $ readelf -wi foo > foo.wi~
 
 Now foo.wi~, which contains the Dwarf debugging info in human-readable
 form.  The info for ~Test we see is this:
 
  <1><c57>: Abbrev Number: 2 (DW_TAG_structure_type)
      DW_AT_sibling     : <cd5>	
      DW_AT_name        : (indirect string, offset: 0x9c1): Test	
      DW_AT_byte_size   : 4	
      DW_AT_decl_file   : 1	
      DW_AT_decl_line   : 1	
  ...
  <2><cbe>: Abbrev Number: 9 (DW_TAG_subprogram)
      DW_AT_external    : 1	
      DW_AT_name        : (indirect string, offset: 0x9c0): ~Test	
      DW_AT_decl_file   : 1	
      DW_AT_decl_line   : 6	
      DW_AT_declaration : 1	
  <3><cc7>: Abbrev Number: 5 (DW_TAG_formal_parameter)
      DW_AT_type        : <ce8>	
      DW_AT_artificial  : 1	
  <3><ccd>: Abbrev Number: 5 (DW_TAG_formal_parameter)
      DW_AT_type        : <cdb>	
      DW_AT_artificial  : 1	
 
 This is for the declaration of ~Test inside the class declaration.
 It's just a declaration; the following subtree is the definition:
 
  <1><d4c>: Abbrev Number: 14 (DW_TAG_subprogram)
      DW_AT_sibling     : <d75>	
      DW_AT_specification: <cbe>	
      DW_AT_decl_line   : 13	
      DW_AT_inline      : 2	(declared as inline but ignored)
  <2><d57>: Abbrev Number: 15 (DW_TAG_formal_parameter)
      DW_AT_name        : (indirect string, offset: 0x98a): this	
      DW_AT_type        : <d0f>	
      DW_AT_artificial  : 1	
  <2><d61>: Abbrev Number: 15 (DW_TAG_formal_parameter)
      DW_AT_name        : (indirect string, offset: 0x9c6): __in_chrg	
      DW_AT_type        : <d75>	
      DW_AT_artificial  : 1	
  <2><d6b>: Abbrev Number: 18 (DW_TAG_variable)
      DW_AT_name        : t	
      DW_AT_decl_file   : 1	
      DW_AT_decl_line   : 14	
      DW_AT_type        : <cd5>	
 
 It has a DW_AT_specification attribute pointing to the declaration
 die, <cbe>.  It does have an entry for 't'.
 
 But what's missing here are DW_AT_low_pc and DW_AT_high_pc entries,
 like those present on the other DW_AT_subprogram entries.  Without
 that, GDB has no idea that this debugging information applies to the
 code addresses for Test::~Test().
 
 The entry for 't' is also lacking a DW_AT_location attribute, so even
 if GDB knew the addreses for Test::~Test (), it wouldn't be able to
 find 't'.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]