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 .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.
