public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/46072] New: AIX linker chokes on debug info for uninitialized static variables
@ 2010-10-18 18:49 skunk at iskunk dot org
  2010-10-19 21:51 ` [Bug target/46072] " skunk at iskunk dot org
                   ` (37 more replies)
  0 siblings, 38 replies; 39+ messages in thread
From: skunk at iskunk dot org @ 2010-10-18 18:49 UTC (permalink / raw)
  To: gcc-bugs

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: unassigned@gcc.gnu.org
        ReportedBy: skunk@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.


^ permalink raw reply	[flat|nested] 39+ messages in thread
end of thread, other threads:[~2014-02-16 10:01 UTC | newest]

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-18 18:49 [Bug debug/46072] New: AIX linker chokes on debug info for uninitialized static variables skunk at iskunk dot org
2010-10-19 21:51 ` [Bug target/46072] " skunk at iskunk dot org
2010-11-10 13:02 ` ppryor63 at gmail dot com
2011-01-25  9:28 ` michael.haubenwallner at salomon dot at
2011-01-25 13:17 ` michael.haubenwallner at salomon dot at
2011-01-25 16:23 ` michael.haubenwallner at salomon dot at
2011-02-09  9:16 ` michael.haubenwallner at salomon dot at
2011-02-24  2:21 ` pedzsan at gmail dot com
2011-03-18 17:15 ` pedzsan at gmail dot com
2011-03-18 18:57 ` skunk at iskunk dot org
2011-03-18 19:04 ` pedzsan at gmail dot com
2011-03-23  9:05 ` michael.haubenwallner at salomon dot at
2011-03-23 11:06 ` david.kirkby at onetel dot net
2011-03-23 14:53 ` pedzsan at gmail dot com
2011-03-23 17:20 ` david.kirkby at onetel dot net
2011-03-23 19:45 ` pedzsan at gmail dot com
2011-03-24 14:01 ` david.kirkby at onetel dot net
2011-04-06  8:36 ` rockdreamer at gmail dot com
2011-04-07  7:59 ` michael.haubenwallner at salomon dot at
2011-04-07 12:55 ` pedzsan at gmail dot com
2011-04-07 17:15 ` david.kirkby at onetel dot net
2011-04-08  7:54 ` michael.haubenwallner at salomon dot at
2011-04-08 19:56 ` ppryor63 at gmail dot com
2011-04-08 21:31 ` david.kirkby at onetel dot net
2011-04-12  2:38 ` david.kirkby at onetel dot net
2011-05-17 14:41 ` dje at gcc dot gnu.org
2011-05-17 15:12 ` michael.haubenwallner at salomon dot at
2011-05-17 15:41 ` david.kirkby at onetel dot net
2011-05-17 18:34 ` skunk at iskunk dot org
2011-05-18  0:49 ` ppryor63 at gmail dot com
2011-05-18  1:37 ` skunk at iskunk dot org
2011-05-20  8:19 ` mrgcc at mailinator dot com
2011-09-15  8:33 ` vovata at gmail dot com
2011-09-15  8:45 ` vovata at gmail dot com
2011-09-15 14:07 ` skunk at iskunk dot org
2011-09-15 14:17 ` vovata at gmail dot com
2012-04-12 16:31 ` skunk at iskunk dot org
2012-04-16 13:31 ` michael.haubenwallner at salomon dot at
2014-02-16 10:01 ` jackie.rosen at hushmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).