http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
Summary: AIX linker chokes on debug info for uninitialized
static variables
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
Host: powerpc-ibm-aix5.3.0.0
Target: powerpc-ibm-aix5.3.0.0
Build: powerpc-ibm-aix5.3.0.0
Created attachment 22082
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22082
Tarball containing a minimal test case
GCC 4.5.1 has worked fine on this AIX 5.3 system for some time. The system had
not been kept up-to-date with IBM system patches, however one day we found
these to be needed (to allow a 64-bit Java install), and so installed about
three years' worth of updates over the course of a few days.
After the first couple of updates, we noticed that debug-enabled builds of our
C software began to fail with this error message:
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 12) in object foo.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
collect2: ld returned 12 exit status
I've dug into this, and believe I have found what's going on. Attached is a
tarball containing a minimal test case.
The minimal test case has a target which triggers the bug (try-1), a target
which does not (try-2), a target to compile to assembly, and a "clean" target.
Note that it was written on a 64-bit AIX system, hence the use of -maix64, but
the bug also seems to occur in 32-bit mode.
The problem is triggered when debugging information is generated for a variable
declared as "static" (whether inside or outside a function). Here is an excerpt
from the assembly produced by the minimal test case:
FE..main:
.bs _foo.bss_
.stabx "my_uninit:S-1",my_uninit,133,0
.es
.bs _foo.rw_[RW]
.stabx "my_init:S-1",my_init,133,0
.es
(my_init is a static variable initialized with a value; my_uninit is
uninitialized.)
My understanding is that .bs is a C_BSTAT declaration, which indicates the
section in which the following variable resides. The section that it references
must be declared by a .csect directive. If we do some grepping, something
interesting comes out:
$ fgrep -n _foo.rw_ foo.s
2: .csect _foo.rw_[RW],4
43: .bs _foo.rw_[RW]
$ fgrep -n _foo.bss_ foo.s
6: .lcomm my_uninit,16,_foo.bss_
7: .lcomm my_init,16,_foo.bss_
40: .bs _foo.bss_
_foo.bss_ has no .csect declaration, and this is presumably what the linker is
complaining about. The same assembly was accepted before, so I'm guessing the
system updates brought with it stricter linking semantics.
Incidentally, this system also has an older version of GCC (2.9-aix51-020209),
and it yields the same error from the minimal test case.
