[Bug c/47966] New: GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.
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: unassig...@gcc.gnu.org
ReportedBy: joni...@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 .bss0004 var1
0804a024 l O .bss0004 var2
0804a014 l O .data0004 var3
27 LCSYM 0 0 0804a020 719var1:S(0,1)
28 STSYM 0 0 0804a024 731var2:S(0,1)# BUG: Must be LCSYM
29 STSYM 0 0 0804a014 743var3: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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47966 --- Comment #1 from Dainis Jonitis 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47966 --- Comment #2 from Dainis Jonitis 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47966 --- Comment #3 from Dainis Jonitis 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47966 --- Comment #4 from Dainis Jonitis 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47966 --- Comment #6 from Dainis Jonitis 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47966 --- Comment #7 from Dainis Jonitis 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47966 --- Comment #9 from Dainis Jonitis 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47966
--- Comment #10 from Dainis Jonitis 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 .data0004 fvar3.1259
0804a034 l O .bss0004 fvar2.1258
0804a038 l O .bss0004 fvar1.1257
29 LCSYM 0 0 0804a038 719fvar1:V(0,1)
30 STSYM 0 0 0804a034 732fvar2:V(0,1) // BUG: Must be LCSYM
31 STSYM 0 0 0804a01c 745fvar3:V(0,1)
