public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "sgjohnston at yahoo dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/12385] New: Full debug info not emitted for C++ classes with external virtual functions
Date: Wed, 24 Sep 2003 07:56:00 -0000	[thread overview]
Message-ID: <20030924064323.12385.sgjohnston@yahoo.com> (raw)

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12385

           Summary: Full debug info not emitted for C++ classes with
                    external virtual functions
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sgjohnston at yahoo dot com
                CC: gcc-bugs at gcc dot gnu dot org,sgjohnston at yahoo dot
                    com
 GCC build triplet: gcc-3.4-20030917
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu

If a C++ class has a vtable, and at least one of the virtual functions is not
defined within the comp unit (ie it's external), then the full debug info for
that class is not emitted. Instead, the die for the class is partly emitted,
with the DW_AT_declaration tag. This can cause confusion in gdb, if namespaces
are used, because gdb tried to look externally to the comp unit to find the full
definition. If the same class name appears in more than one namespace, then
infinite recursion can result (this happens with classes in gtkmm).

Example:

class ObjectBase
{
public:
  virtual void test();
  void test2();
  int i;
};

void ObjectBase::test2()
{
  i = 123;
}

int main()
{
  ObjectBase obj1;
  obj1.test();
}

Emits the following for class ObjectBase:

 <1><61>: Abbrev Number: 2 (DW_TAG_structure_type)
     DW_AT_sibling     : <a9>	
     DW_AT_name        : (indirect string, offset: 0x0): ObjectBase	
     DW_AT_declaration : 1	
 <2><6b>: Abbrev Number: 3 (DW_TAG_subprogram)
     DW_AT_sibling     : <99>	
     DW_AT_external    : 1	
     DW_AT_name        : test2	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 10	
     DW_AT_MIPS_linkage_name: _ZN10ObjectBase5test2Ev	
     DW_AT_declaration : 1	
 <3><92>: Abbrev Number: 4 (DW_TAG_formal_parameter)
     DW_AT_type        : <a9>	
     DW_AT_artificial  : 1	
 <2><99>: Abbrev Number: 5 (DW_TAG_subprogram)
     DW_AT_external    : 1	
     DW_AT_name        : (indirect string, offset: 0x0): ObjectBase	
     DW_AT_artificial  : 1	
     DW_AT_declaration : 1	
 <3><a1>: Abbrev Number: 4 (DW_TAG_formal_parameter)
     DW_AT_type        : <a9>	
     DW_AT_artificial  : 1

ObjectBase::test() is not emitted, nor are the artifical operator=() methods,
etc. Also, ObjectBase is noted a declaration. If no virtual functions are
present, then the full class is emitted as expected.

This behaviour happens because a class with a vtable is not written out until
the end of the comp unit, when the vtables are written. When the decision is
made to write out the vtables, is for some reason the vtable is not written,
then the class's debug info is also not written, and just the dies that have
been collected through usage are included in the class. 

This behaviour was more pronounced in gcc 3.2.2, and I thought I had a fix...
but 3.4 is very different in this area, and I can't see a similar fix. The fix I
had for 3.2.2, for what it's worth, was:

*** decl2.c	2003-09-23 23:38:10.000000000 -0700
--- decl2-patch.c	2003-09-23 23:36:58.000000000 -0700
*************** finish_vtable_vardecl (t, data)
*** 2464,2480 ****
        if (flag_syntax_only)
  	TREE_ASM_WRITTEN (vars) = 1;
  
-       /* Since we're writing out the vtable here, also write the debug 
- 	 info.  */
-       note_debug_info_needed (ctype);
- 
        return 1;
      }
  
!   /* If the references to this class' vtables were optimized away, still
!      emit the appropriate debugging information.  See dfs_debug_mark.  */
!   if (DECL_COMDAT (vars)
!       && CLASSTYPE_DEBUG_REQUESTED (ctype))
      note_debug_info_needed (ctype);
  
    return 0;
--- 2464,2478 ----
        if (flag_syntax_only)
  	TREE_ASM_WRITTEN (vars) = 1;
  
        return 1;
      }
  
!   /* If vtable is external, or if the references to this class' vtables
!      were optimized away, still emit the appropriate debugging information.
!      See dfs_debug_mark.  */
!   if (DECL_NEEDED_P (vars) ||
!       (DECL_COMDAT (vars)
!        && CLASSTYPE_DEBUG_REQUESTED (ctype)))
      note_debug_info_needed (ctype);
  
    return 0;
-----------------

Thanks for any help
Stuart


             reply	other threads:[~2003-09-24  6:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-24  7:56 sgjohnston at yahoo dot com [this message]
2003-09-25 21:43 ` [Bug debug/12385] " pinskia at gcc dot gnu dot org
2003-09-26  7:04 ` sgjohnston at yahoo dot com
2003-10-10 14:18 ` drow at gcc dot gnu dot org
2004-01-10  6:26 ` pinskia at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030924064323.12385.sgjohnston@yahoo.com \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).