From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5554 invoked by alias); 30 Sep 2002 12:46:07 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 5509 invoked by uid 71); 30 Sep 2002 12:46:06 -0000 Resent-Date: 30 Sep 2002 12:46:06 -0000 Resent-Message-ID: <20020930124606.5508.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, tom.horsley@ccur.com Received: (qmail 4680 invoked by uid 61); 30 Sep 2002 12:45:44 -0000 Message-Id: <20020930124544.4678.qmail@sources.redhat.com> Date: Mon, 30 Sep 2002 05:46:00 -0000 From: tom.horsley@ccur.com Reply-To: tom.horsley@ccur.com To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: debug/8095: missing dwarf info for parent class X-SW-Source: 2002-09/txt/msg00853.txt.bz2 List-Id: >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: