[Bug c/47966] New: GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[Bug c/47966] New: GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

           Summary: GCC 3.4.6 and 4.4.3 generate wrong stabs debugging
                    information for global variables explicitly
                    initialized with 0.
           Product: gcc
           Version: 4.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jonitis@gmail.com


extern int printf (const char *, ...);

static int var1;
static int var2 = 0;
static int var3 = 1;

int
main(int argc, char *argv[])
{
        printf("v1=%d v2=%d v3=%d\n", var1, var2, var3);

        return 0;
}

Old compiler 2.95.2 was putting var1 in .bss section and both var2 and var3 in
.data section. 

GCC 3.4.6 is smarter and puts var2 in .bss section, but seems forgot to update
generation of debugging information. For var2 it generates:
  .stabs "var2:S1",38,0,4,_var2
where 38=0x26=N_STSYM - data segment variable. It have to be 40=0x28=N_LCSYM.

objdump confirms wrong debbugging info.

0804a020 l     O .bss    00000004              var1
0804a024 l     O .bss    00000004              var2
0804a014 l     O .data    00000004              var3 
27     LCSYM  0      0      0804a020 719    var1:S(0,1)
28     STSYM  0      0      0804a024 731    var2:S(0,1)    # BUG: Must be LCSYM
29     STSYM  0      0      0804a014 743    var3:S(0,1) 

When I use gcc with -S switch to generate .s assembler file and then manually
fix the .stab from 38 to 40 to say that it is in .bss section then everything
works fine in our GDB 6.8 (proprietary FreeBSD based system).

I've also verified on Ubuntu 10.04 gcc 4.4.3-4ubuntu5 that this bug is still
present. I had no chance to verify anything newer than 4.4.3


Seems that GDB 6.8 for ELF format is smart enough and does ignore the wrong
address that debug symbols provide. 

On our platform for A.OUT format files the GDB 6.8 is confused by wrong
debugging information and tries to get variable information from some bogus
address in .data section. We will have to patch our GDB to trust the symbol
table more than debugging information. Ideally GCC also will be changed.

[Bug c/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #1 from Dainis Jonitis <jonitis at gmail dot com> 2011-03-03 10:21:03 UTC ---
Created attachment 23522
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23522
GCC generated wrong assembler file

[Bug c/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #2 from Dainis Jonitis <jonitis at gmail dot com> 2011-03-03 10:21:44 UTC ---
Created attachment 23523
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23523
nm utility output

[Bug c/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #3 from Dainis Jonitis <jonitis at gmail dot com> 2011-03-03 10:22:33 UTC ---
Created attachment 23524
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23524
objdump utility output with wrong N_LCSYM debugging information

[Bug c/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #4 from Dainis Jonitis <jonitis at gmail dot com> 2011-03-03 10:22:57 UTC ---
Created attachment 23525
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23525
makefile

[Bug debug/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-debug
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.03.03 10:43:15
          Component|c                           |debug
     Ever Confirmed|0                           |1

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-03 10:43:15 UTC ---
Probably nobody will care, there are nearly no stabs users left.

Well, confirmed anyway.

[Bug debug/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #6 from Dainis Jonitis <jonitis at gmail dot com> 2011-03-03 14:40:18 UTC ---
Problem is actually only with static file scope variables. Only then the
N_LCSYM and N_STSYM stabs are used. With global variables there is no problem
as N_GSYM stab is used instead.

[Bug debug/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for static file scope variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #7 from Dainis Jonitis <jonitis at gmail dot com> 2011-03-03 15:44:04 UTC ---
Everything works fine in Ubuntu GDB, because the Assembler (2.20.1) is smart
enough to ignore wrong debug symbols and still generate correct object file
with correct addresses in stabs that match symbol table addresses. 

It fails on our system because we use prehistoric assembler 1.92.3 that is
confused by wrong debug symbols and produces the wrong stab addresses in object
file.

[Bug debug/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for static file scope variables explicitly initialized with 0.

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-03-03 17:42:53 UTC ---
IIRC a.out format support for freebsd has just been depercated.  Why use stabs
at all?  Elf and dwarf2 have been around for at least 10 years now and actually
make sense for 90% of the world; doesn't it make sense to update to using elf? 
Somethings will never work in a.out (or a.outb).

[Bug debug/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for static file scope variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #9 from Dainis Jonitis <jonitis at gmail dot com> 2011-03-04 07:48:45 UTC ---
Unfortunately in legacy embedded systems it is not so easy to change toolchain.
We switched from GCC 2.95.2 to 3.4.6 as the last one that supports a.out
format. For us switching to ELF requires too much effort without any
significant gains.

As a workaround I've changed our GDB 6.8 to always trust symbol table more than
debugging information. So this reduces number of affected persons to 0 :)

If I will have time I may look in GCC source code and possibly produce a patch.

[Bug debug/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for static file or function scope variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #10 from Dainis Jonitis <jonitis at gmail dot com> 2011-03-04 14:55:56 UTC ---
Actually the same problem is with function scope static variables.

int
main(int argc, char *argv[])
{
    static int fvar1;
    static int fvar2 = 0;
    static int fvar3 = 1;

        return 0;
}

0804a01c l     O .data    00000004              fvar3.1259
0804a034 l     O .bss    00000004              fvar2.1258
0804a038 l     O .bss    00000004              fvar1.1257 
29     LCSYM  0      0      0804a038 719    fvar1:V(0,1)
30     STSYM  0      0      0804a034 732    fvar2:V(0,1) // BUG: Must be LCSYM
31     STSYM  0      0      0804a01c 745    fvar3:V(0,1)

[Bug debug/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for static file or function scope variables explicitly initialized with 0.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47966

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |13.0

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> Probably nobody will care, there are nearly no stabs users left.

And 11 years later, it was removed by r13-2361-g7e0db0cdf01e9c .  So closing as
won't fix.