From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4960 invoked by alias); 28 Jan 2013 20:08:54 -0000 Received: (qmail 4501 invoked by uid 48); 28 Jan 2013 20:08:15 -0000 From: "tromey at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/55059] [4.8 Regression] DWARF missing concrete class definition Date: Mon, 28 Jan 2013 20:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Keywords: wrong-debug X-Bugzilla-Severity: normal X-Bugzilla-Who: tromey at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg02605.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55059 --- Comment #5 from Tom Tromey 2013-01-28 20:08:11 UTC --- (In reply to comment #4) > (In reply to comment #3) > > If we change gdb to cope with this, I think the effect will be to undo what > > the patches here were attempting to accomplish. > > I believe the patch was trying to avoid treating a partial definition as a full > definition when there's a full definition of the class in another CU. If > there's only the partial definition, the best we can do is to use that. That > seems better to me than the situation we had before. That isn't what gdb does, though. I've been thinking about this today and have a list of objections - I couldn't find support in the DWARF standard for this approach. I realize DWARF is "anything goes" -- but if this approach is taken then I think at least a bug report to all the known DWARF consumers is in order. I imagine several of them will need fixes. Fixing this in gdb seems a bit expensive. I think we will have to track all partial definitions of a type and then replace them with the real definition, if one is found. It is unclear how much DWARF we'll have to read to dig up the real definition when using the .gdb_index. Basically this is a new, non-local property of DWARF with zero connections between the declaration and definition. It seems like there can be many obscure bad scenarios. If the motivation for this feature in GCC is space savings in the DWARF, then it seems like it should be on one of the various -f options, not the default. For .debug_types at least I think it is better to always emit the full information. This may be true of dwz as well, though I suppose dwz could also be taught this convention. IIUC this approach relies on ODR for C++ (and presumably just can't be used for other languages). However, I think this presumes too much. It may be that the ODR is violated in a program, and the debuginfo can be used to help determine this. But this rule makes it harder to discover differences between CUs. Finally, the original thread discusses gdb a fair amount and by my reading was contingent on "gdb doing the right thing". But this is not the case.