I see similar problems on AIX.

Ulrich Weigand wrote:

When building with -funit-at-a-time (which is on by default with -O2), *no*
debug info for global variables appears to be emitted at all.

The problem appears to be this piece of code in check_global_declarations:

      /* Do not emit debug information about variables that are in
         static storage, but not defined.  */
      if (TREE_CODE (decl) == VAR_DECL
          && TREE_STATIC (decl)
          && !TREE_ASM_WRITTEN (decl))
        DECL_IGNORED_P (decl) = 1;

which was added by:
http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg01250.html

2004-11-25  Mark Mitchell  <mark@codesourcery.com>

        PR c++/18556
        * toplev.c (check_global_declarations): Set DECL_IGNORED_P on
        unemitted variables with static storage duration.


However, check_global_declarations is called (by the C front-end at least)
*before* the call to cgraph_optimize.  At this time, when -funit-at-a-time
is in effect, *no* variables have been emitted to assembler as far as I
can tell, and thus all global variables get the DECL_IGNORED_P flag.

Interestingly enough, when building with the C++ front-end, the debug
info is properly emitted.  I'm not sure where exactly the difference is ...

Is there a test case for this bug?  (The usual things: preprocessed source,
command-line, etc.?)

(In reply to comment #3)
> Is there a test case for this bug?  (The usual things: preprocessed source,
> command-line, etc.?)
From <http://gcc.gnu.org/ml/gcc/2005-05/msg01635.html>:

You can reproduce it using:
static int i;
int main(void)
{
  i += 3;
  i *= 5;
  return 0;
}

and readelf and looking for the DW_TAG_variable tag.

Subject: Re:  [4.0/4.1 Regression] debug info omitted for
 global variables

pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-05 23:50 -------
> (In reply to comment #3)
> 
>>Is there a test case for this bug?  (The usual things: preprocessed source,
>>command-line, etc.?)
> 
> From <http://gcc.gnu.org/ml/gcc/2005-05/msg01635.html>:
> 
> You can reproduce it using:
> static int i;
> int main(void)
> {
>   i += 3;
>   i *= 5;
>   return 0;
> }
> 
> and readelf and looking for the DW_TAG_variable tag.

Thanks.  I can see the problem, when compiling with -O2.

I'm not really sure yet whether this is my fault, or whether some 
subsequent change to cgraph after my changes got checked in broke things.

In any case, I'm don't think that the code I wrote in 
check_global_declarations is wrong, in and of itself.  If 
check_global_declarations is going to be responsible for calling 
debug_hooks->global_decl, then we must set DECL_IGNORED_P correctly by 
that point.  (That assume that, in fact, we should not put out debugging 
information about variables that have been optimized away; I think that 
assumption is correct in that we might otherwise get relocations against 
them, at least in some debugging formats.)

But, the way things are set up, we apparently don't really know whether 
or not we're going to output the variables until cgraph_optimize, which 
is not called until later in c_write_global_declarations.

That suggests that perhaps the correct fix is to move the call to 
debug_hooks->global_decl into cgraph, or have it in both places.  Or, 
perhaps cgraph_optimize should be called before check_global_declarations.

In fact, the C++ front end calls cgraph_optimize before
check_global_declarations, so it's at least possible to make the calls in that
order.  It's possible that we miss some warnings or something that way, if
cgraph_optimize destroys information that we need -- but it's apparently not a
total disaster.

Indeed, this patch seems to fix the problem.  (Untested as of yet, beyond
running the debug.exp tests and the original testcase.)

Joseph, Richard, any thoughts on the appropriateness of this for the C front end?

Index: c-decl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-decl.c,v
retrieving revision 1.660
diff -c -5 -p -r1.660 c-decl.c
*** c-decl.c    28 May 2005 01:38:08 -0000      1.660
--- c-decl.c    6 Jun 2005 00:46:03 -0000
*************** c_write_global_declarations (void)
*** 7548,7570 ****
    /* Close the external scope.  */
    ext_block = pop_scope ();
    external_scope = 0;
    gcc_assert (!current_scope);

-   /* Process all file scopes in this compilation, and the external_scope,
-      through wrapup_global_declarations and check_global_declarations.  */
-   for (t = all_translation_units; t; t = TREE_CHAIN (t))
-     c_write_global_declarations_1 (BLOCK_VARS (DECL_INITIAL (t)));
-   c_write_global_declarations_1 (BLOCK_VARS (ext_block));
-
    /* Generate functions to call static constructors and destructors
       for targets that do not support .ctors/.dtors sections.  These
       functions have magic names which are detected by collect2.  */
    build_cdtor ('I', static_ctors); static_ctors = 0;
    build_cdtor ('D', static_dtors); static_dtors = 0;

    /* We're done parsing; proceed to optimize and emit assembly.
       FIXME: shouldn't be the front end's responsibility to call this.  */
    cgraph_optimize ();
  }

  #include "gt-c-decl.h"
--- 7548,7570 ----
    /* Close the external scope.  */
    ext_block = pop_scope ();
    external_scope = 0;
    gcc_assert (!current_scope);

    /* Generate functions to call static constructors and destructors
       for targets that do not support .ctors/.dtors sections.  These
       functions have magic names which are detected by collect2.  */
    build_cdtor ('I', static_ctors); static_ctors = 0;
    build_cdtor ('D', static_dtors); static_dtors = 0;

    /* We're done parsing; proceed to optimize and emit assembly.
       FIXME: shouldn't be the front end's responsibility to call this.  */
    cgraph_optimize ();
+
+   /* Process all file scopes in this compilation, and the external_scope,
+      through wrapup_global_declarations and check_global_declarations.  */
+   for (t = all_translation_units; t; t = TREE_CHAIN (t))
+     c_write_global_declarations_1 (BLOCK_VARS (DECL_INITIAL (t)));
+   c_write_global_declarations_1 (BLOCK_VARS (ext_block));
  }

  #include "gt-c-decl.h"

Created attachment 9195 [details]
Move the c_write_global_declarations_1 calls after cgraph_optimize.

This is an attempt to try Mark's suggested patch.  Mark's patch does not work
as is, because cgraph_optimize does a garbage collect, and ext_block is an
unregistered root.  This problem shows up while doing a C only bootstrap.  I
made ext_block a file-scope static, and added a GTY marker and retried.  Now it
passes a C only bootstrap, but I got 5 extra testsuite failures.
FAIL: gcc.dg/c90-static-1.c  (test for errors, line 13)
FAIL: gcc.dg/c90-static-1.c  (test for errors, line 17)
FAIL: gcc.dg/c99-static-1.c  (test for errors, line 14)
FAIL: gcc.dg/c99-static-1.c  (test for errors, line 18)
FAIL: gcc.dg/varpool-1.c scan-assembler-not
unnecesary_static_initialized_variable

The first 4 fail because cgraph_optimize sets DECL_INITIAL to error_mark_node
for functions we won't emit, which breaks the DECL_INITIAL == 0 semantic check
in c_write_global_declarations_1.  That can perhaps be fixed by changing the
latter to also check for error_mark_node, but that could lead to misleading
error messages when there are previous errors in the program.

The last one fails because cgraph_optimize is not able to eliminate a static
variable used by an inline function.  For this one, I am not sure what went
wrong.	My impression is that it will be harder to fix or work around, so I
haven't tried to debug it.

Having looked at this a bit now, I am inclined to think that Mark's patch for
18556 is the wrong approach.  Mark suggested that we should not emit debug info
for variables that have been optimized away.  However, debug info is supposed
to be a representation of the source code, not the object file.  So if a
variable is optimized away, there should still be debug info for it, saying
that it has been optimized away.  Unless of course the user asks for this debug
info to be eliminated, e.g. -feliminate-unused-debug-symbols.  So I am thinking
that the real problem for 18556 is somewhere in the debugging output routines. 
This is what I will be looking at next when time permits, i.e. trying to
reproduce 18556 and seeing if I can find a bug in the debugging output code.

*** Bug 22295 has been marked as a duplicate of this bug. ***

Gcc Red Hat 4.0.0-8 seems OK. Does Red Hat have a fix on gcc-4_0-rhl-branch?
This bug makes it very hard to debug binaries generated by gcc 4.0.

I checked the current gcc-4_0-rhl-branch in CVS. It has the same problem.
Can we revisit bug 18556? I can test both.

Created attachment 9201 [details]
A patch to generate debug info for common symbol

The problem seems that gcc failed to emit debug info for common symbols. I
am testing this patch on Linux/ia32/x86-64/ia64.

My patch doesn't handle uninitiliazed local variables correctly. The difference
between C and C++ is C++ writes out variables first.

Created attachment 9202 [details]
A patch to generate debug info for uninitialized symbol

I am testing this patch now.

My patch doesn't work with gcc.dg/varpool-1.c. c_write_global_declarations
seems calling check_global_declarations and cgraph_optimize in the wrong
order. Shouldn't check_global_declarations be called after cgraph_optimize
instead of before?

Patches for mainline and 4.0 are posted at

http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00270.html

I hope they lead to the proper fixes and this critical regression
is fixed in 4.0.1.

Subject: Re:  [4.0/4.1 Regression] debug info omitted for
 uninitialized variables

hjl at lucon dot org wrote:
> ------- Additional Comments From hjl at lucon dot org  2005-07-05 16:56 -------
> Patches for mainline and 4.0 are posted at
> http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00270.html
> I hope they lead to the proper fixes and this critical regression
> is fixed in 4.0.1.

I think you are just compounding the mistake created by Mark Mitchell's 
patch for PR 18556.  I mentioned this in comment #8, which unfortunately 
didn't get sent to the gcc-bugs mailing list.

Subject: Re:  [4.0/4.1 Regression] debug info omitted for
 uninitialized variables

wilson at specifix dot com wrote:

> I think you are just compounding the mistake created by Mark Mitchell's 
> patch for PR 18556.  I mentioned this in comment #8, which unfortunately 
> didn't get sent to the gcc-bugs mailing list.

I agree that, in the abstract, the debug information should match the 
source program.  However, the problem was that we generated debug 
information that referenced a non-existant symbol, which is clearly a 
major problem.  I'm not sure why the debug generator did that; perhaps 
that's the real bug, as you suggest.

My change essentially restored the behavior of check_global_declarations 
to its historical state; clearing DECL_RTL (as this code used to do) was 
essentially supposed to turn off generation of debugging information for 
the variable.  If information was still emitted, that was somewhat by 
accident, judging by the comment there.

Since this bug does not affect the C++ front end, it's clear that it's 
possible to write a front end in which things work as expected.

So, there would be seem to be two ways to potential ways to fix things: 
(1) change the debug generators, as you suggest; (2) change the C front end.

I'd be happy to help with either approach; this is certainly my fault, 
independently of where the fix lies.  However, as you've volunteered to 
look at the debug generators, I'm going to leave this bug aside until 
you report back.  If you don't have time to look soon, would you please 
let me know?

Thanks,

No activity in last few days. Mark, would it be possible for you to take a look at this again! Thank you.

I have done a binary search and at least for the failures and at least those
problems mentioned in PR c++/18556 are fixed by PR middle-end/17799 without
the need for PR c++/18556 patch.
Now, the question is I think if there is a testcase that still needs
PR c++/18556 patch.  If not, at least for gcc-4_0-branch IMHO the easiest
would be simply to revert that patch.  If yes, but it is C++ only and there
can't be a case when something like that is needed in C, a quick fix would be
      /* Do not emit debug information about variables that are in
         static storage, but not defined.  */
      if (TREE_CODE (decl) == VAR_DECL
+         && (cgraph_global_info_ready || !flag_unit_at_a_time)
          && TREE_STATIC (decl)
          && !TREE_ASM_WRITTEN (decl))
        DECL_IGNORED_P (decl) = 1;
so we would not force no debugging for a var decl that has not been written,
unless cgraph_optimize has been called already or -fno-unit-at-a-time.

Subject: Re:  [4.0/4.1 Regression] debug info omitted for
 uninitialized variables

jakub at redhat dot com wrote:
> ------- Additional Comments From jakub at redhat dot com  2005-07-20 11:41 -------
> I have done a binary search and at least for the failures and at least those
> problems mentioned in PR c++/18556 are fixed by PR middle-end/17799 without
> the need for PR c++/18556 patch.
> Now, the question is I think if there is a testcase that still needs
> PR c++/18556 patch.  If not, at least for gcc-4_0-branch IMHO the easiest
> would be simply to revert that patch.  If yes, but it is C++ only and there
> can't be a case when something like that is needed in C, a quick fix would be
>       /* Do not emit debug information about variables that are in
>          static storage, but not defined.  */
>       if (TREE_CODE (decl) == VAR_DECL
> +         && (cgraph_global_info_ready || !flag_unit_at_a_time)
>           && TREE_STATIC (decl)
>           && !TREE_ASM_WRITTEN (decl))
>         DECL_IGNORED_P (decl) = 1;
> so we would not force no debugging for a var decl that has not been written,
> unless cgraph_optimize has been called already or -fno-unit-at-a-time.

I will look at this in more detail today.  Thanks!

Jakub --

Thank you for finding the patch that fixed this problem.  

Richard's patch changed things to mark the problematic variable as
DECL_IGNORED_P earlier, so my patch is no longer necessary.

As for Jim's comments about matching the source, the variable is also
DECL_ARTIFICIAL, so perhaps its reasonable to assume that the user doesn't care
about it.

I will try a test run with my patch reverted; if that passes, and still fixes
the bug in this PR, I will check in.

Thanks!

-- Mark

Subject: Re:  [4.0/4.1 Regression] debug info omitted for
 uninitialized variables

mmitchel at gcc dot gnu dot org wrote:

> I will try a test run with my patch reverted; if that passes, and still fixes
> the bug in this PR, I will check in.

Unfortunately, it failed -- gcc.dg/pch/global-1.c fails at -O3.

I have not yet figured out why...

Subject: Re:  [4.0/4.1 Regression] debug info omitted for
 uninitialized variables

mark at codesourcery dot com wrote:

> Unfortunately, it failed -- gcc.dg/pch/global-1.c fails at -O3.
> 
> I have not yet figured out why...

This has to do with the fact that first_global_object_name and 
weak_global_object_name are not preserved across PCH; this looks to be a 
bug latent since the introduction of PCH.  Working on fixing that now...

Subject: Bug 21828

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2005-07-22 17:40:37

Modified files:
	gcc            : ChangeLog toplev.c varasm.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.dg/debug/dwarf2: dwarf-uninit.c 

Log message:
	PR debug/21828
	* toplev.c (check_global_declarations): Do not mark undefined
	variables as DECL_IGNORED_P.
	* varasm.c (first_global_object_name): GTY it.
	(weak_global_object_name): Likewise.
	(notice_global_symbol): Use ggc_strdup, not xstrdup, when creating
	a string to go into {weak,first}_global_object_name.
	
	PR debug/21828
	* gcc.dg/debug/dwarf2/dwarf-uninit.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9521&r2=2.9522
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?cvsroot=gcc&r1=1.972&r2=1.973
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.521&r2=1.522
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5802&r2=1.5803
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-uninit.c.diff?cvsroot=gcc&r1=NONE&r2=1.1

Subject: Bug 21828

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	mmitchel@gcc.gnu.org	2005-07-22 19:33:16

Modified files:
	gcc            : ChangeLog toplev.c varasm.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.dg/debug/dwarf2: dwarf-uninit.c 

Log message:
	PR debug/21828
	* toplev.c (check_global_declarations): Do not mark undefined
	variables as DECL_IGNORED_P.
	* varasm.c (first_global_object_name): GTY it.
	(weak_global_object_name): Likewise.
	(notice_global_symbol): Use ggc_strdup, not xstrdup, when creating
	a string to go into {weak,first}_global_object_name.
	
	PR debug/21828
	* gcc.dg/debug/dwarf2/dwarf-uninit.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.327&r2=2.7592.2.328
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.944.2.4&r2=1.944.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.477.6.12&r2=1.477.6.13
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.293&r2=1.5084.2.294
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-uninit.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1

Fixed in 4.0.2.

Mark, your patch caused bug 18556 to fail on Linux/ia64 again.

Subject: Re:  [4.0 Regression] debug info omitted for uninitialized
 variables

hjl at lucon dot org wrote:
> ------- Additional Comments From hjl at lucon dot org  2005-07-22 20:44 -------
> Mark, your patch caused bug 18556 to fail on Linux/ia64 again.

HJ --

Please reclose 21828.  Other bugs coming back have nothing to do with 21828.

I am closing it now. Since bug 21828 and bug 18556 are closely related, how
can we make sure that fixing one won't break the other? Should I open a new
meta bug?

Subject: Re:  [4.0 Regression] debug info omitted for uninitialized
 variables

hjl at lucon dot org wrote:
> ------- Additional Comments From hjl at lucon dot org  2005-07-22 20:53 -------
> I am closing it now. Since bug 21828 and bug 18556 are closely related, how
> can we make sure that fixing one won't break the other? Should I open a new
> meta bug?

I don't think that's necessary.

There are already lots of pointers back and forth, and I tested the 
eh53.C test case in developing the fix for PR 21828.

Subject: Re:  [4.0 Regression] debug info omitted for uninitialized variables


On Jul 22, 2005, at 12:33 PM, cvs-commit at gcc dot gnu dot org wrote:

>
> ------- Additional Comments From cvs-commit at gcc dot gnu dot org   
> 2005-07-22 19:33 -------
> Subject: Bug 21828
>
> CVSROOT:    /cvs/gcc
> Module name:    gcc
> Branch:     gcc-4_0-branch
> Changes by:    mmitchel@gcc.gnu.org    2005-07-22 19:33:16
>
> Modified files:
>     gcc            : ChangeLog toplev.c varasm.c
>     gcc/testsuite  : ChangeLog
> Added files:
>     gcc/testsuite/gcc.dg/debug/dwarf2: dwarf-uninit.c
>
> Log message:
>     PR debug/21828
>     * toplev.c (check_global_declarations): Do not mark undefined
>     variables as DECL_IGNORED_P.
>     * varasm.c (first_global_object_name): GTY it.
>     (weak_global_object_name): Likewise.
>     (notice_global_symbol): Use ggc_strdup, not xstrdup, when creating
>     a string to go into {weak,first}_global_object_name.
>
>     PR debug/21828
>     * gcc.dg/debug/dwarf2/dwarf-uninit.c: New test.
>
> Patches:
> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff? 
> cvsroot=gcc&only_with_tag=gcc-4_0- 
> branch&r1=2.7592.2.327&r2=2.7592.2.328
> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff? 
> cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.944.2.4&r2=1.944.2.5
> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff? 
> cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.477.6.12&r2=1.477.6.13
> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ 
> ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0- 
> branch&r1=1.5084.2.293&r2=1.5084.2.294
> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/ 
> debug/dwarf2/dwarf-uninit.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0- 
> branch&r1=NONE&r2=1.1.2.1
>

After this check-in :

$ cat t.c
static int foo;
int bar;
int main(void)
{
   foo += 3;
   bar *= 5;
   return 0;
}

$ xgcc -g  -O2 -o t t.c
$ cat gdbcmds
b main
ptype foo
ptype bar
p foo
p bar
$ gdb --batch -x gdbcmds t
Reading symbols for shared libraries ... done
Breakpoint 1 at 0x2d14: file t.c, line 6.
type = <unknown type>
type = <unknown type>
$1 = <unknown type>
$2 = <unknown type>

This is on powerpc-darwin. I expected this patch to fix this. Am I  
missing something ?

Thanks,
-
Devang

Subject: Re:  [4.0 Regression] debug info omitted for uninitialized
 variables

Devang Patel wrote:
>
> $ gdb --batch -x gdbcmds t
> Reading symbols for shared libraries ... done
> Breakpoint 1 at 0x2d14: file t.c, line 6.
> type = <unknown type>
> type = <unknown type>
> $1 = <unknown type>
> $2 = <unknown type>
> 
> This is on powerpc-darwin. I expected this patch to fix this. Am I  
> missing something ?

First, your example was not the one in the original bug report.

Second, you're using STABS, not DWARF-2.  I suspect the stabs debug 
generator, or the GDB stabs reader is not as good as DWARF.

On GNU/Linux, GDB knows that "bar" has type "int".  It still doesn't 
know the type of "foo"; apparently too much of the debug information is 
optimized away.  But, that's some other problem -- perhaps in GDB 
itself.  The information is clearly there for it:

         .uleb128 0x2    # (DIE (0x2d) DW_TAG_variable)
         .ascii "foo\0"  # DW_AT_name
         .byte   0x1     # DW_AT_decl_file
         .byte   0x1     # DW_AT_decl_line
         .long   0x38    # DW_AT_type
         .uleb128 0x3    # (DIE (0x38) DW_TAG_base_type)
         .ascii "int\0"  # DW_AT_name
         .byte   0x4     # DW_AT_byte_size
         .byte   0x5     # DW_AT_encoding