This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
Compilation with -O0 -g no longer creates debug information for all variables.
Created an attachment (id=11447) [edit] test case Compiled for either sh-elf or i686-pc-linux-gnu, currrent mainline cc1plus does not generate any debug information for the variable 'problem'.
Created an attachment (id=11448) [edit] With the translation result for this file, the testcase can be linked This file provides a definition of main and f so that when this file and the test case are translated to an object file, they can be linked together so that you can observe gdb showing - or rather not showing - the variable named "problem".
Confirmed.
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
I am not going to track down what did it, but something has fixed this on the 4.2 branch. I can reproduce it on Debian's 4.1 branch snapshot. If someone wants to fix it on 4.1, it should probably be easy to use the regression hunter to identify what patch caused the string "problem" to appear in the assembly output. It is probably something in the last two and a half months, since the bug was reported, but I do not see any obvious candidates.
(In reply to comment #5) > I am not going to track down what did it, but something has fixed this on the > 4.2 branch. I can reproduce it on Debian's 4.1 branch snapshot. If someone > wants to fix it on 4.1, it should probably be easy to use the regression hunter > to identify what patch caused the string "problem" to appear in the assembly > output. It is probably something in the last two and a half months, since the > bug was reported, but I do not see any obvious candidates. > If this is fixed on mainline, the fix must be rather recent; I see this still failing with r115417: GNU C++ version 4.2.0 20060713 (experimental). What is the oldest gcc 4.2 version where you saw this work?
Subject: Re: [4.1 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor On Tue, Jul 25, 2006 at 12:14:46PM -0000, amylaar at gcc dot gnu dot org wrote: > If this is fixed on mainline, the fix must be rather recent; I see this still > failing with > r115417: GNU C++ version 4.2.0 20060713 (experimental). > What is the oldest gcc 4.2 version where you saw this work? I tested it on HEAD on the day I posted (2006-07-22). Could you check whether that works for you, or it's something environmental?
Subject: Re: [4.1 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor drow at false dot org wrote: >------- Comment #7 from drow at gcc dot gnu dot org 2006-07-25 13:27 ------- >Subject: Re: [4.1 Regression] MIssing debug info at -O0 for a local variable >in a C++ constructor > >On Tue, Jul 25, 2006 at 12:14:46PM -0000, amylaar at gcc dot gnu dot org wrote: > > >>If this is fixed on mainline, the fix must be rather recent; I see this still >>failing with >>r115417: GNU C++ version 4.2.0 20060713 (experimental). >>What is the oldest gcc 4.2 version where you saw this work? >> >> > >I tested it on HEAD on the day I posted (2006-07-22). Could you check >whether that works for you, or it's something environmental? > > When I compile the testcase (using -g -O0) with a cc1plus built from todays sources (r115734), a test search for "problem" in the .s file comes up empty. OTOH, both a native and a cross build eventually failed. Can you find out the exact version of gcc that you tested?
Created an attachment (id=11938) [edit] g++.dg/debug test case As far as I can tell, as a g++.dg/debug test case, this passes for stabs, but fails for dwarf.
Subject: Re: [4.1 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor On Tue, Jul 25, 2006 at 05:08:18PM -0000, joern dot rennecke at st dot com wrote: > When I compile the testcase (using -g -O0) with a cc1plus built from todays > sources (r115734), a test search for "problem" in the .s file comes up > empty. > OTOH, both a native and a cross build eventually failed. > > Can you find out the exact version of gcc that you tested? Now it fails. What the heck? The problem is that an abstract instance of 'problem' is never emitted. For the two concrete instances we try to reference the abstract copy but there isn't one. The variable is emitted, but without a name. The first abstract instance of A::A is a declaration. Later a "definition" (still abstract) is seen. But its DECL_INITIAL is error_mark_node! If I had to guess I'd say that this was a C++ front end problem, or maybe a recent change in cgraph. I don't have time to debug it further right now. The abstract copy of the function has to have a body, or dwarf2out has no structure with which to describe the local variables.
(In reply to comment #10) > If I had to guess I'd say that this was a C++ front end problem, or > maybe a recent change in cgraph. It can't have been a particularly recent change, since it already failed with GNU C++ version 4.1.0 20050323 (experimental) (sh-elf) . It worked with GNU C++ version 4.1.0 20050314 (experimental) (sh-elf) .
It is a cgraph change. There were several patches affecting cgraph_remove_node during this time period; it was probably one of those. The problem is that we throw away the body of the abstract copy of the constructor, before we get around to emitting debug information for it. There's already a debug hook at what looks like the right time. It's just not used for dwarf2: deferred_inline_function. It was replaced by outlining_inline_function, which is called only when we know we'll generate a concrete instance. There's a couple of things we could do: - Not throw away the body. - Try to generate the debug info earlier, and then prune it if it isn't needed. - Try to treat one of the concrete clones (whose bodies we need) as the origin. I think the first one is going to be safest for now. I don't really see how to do it. Jan, do you have a suggestion?
(In reply to comment #12) > It is a cgraph change. There were several patches affecting cgraph_remove_node > during this time period; it was probably one of those. The problem appeared from r96653 to r96654; AFAICT this is the gcc-patches posting for the associated patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01709.html
Subject: Re: [4.1/4.2 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor On Thu, Jul 27, 2006 at 05:29:38PM -0000, amylaar at gcc dot gnu dot org wrote: > The problem appeared from r96653 to r96654; AFAICT this is the gcc-patches > posting for the associated patch: > http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01709.html Jan and Dan Berlin suggested that the right fix for this bug might be to not register the uncloned constructor with cgraph, only the clones.
I don't think I can sort this one out. I think the easiest solution will be to check when marking a function as reachable whether it has an abstract origin, and if so set a flag in the abstract origin preventing its body from being killed, but I can't keep track of all the other similar-but-not-quite-the-same flags in cgraph.
*** Bug 34767 has been marked as a duplicate of this bug. ***
Honza, can you have a look here?
*** Bug 35212 has been marked as a duplicate of this bug. ***
I don't know if this is the correct patch but we made this for the PS3 toolchain: Index: gcc/cgraph.c =================================================================== --- gcc/cgraph.c (revision 2280) +++ gcc/cgraph.c (working copy) @@ -476,14 +476,16 @@ if (!n->next_clone && !n->global.inlined_to && (cgraph_global_info_ready && (TREE_ASM_WRITTEN (n->decl) || DECL_EXTERNAL (n->decl)))) - kill_body = true; + { + DECL_INITIAL (node->decl) = error_mark_node; + kill_body = true; + } } if (kill_body && !dump_enabled_p (TDI_tree_all) && flag_unit_at_a_time) { DECL_SAVED_TREE (node->decl) = NULL; DECL_STRUCT_FUNCTION (node->decl) = NULL; - DECL_INITIAL (node->decl) = error_mark_node; } cgraph_n_nodes--; /* Do not free the structure itself so the walk over chain can continue. */
I am just going to test this patch and relook at it when the test is finished but I can see what the issue is. at -O0 we have unit-at-a-time on. Though there is still an issue if we don't have any clones, I think. I will relook more into it after the bootstrap/test finishes.
A patch like this seems like a decent workaround to me. Honza, any opinions on this approach? Ian Index: cgraph.c =================================================================== --- cgraph.c (revision 134283) +++ cgraph.c (working copy) @@ -615,6 +615,14 @@ cgraph_remove_node (struct cgraph_node * kill_body = true; } + /* We don't release the body of abstract functions, because they may + be needed when emitting debugging information. In particular + this will happen for C++ constructors/destructors. FIXME: + Ideally we would check to see whether there are any reachable + functions whose DECL_ABSTRACT_ORIGIN points to this decl. */ + if (DECL_ABSTRACT (node->decl)) + kill_body = false; + if (kill_body && flag_unit_at_a_time) cgraph_release_function_body (node); node->decl = NULL;
(In reply to comment #21) > A patch like this seems like a decent workaround to me. > > Honza, any opinions on this approach? This looks good to me also.
Closing 4.1 branch.
So the patch http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00133.html that fixes this got accepted. So this might end up in trunk soon. For 4.3 and 4.2 we might want to apply Ian's patch as it is less disruptive. See http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01981.html .
Subject: Bug 27574 Author: dodji Date: Wed Nov 12 21:57:44 2008 New Revision: 141807 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141807 Log: gcc/ChangeLog: 2008-11-12 Dodji Seketeli <dodji@redhat.com> PR debug/27574 * cgraph.h: New abstract_and_needed member to struct cgraph_node. * cgraphunit.c (cgraph_analyze_functions): Flag abstract functions - which clones are reachable - as "abstract and needed". * cgraph.c (cgraph_release_function_body): If a node is "abstract and needed", do not release its DECL_INITIAL() content because that will be needed to emit debug info. gcc/testsuite/ChangeLog: 2008-11-12 Dodji Seketeli <dodji@redhat.com> PR debug/27574 * g++.dg/debug/dwarf2/local-var-in-contructor.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/local-var-in-contructor.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/cgraph.h trunk/gcc/cgraphunit.c trunk/gcc/final.c trunk/gcc/testsuite/ChangeLog
Subject: Bug 27574 Author: dodji Date: Thu Nov 13 10:55:01 2008 New Revision: 141819 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141819 Log: Fix ChangeLog entry: PR debug/27574 * cgraph.h: New abstract_and_needed member to struct cgraph_node. * cgraphunit.c (cgraph_analyze_functions): Flag abstract functions - which clones are reachable - as "abstract and needed". * cgraph.c (cgraph_release_function_body): If a node is "abstract and needed", do not release its DECL_INITIAL() content that will be needed to emit debug info. Modified: trunk/gcc/ChangeLog
Subject: Bug 27574 Author: dodji Date: Fri Nov 14 13:26:59 2008 New Revision: 141858 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141858 Log: gcc/ChangeLog: PR debug/27574 * cgraph.h: New abstract_and_needed member to struct cgraph_node. * cgraphunit.c (cgraph_analyze_functions): Flag abstract functions -which clones are reachable - as "abstract and needed". * cgraph.c (cgraph_release_function_body): If a node is "abstract and needed", do not release its DECL_INITIAL() content will be needed to emit debug info. gcc/testsuite/ChangeLog: PR debug/27574 * g++.dg/debug/dwarf2/local-var-in-contructor.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/debug/dwarf2/local-var-in-contructor.C Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/cgraph.c branches/gcc-4_3-branch/gcc/cgraph.h branches/gcc-4_3-branch/gcc/cgraphunit.c branches/gcc-4_3-branch/gcc/final.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
Subject: Bug 27574 Author: dodji Date: Wed Nov 19 00:15:52 2008 New Revision: 141984 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141984 Log: gcc/ChangeLog: 2008-11-14 Dodji Seketeli <dodji@redhat.com> PR c++/27574 * gcc/cgraph.c (cgraph_remove_node): Do not remove the body of abstract functions. It might be useful to emit debugging information. This is a patch from Ian Lance Taylor. * cgraphunit.c (cgraph_optimize): Do not cry when bodies of abstract functions are still around. They are useful to output debug info. gcc/testsuite/ChangeLog 2008-11-14 Dodji Seketeli <dodji@redhat.com> PR c++/27574 * testsuite/g++.dg/debug/dwarf2/dwarf2.exp: Backport this here from gcc-4_3-branch. * g++.dg/debug/dwarf2/local-var-in-contructor.C: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/debug/dwarf2/ branches/gcc-4_2-branch/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2.exp branches/gcc-4_2-branch/gcc/testsuite/g++.dg/debug/dwarf2/local-var-in-contructor.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/cgraph.c branches/gcc-4_2-branch/gcc/cgraphunit.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
Fixed in trunk, 4.3 and 4.2 branch.
I think the testcase pr27574.C should be added to the testsuite before closing this bug.
Sorry, I only checked for the presence of the original testcase name in the testsuite, and thus missed the fact that there is a new test called local-var-in-contructor.C [sic] .
*** Bug 39961 has been marked as a duplicate of this bug. ***