[Bug debug/46072] New: AIX linker chokes on debug info for uninitialized static variables

[Bug debug/46072] New: AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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

--- Comment #1 from Daniel Richard G. <skunk at iskunk dot org> 2010-10-19 21:51:44 UTC ---
I'd like to add: We've been able to work around this issue in our C codebase
simply by ensuring that every static variable is initialized with a value. The
bug behavior makes the uninitialized ones easy to track down as a matter of
course.

However, we can't do the same for our C++ codebase. There is at least one
static declaration (std::__ioinit) in the C++ header files that we can't touch,
so unless we turn off debug information altogether, there's not much of a way
to avoid the linker error.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[ppryor63 at gmail dot com]

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

Paul Pryor <ppryor63 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppryor63 at gmail dot com

--- Comment #2 from Paul Pryor <ppryor63 at gmail dot com> 2010-11-10 13:01:48 UTC ---
I encountered the same problem in AIX 5.3 on both boxes that were patched to
5300-12-02-1036 recently. If you need any more information please contact me. I
am attaching all diagnostic information below.

-------

$ oslevel -s
5300-12-02-1036

-------

$ ls -l /usr/bin/ld
lrwxrwxrwx    1 bin      bin              15 Jun 10 2009  /usr/bin/ld ->
/usr/ccs/bin/ld
$ ls -l /usr/ccs/bin/ld
-r-xr-xr-x    1 bin      bin           38942 Aug 06 17:05 /usr/ccs/bin/ld
$ lslpp -w /usr/ccs/bin/ld
  File                                        Fileset               Type
  ----------------------------------------------------------------------------
  /usr/ccs/bin/ld                             bos.rte.bind_cmds     File
$ lslpp -h bos.rte.bind_cmds
  Fileset         Level     Action       Status       Date         Time
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  bos.rte.bind_cmds
                 5.3.0.40   COMMIT       COMPLETE     06/10/09     16:01:41
                  5.3.9.1   COMMIT       COMPLETE     06/10/09     17:42:02
                 5.3.12.1   COMMIT       COMPLETE     11/05/10     06:37:14
$ lslpp -i bos.rte.bind_cmds
                        Vendor
  Fileset               Code    Product Id  Feature Id  Package Name
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  bos.rte.bind_cmds 5.3.0.40
                                5765-E6200  0000        bos
-------

$ cat static.c
static int flag1;
static int flag2 = 0;

int main(int arg, char *argv[])
{
  printf("flag1:%d flag2:%d\n", flag1, flag2);
  return 0;
}
$ gcc -v
Reading specs from /opt/freeware/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/specs
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--disable-nls --enable-languages=c,c++ --prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs --host=powerpc-ibm-aix5.2.0.0
Thread model: aix
gcc version 3.3.2
$ gcc -g -o static static.c
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 24) in object
/tmp//cc6ul6xe.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
$ gcc -o static static.c
$ ./static
flag1:0 flag2:0

-------

$ cat static.c
#include <stdio.h>

static int flag1;
static int flag2 = 0;

int main(int argc, char *argv[])
{
  printf("flag1:%d flag2:%d\n", flag1, flag2);
  return 0;
}

$ gcc -v
Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--enable-languages=c,c++,java --prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs --host=powerpc-ibm-aix5.3.0.0
--target=powerpc-ibm-aix5.3.0.0 --build=powerpc-ibm-aix5.3.0.0
--disable-libjava-multilib
Thread model: aix
gcc version 4.2.0

$ gcc -g -o static static.c
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 259) in object
/tmp//cccd0Shv.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
$ gcc -o static static.c
$ ./static
flag1:0 flag2:0

-------

$ cat static.c
#include <stdio.h>

static int flag1;
static int flag2 = 0;

int main(int argc, char *argv[])
{
  printf("flag1:%d flag2:%d\n", flag1, flag2);
  return 0;
}

$ xlc -g -o static static.c
$ ./static
flag1:0 flag2:0

-------

$ cat static.c
static int flag1;
static int flag2 = 0;

int main(int arg, char *argv[])
{
  printf("flag1:%d flag2:%d\n", flag1, flag2);
  return 0;
}

$ gcc -v
Reading specs from /opt/freeware/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/specs
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--disable-nls --enable-languages=c,c++ --prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs --host=powerpc-ibm-aix5.2.0.0
Thread model: aix
gcc version 3.3.2

$ gcc -g -S static.c

$ cat static.s
        .file   "static.c"
        .toc
        .csect _static.rw_c[RW],3
        .csect .text[PR]
        .stabx 
"__int128_t:t1=@s128;r1;000000000000000000000000;0377777777777777777777777777777777;",0,140,0
        .stabx 
"__uint128_t:t2=@s128;r2;000000000000000000000000;0377777777777777777777777777777777;",0,140,0
        .stabx  "complex int:t3=s8real:-1,0,32;imag:-1,32,32;;",0,140,0
        .stabx  "complex float:t4=R3;8;0;",0,140,0
        .stabx  "complex double:t5=R4;16;0;",0,140,0
        .stabx  "complex long double:t6=R4;16;0;",0,140,0
        .stabx  "__builtin_va_list:t7=*-2",0,140,0
        .stabx  "_Bool:t8=@s8;-16;",0,140,0
        .lcomm flag2,4,_static.bss_c
        .csect _static.rw_c[RO],3
        .align 2
LC..0:
        .byte "flag1:%d flag2:%d"
        .byte 10, 0
        .toc
LC..1:
        .tc flag1[TC],flag1
LC..2:
        .tc flag2[TC],flag2
LC..3:
        .tc LC..0[TC],LC..0
        .csect .text[PR]
        .align 2
        .globl main
        .globl .main
        .csect main[DS]
main:
        .long .main, TOC[tc0], 0
        .csect .text[PR]
.main:
        .stabx  "main:F-1",.main,142,0
        .function .main,.main,16,044,FE..main-.main
        .bf     5
        .stabx  "arg:p-1",96,130,0
        .stabx  "argv:p9=*10=*-2",100,130,0
        .line   1
        mflr 0
        stw 31,-4(1)
        stw 0,8(1)
        stwu 1,-72(1)
        mr 31,1
        stw 3,96(31)
        stw 4,100(31)
        .line   2
        lwz 11,LC..1(2)
        lwz 9,LC..2(2)
        lwz 3,LC..3(2)
        lwz 4,0(11)
        lwz 5,0(9)
        bl .printf
        nop
        .line   3
        li 0,0
        .line   4
        mr 3,0
        lwz 1,0(1)
        lwz 0,8(1)
        mtlr 0
        lwz 31,-4(1)
        blr
        .ef     8
LT..main:
        .long 0
        .byte 0,0,32,97,128,1,2,1
        .long 0
        .long LT..main-.main
        .short 4
        .byte "main"
        .byte 31
        .align 2
FE..main:
        .lcomm flag1,4,_static.bss_c
        .bs     _static.bss_c
        .stabx  "flag1:S-1",flag1,133,0
        .es
        .bs     _static.rw_c[RW]
        .stabx  "flag2:S-1",flag2,133,0
        .es
_section_.text:
        .csect .data[RW],3
        .long _section_.text

-------

$ gcc -v
Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--enable-languages=c,c++,java --prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs --host=powerpc-ibm-aix5.3.0.0
--target=powerpc-ibm-aix5.3.0.0 --build=powerpc-ibm-aix5.3.0.0
--disable-libjava-multilib
Thread model: aix
gcc version 4.2.0

$ gcc -g -S static.c

$ cat static.s
        .file   "static.c"
        .csect _static.rw_[RW],3
        .csect .text[PR]
        .toc
        .csect .text[PR]
        .stabx  "_Decimal32:t1=r-1;4;0;",0,140,0
        .stabx  "_Decimal64:t2=r-1;8;0;",0,140,0
        .stabx  "_Decimal128:t3=r-1;16;0;",0,140,0
        .stabx  "__gnuc_va_list:t4=5=*-2",0,140,0
        .stabx  "size_t:t6=-10",0,140,0
        .stabx  "fpos_t:t7=-4",0,140,0
        .stabx  "fpos64_t:t8=-31",0,140,0
        .stabx 
"FILE:t9=10=s32_ptr:11=*-5,0,32;_cnt:-1,32,32;_base:11,64,32;_bufendp:11,96,32;_flag:-3,128,16;_file:-3,144,16;__stdioid:-1,160,32;__newbase:12=*-2,192,32;_lock:13=*-11,224,32;;",0,140,0
        .stabx  "va_list:t14=12",0,140,0
        .stabx  "int8_t:t15=-6",0,140,0
        .stabx  "int16_t:t16=-3",0,140,0
        .stabx  "int32_t:t17=-1",0,140,0
        .stabx  "int64_t:t18=-31",0,140,0
        .stabx  "uint8_t:t19=-5",0,140,0
        .stabx  "uint16_t:t20=-7",0,140,0
        .stabx  "uint32_t:t21=-8",0,140,0
        .stabx  "uint64_t:t22=-32",0,140,0
        .stabx  "intmax_t:t23=18",0,140,0
        .stabx  "uintmax_t:t24=22",0,140,0
        .stabx  "intptr_t:t25=-4",0,140,0
        .stabx  "uintptr_t:t26=-10",0,140,0
        .stabx  "int_least8_t:t27=-6",0,140,0
        .stabx  "int_least16_t:t28=-3",0,140,0
        .stabx  "int_least32_t:t29=-1",0,140,0
        .stabx  "int_least64_t:t30=-31",0,140,0
        .stabx  "uint_least8_t:t31=-5",0,140,0
        .stabx  "uint_least16_t:t32=-7",0,140,0
        .stabx  "uint_least32_t:t33=-8",0,140,0
        .stabx  "uint_least64_t:t34=-32",0,140,0
        .stabx  "int_fast8_t:t35=-6",0,140,0
        .stabx  "int_fast16_t:t36=16",0,140,0
        .stabx  "int_fast32_t:t37=17",0,140,0
        .stabx  "uint_fast8_t:t38=-5",0,140,0
        .stabx  "uint_fast16_t:t39=20",0,140,0
        .stabx  "uint_fast32_t:t40=21",0,140,0
        .stabx  "int_fast64_t:t41=18",0,140,0
        .stabx  "uint_fast64_t:t42=22",0,140,0
        .stabx  "imaxdiv_t:t43=44=s16quot:23,0,64;rem:23,64,64;;",0,140,0
        .align 2
        .lglobl .strtoimax
        .csect strtoimax[DS]
strtoimax:
        .long .strtoimax, TOC[tc0], 0
        .csect .text[PR]
.strtoimax:
        .bi     "/usr/include/sys/inttypes.h"
        .stabx  "strtoimax:f23",.strtoimax,142,0
        .function .strtoimax,.strtoimax,16,044,FE..strtoimax-.strtoimax
        .bf     67
        .stabx  "__nptr:p45=*46=k-2",104,130,0
        .stabx  "__endptr:p47=*12",108,130,0
        .stabx  "__base:p-1",112,130,0
        .line   1
        mflr 0
        stw 31,-4(1)
        stw 0,8(1)
        stwu 1,-80(1)
        mr 31,1
        stw 3,104(31)
        stw 4,108(31)
        stw 5,112(31)
        .line   2
        lwz 3,104(31)
        lwz 4,108(31)
        lwz 5,112(31)
        bl .__strtollmax
        nop
        mr 10,4
        mr 9,3
        .line   3
        mr 3,9
        mr 4,10
        lwz 1,0(1)
        lwz 0,8(1)
        mtlr 0
        lwz 31,-4(1)
        blr
        .ef     69
LT..strtoimax:
        .long 0
        .byte 0,0,32,97,128,1,3,1
        .long 0
        .long LT..strtoimax-.strtoimax
        .short 9
        .byte "strtoimax"
        .byte 31
        .align 2
FE..strtoimax:
        .stabx  "wchar_t:t48=-7",0,140,0
        .stabx  "intfast_t:t49=17",0,140,0
        .stabx  "uintfast_t:t50=21",0,140,0
        .stabx  "__long32_t:t51=-4",0,140,0
        .stabx  "__ulong32_t:t52=-10",0,140,0
        .stabx  "__long64_t:t53=-1",0,140,0
        .stabx  "__ulong64_t:t54=-8",0,140,0
        .stabx  "int32long64_t:t55=-1",0,140,0
        .stabx  "uint32long64_t:t56=-8",0,140,0
        .stabx  "long32int64_t:t57=-4",0,140,0
        .stabx  "ulong32int64_t:t58=-10",0,140,0
        .stabx  "int8:t59=-6",0,140,0
        .stabx  "int16:t60=-3",0,140,0
        .stabx  "int32:t61=-1",0,140,0
        .stabx  "int64:t62=-31",0,140,0
        .stabx  "u_int8:t63=-5",0,140,0
        .stabx  "u_int8_t:t64=-5",0,140,0
        .stabx  "u_int16:t65=-7",0,140,0
        .stabx  "u_int16_t:t66=-7",0,140,0
        .stabx  "u_int32:t67=-8",0,140,0
        .stabx  "u_int32_t:t68=-8",0,140,0
        .stabx  "u_int64:t69=-32",0,140,0
        .stabx  "u_int64_t:t70=-32",0,140,0
        .stabx  "ptrdiff_t:t71=-4",0,140,0
        .stabx  "wctype_t:t72=-8",0,140,0
        .stabx  "time_t:t73=-1",0,140,0
        .stabx  "clock_t:t74=-1",0,140,0
        .stabx  "uchar_t:t75=-5",0,140,0
        .stabx  "ushort_t:t76=-7",0,140,0
        .stabx  "uint_t:t77=-8",0,140,0
        .stabx  "ulong_t:t78=-10",0,140,0
        .stabx  "ssize_t:t79=-4",0,140,0
        .stabx  "level_t:t80=-1",0,140,0
        .stabx  "daddr_t:t81=53",0,140,0
        .stabx  "daddr32_t:t82=-1",0,140,0
        .stabx  "daddr64_t:t83=18",0,140,0
        .stabx  "caddr_t:t84=12",0,140,0
        .stabx  "ino_t:t85=54",0,140,0
        .stabx  "ino32_t:t86=77",0,140,0
        .stabx  "ino64_t:t87=22",0,140,0
        .stabx  "cnt_t:t88=-3",0,140,0
        .stabx  "dev_t:t89=54",0,140,0
        .stabx  "dev32_t:t90=77",0,140,0
        .stabx  "dev64_t:t91=22",0,140,0
        .stabx  "chan_t:t92=-1",0,140,0
        .stabx  "time32_t:t93=-1",0,140,0
        .stabx  "pid32_t:t94=-1",0,140,0
        .stabx  "tid32_t:t95=-1",0,140,0
        .stabx  "pid64_t:t96=22",0,140,0
        .stabx  "tid64_t:t97=22",0,140,0
        .stabx  "time64_t:t98=18",0,140,0
        .stabx  "__ptr32:t99=13",0,140,0
        .stabx  "__cptr32:t100=12",0,140,0
        .stabx  "soff_t:t101=-1",0,140,0
        .stabx  "off_t:t102=-4",0,140,0
        .stabx  "off64_t:t103=-31",0,140,0
        .stabx  "paddr_t:t104=-4",0,140,0
        .stabx  "key_t:t105=55",0,140,0
        .stabx  "timer_t:t106=53",0,140,0
        .stabx  "timer32_t:t107=-1",0,140,0
        .stabx  "timer64_t:t108=18",0,140,0
        .stabx  "nlink_t:t109=-3",0,140,0
        .stabx  "mode_t:t110=77",0,140,0
        .stabx  "uid_t:t111=77",0,140,0
        .stabx  "gid_t:t112=77",0,140,0
        .stabx  "mid_t:t113=99",0,140,0
        .stabx  "pid_t:t114=55",0,140,0
        .stabx  "tid_t:t115=53",0,140,0
        .stabx  "slab_t:t116=117=ar118=r118;0;037777777777;;0;11;-2",0,140,0
        .stabx  "mtyp_t:t119=-4",0,140,0
        .stabx  "boolean_t:t120=-1",0,140,0
        .stabx  "crid_t:t121=-1",0,140,0
        .stabx  "blkcnt_t:t122=53",0,140,0
        .stabx  "blksize_t:t123=53",0,140,0
        .stabx  "blkcnt32_t:t124=-1",0,140,0
        .stabx  "blksize32_t:t125=-1",0,140,0
        .stabx  "blkcnt64_t:t126=22",0,140,0
        .stabx  "blksize64_t:t127=22",0,140,0
        .stabx  "fsblkcnt_t:t128=78",0,140,0
        .stabx  "fsfilcnt_t:t129=78",0,140,0
        .stabx  "wint_t:t130=-1",0,140,0
        .stabx  "id_t:t131=56",0,140,0
        .stabx  "useconds_t:t132=-8",0,140,0
        .stabx  "suseconds_t:t133=-1",0,140,0
        .stabx  "clockid_t:t134=-31",0,140,0
        .stabx  "sigset_t:T135=s8losigs:-8,0,32;hisigs:-8,32,32;;",0,140,0
        .stabx  "sigset_t:t136=135",0,140,0
        .stabx 
"sigset32_t:t137=138=s8losigs:-8,0,32;hisigs:-8,32,32;;",0,140,0
        .stabx 
"sigset64_t:t139=140=s32ss_set:141=ar118;0;3;22,0,256;;",0,140,0
        .stabx  "signal_t:t142=-1",0,140,0
        .stabx  "fsid_t:T143=s8val:144=ar118;0;1;-8,0,64;;",0,140,0
        .stabx  "fsid_t:t145=143",0,140,0
        .stabx  "fsid64_t:T146=s16val:147=ar118;0;1;22,0,128;;",0,140,0
        .stabx  "fsid64_t:t148=146",0,140,0
        .stabx  "pthread_attr_t:t149=13",0,140,0
        .stabx  "pthread_condattr_t:t150=13",0,140,0
        .stabx  "pthread_mutexattr_t:t151=13",0,140,0
        .stabx  "pthread_rwlockattr_t:t152=13",0,140,0
        .stabx  "pthread_barrierattr_t:t153=13",0,140,0
        .stabx  "pthread_t:t154=-8",0,140,0
        .stabx  "pthread_key_t:t155=-8",0,140,0
        .stabx 
"pthread_mutex_t:t156=157=s52__mt_word:158=ar118;0;12;-1,0,416;;",0,140,0
        .stabx 
"pthread_cond_t:t159=160=s44__cv_word:161=ar118;0;10;-1,0,352;;",0,140,0
        .stabx 
"pthread_once_t:t162=163=s112__on_word:164=ar118;0;27;-1,0,896;;",0,140,0
        .stabx 
"pthread_spinlock_t:t165=166=s24__sp_word:167=ar118;0;5;-1,0,192;;",0,140,0
        .stabx 
"pthread_barrier_t:t168=169=s32__br_word:170=ar118;0;7;-1,0,256;;",0,140,0
        .stabx 
"pthread_rwlock_t:t171=172=s208__rw_word:173=ar118;0;51;-1,0,1664;;",0,140,0
        .stabx  "_quad:T174=s8val:175=ar118;0;1;-1,0,64;;",0,140,0
        .stabx  "quad:t176=174",0,140,0
        .stabx  "vmid_t:t177=-4",0,140,0
        .stabx  "vmhandle_t:t178=78",0,140,0
        .stabx  "vmid32_t:t179=-1",0,140,0
        .stabx  "vmhandle32_t:t180=77",0,140,0
        .stabx  "kvmid_t:t181=57",0,140,0
        .stabx  "kvmhandle_t:t182=58",0,140,0
        .stabx  "vmid64_t:t183=-31",0,140,0
        .stabx  "rpn64_t:t184=-31",0,140,0
        .stabx  "cnt64_t:t185=-31",0,140,0
        .stabx  "psize_t:t186=-31",0,140,0
        .stabx  "vmidx_t:t187=55",0,140,0
        .stabx  "vmfkey_t:t188=56",0,140,0
        .stabx  "vmprkey_t:t189=56",0,140,0
        .stabx  "vmkey_t:t190=55",0,140,0
        .stabx  "vmhwkey_t:t191=55",0,140,0
        .stabx  "vpn_t:t192=55",0,140,0
        .stabx  "rpn_t:t193=55",0,140,0
        .stabx  "ptex_t:t194=-10",0,140,0
        .stabx  "swhatx_t:t195=-10",0,140,0
        .stabx  "esid_t:t196=56",0,140,0
        .stabx  "aptx_t:t197=76",0,140,0
        .stabx  "pdtx_t:t198=-1",0,140,0
        .stabx  "psx_t:t199=-3",0,140,0
        .stabx  "pshift_t:t200=76",0,140,0
        .stabx  "sshift_t:t201=76",0,140,0
        .stabx  "unidx_t:t202=-1",0,140,0
        .stabx  "snidx_t:t203=-1",0,140,0
        .stabx  "vmnodeidx_t:t204=-1",0,140,0
        .stabx  "kvpn_t:t205=-1",0,140,0
        .stabx  "krpn_t:t206=-1",0,140,0
        .stabx  "vmsize_t:t207=55",0,140,0
        .stabx  "vmm_lock_t:t208=55",0,140,0
        .stabx  "ureg_t:t209=-10",0,140,0
        .stabx  "vmaddr_t:T210=s8srval:178,0,32;offset:84,32,32;;",0,140,0
        .stabx  "vmaddr_t:t211=210",0,140,0
        .stabx 
"adspace_t:T212=s68alloc:58,0,32;srval:213=ar118;0;15;178,32,512;;",0,140,0
        .stabx  "adspace_t:t214=212",0,140,0
        .stabx 
"adspace32_t:T215=s68alloc:77,0,32;srval:216=ar118;0;15;77,32,512;;",0,140,0
        .stabx  "adspace32_t:t217=215",0,140,0
        .stabx  "_MR_ATTR_TYPE:T218=eBadAttr:0,VirtAddr:1,;",0,140,0
        .stabx  "MR_ATTR_TYPE:t219=218",0,140,0
        .stabx 
"_MR_LABEL_TYPE:T220=eBadMem:0,FreeMem:1,IPLCB:2,RMALLOC:3,PM_HEAP:4,RTAS_HEAP:5,TCE_TABLE:6,IO_SPACE:7,HUGE_PAGE:8,;",0,140,0
        .stabx  "MR_LABEL_TYPE:t221=220",0,140,0
        .stabx 
"iplcb_map_reg_t:t222=223=s24mr_addr:-32,0,64;mr_size:-32,64,64;mr_att:-5,128,8;mr_label:-5,136,8;mr_nodeid:-7,144,16;reserved:224=ar118;0;3;-2,160,32;;",0,140,0
        .stabx  "vmlpghandle_t:t225=178",0,140,0
        .stabx 
"label_t:T226=s100prev:227=*226,0,32;iar:78,32,32;stack:78,64,32;toc:78,96,32;cr:78,128,32;intpri:78,160,32;reg:228=ar118;0;18;78,192,608;;",0,140,0
        .stabx  "label_t:t229=226",0,140,0
        .stabx  "ext_t:t230=55",0,140,0
        .stabx  "__ptr64:t231=-32",0,140,0
        .stabx  "__cptr64:t232=-32",0,140,0
        .stabx  "UniChar:t233=76",0,140,0
        .stabx  "UTF32Char:t234=77",0,140,0
        .stabx  "uchar:t235=75",0,140,0
        .stabx  "ushort:t236=76",0,140,0
        .stabx  "uint:t237=77",0,140,0
        .stabx  "ulong:t238=78",0,140,0
        .stabx  "physadr_t:t239=240=*241=s4r:242=ar118;0;0;-1,0,32;;",0,140,0
        .stabx  "physadr:t243=239",0,140,0
        .stabx  "u_char:t244=-5",0,140,0
        .stabx  "u_short:t245=-7",0,140,0
        .stabx  "u_int:t246=-8",0,140,0
        .stabx  "u_long:t247=-10",0,140,0
        .stabx  "swblk_t:t248=-1",0,140,0
        .stabx  "sigset:T249=s8losigs:-8,0,32;hisigs:-8,32,32;;",0,140,0
        .stabx  "fsid:T250=s8val:144,0,64;;",0,140,0
        .stabx 
"fileid:T251=s24fid_len:77,0,32;fid_ino:86,32,32;fid_gen:77,64,32;fid_x:252=ar118;0;9;-2,96,80;;",0,140,0
        .stabx 
"fid:T253=s24fid_len:77,0,32;fid_data:254=ar118;0;19;-2,32,160;;",0,140,0
        .stabx  "fid_t:t255=253",0,140,0
        .stabx  "fhandle:T256=s32x:257=ar118;0;31;-2,0,256;;",0,140,0
        .stabx  "fhandle_t:t258=256",0,140,0
        .stabx 
"filehandle:T259=s32fh_fsid:145,0,64;fh_fid:251,64,192;;",0,140,0
        .stabx 
"unique_id:T260=s16word1:52,0,32;word2:52,32,32;word3:52,64,32;word4:52,96,32;;",0,140,0
        .stabx  "unique_id_t:t261=260",0,140,0
        .stabx  "offset_t:t262=-31",0,140,0
        .stabx  "ssize64_t:t263=-31",0,140,0
        .stabx  "longlong_t:t264=-31",0,140,0
        .stabx  "u_longlong_t:t265=-32",0,140,0
        .stabx  "class_id_t:t266=-8",0,140,0
        .stabx  "liobn_t:t267=77",0,140,0
        .stabx  "unit_addr_t:t268=-32",0,140,0
        .stabx  "size64_t:t269=-32",0,140,0
        .lcomm flag2,4,_static.bss_
        .csect _static.rw_[RO],3
        .align 2
LC..2:
        .byte "flag1:%d flag2:%d"
        .byte 10, 0
        .toc
LC..0:
        .tc flag1[TC],flag1
LC..1:
        .tc flag2[TC],flag2
LC..3:
        .tc LC..2[TC],LC..2
        .csect .text[PR]
        .align 2
        .globl main
        .globl .main
        .csect main[DS]
main:
        .long .main, TOC[tc0], 0
        .csect .text[PR]
.main:
        .ei     "/usr/include/sys/inttypes.h"
        .stabx  "main:F-1",.main,142,0
        .function .main,.main,16,044,FE..main-.main
        .bf     7
        .stabx  "argc:p-1",104,130,0
        .stabx  "argv:p47",108,130,0
        .line   1
        mflr 0
        stw 31,-4(1)
        stw 0,8(1)
        stwu 1,-80(1)
        mr 31,1
        stw 3,104(31)
        stw 4,108(31)
        .line   2
        lwz 9,LC..0(2)
        lwz 11,0(9)
        lwz 9,LC..1(2)
        lwz 0,0(9)
        lwz 3,LC..3(2)
        mr 4,11
        mr 5,0
        bl .printf
        nop
        .line   3
        li 0,0
        .line   4
        mr 3,0
        lwz 1,0(1)
        lwz 0,8(1)
        mtlr 0
        lwz 31,-4(1)
        blr
        .ef     10
LT..main:
        .long 0
        .byte 0,0,32,97,128,1,2,1
        .long 0
        .long LT..main-.main
        .short 4
        .byte "main"
        .byte 31
        .align 2
FE..main:
        .lcomm flag1,4,_static.bss_
        .bs     _static.bss_
        .stabx  "flag1:S-1",flag1,133,0
        .es
        .bs     _static.rw_[RW]
        .stabx  "flag2:S-1",flag2,133,0
        .es
_section_.text:
        .csect .data[RW],3
        .long _section_.text

-------

$ xlc -g -S static.c

$ cat static.s
.set r0,0; .set SP,1; .set RTOC,2; .set r3,3; .set r4,4
.set r5,5; .set r6,6; .set r7,7; .set r8,8; .set r9,9
.set r10,10; .set r11,11; .set r12,12; .set r13,13; .set r14,14
.set r15,15; .set r16,16; .set r17,17; .set r18,18; .set r19,19
.set r20,20; .set r21,21; .set r22,22; .set r23,23; .set r24,24
.set r25,25; .set r26,26; .set r27,27; .set r28,28; .set r29,29
.set r30,30; .set r31,31
.set fp0,0; .set fp1,1; .set fp2,2; .set fp3,3; .set fp4,4
.set fp5,5; .set fp6,6; .set fp7,7; .set fp8,8; .set fp9,9
.set fp10,10; .set fp11,11; .set fp12,12; .set fp13,13; .set fp14,14
.set fp15,15; .set fp16,16; .set fp17,17; .set fp18,18; .set fp19,19
.set fp20,20; .set fp21,21; .set fp22,22; .set fp23,23; .set fp24,24
.set fp25,25; .set fp26,26; .set fp27,27; .set fp28,28; .set fp29,29
.set fp30,30; .set fp31,31
.set v0,0; .set v1,1; .set v2,2; .set v3,3; .set v4,4
.set v5,5; .set v6,6; .set v7,7; .set v8,8; .set v9,9
.set v10,10; .set v11,11; .set v12,12; .set v13,13; .set v14,14
.set v15,15; .set v16,16; .set v17,17; .set v18,18; .set v19,19
.set v20,20; .set v21,21; .set v22,22; .set v23,23; .set v24,24
.set v25,25; .set v26,26; .set v27,27; .set v28,28; .set v29,29
.set v30,30; .set v31,31
.set MQ,0; .set XER,1; .set FROM_RTCU,4; .set FROM_RTCL,5; .set FROM_DEC,6
.set LR,8; .set CTR,9; .set TID,17; .set DSISR,18; .set DAR,19; .set TO_RTCU,20
.set TO_RTCL,21; .set TO_DEC,22; .set SDR_0,24; .set SDR_1,25; .set SRR_0,26
.set SRR_1,27
.set BO_dCTR_NZERO_AND_NOT,0; .set BO_dCTR_NZERO_AND_NOT_1,1
.set BO_dCTR_ZERO_AND_NOT,2; .set BO_dCTR_ZERO_AND_NOT_1,3
.set BO_IF_NOT,4; .set BO_IF_NOT_1,5; .set BO_IF_NOT_2,6
.set BO_IF_NOT_3,7; .set BO_dCTR_NZERO_AND,8; .set BO_dCTR_NZERO_AND_1,9
.set BO_dCTR_ZERO_AND,10; .set BO_dCTR_ZERO_AND_1,11; .set BO_IF,12
.set BO_IF_1,13; .set BO_IF_2,14; .set BO_IF_3,15; .set BO_dCTR_NZERO,16
.set BO_dCTR_NZERO_1,17; .set BO_dCTR_ZERO,18; .set BO_dCTR_ZERO_1,19
.set BO_ALWAYS,20; .set BO_ALWAYS_1,21; .set BO_ALWAYS_2,22
.set BO_ALWAYS_3,23; .set BO_dCTR_NZERO_8,24; .set BO_dCTR_NZERO_9,25
.set BO_dCTR_ZERO_8,26; .set BO_dCTR_ZERO_9,27; .set BO_ALWAYS_8,28
.set BO_ALWAYS_9,29; .set BO_ALWAYS_10,30; .set BO_ALWAYS_11,31
.set CR0_LT,0; .set CR0_GT,1; .set CR0_EQ,2; .set CR0_SO,3
.set CR1_FX,4; .set CR1_FEX,5; .set CR1_VX,6; .set CR1_OX,7
.set CR2_LT,8; .set CR2_GT,9; .set CR2_EQ,10; .set CR2_SO,11
.set CR3_LT,12; .set CR3_GT,13; .set CR3_EQ,14; .set CR3_SO,15
.set CR4_LT,16; .set CR4_GT,17; .set CR4_EQ,18; .set CR4_SO,19
.set CR5_LT,20; .set CR5_GT,21; .set CR5_EQ,22; .set CR5_SO,23
.set CR6_LT,24; .set CR6_GT,25; .set CR6_EQ,26; .set CR6_SO,27
.set CR7_LT,28; .set CR7_GT,29; .set CR7_EQ,30; .set CR7_SO,31
.set TO_LT,16; .set TO_GT,8; .set TO_EQ,4; .set TO_LLT,2; .set TO_LGT,1

        .rename H.19.NO_SYMBOL{PR},""
        .rename H.36.NO_SYMBOL{TC},""
        .rename H.38.NO_SYMBOL{RO},""
        .rename E.40.__STATIC{RW},"_$STATIC"
        .rename H.45.__STATIC{TC},"_$STATIC"
        .rename E.47.__STATIC_BSS,"_$STATIC_BSS"
        .rename H.52.__STATIC_BSS{TC},"_$STATIC_BSS"
        .rename H.56.main{TC},"main"

        .lglobl H.19.NO_SYMBOL{PR}
        .globl  .main
        .lglobl H.38.NO_SYMBOL{RO}
        .lglobl E.40.__STATIC{RW}
        .lglobl E.47.__STATIC_BSS{RW}
        .globl  main{DS}
        .extern .printf{PR}


# .text section
        .file   "static.c"
        .stabx  "__default_char:t20=-5",0x00,0x8c,0x0
        .stabx  ":t2=-2",0x00,0x8c,0x0
        .stabx  ":t1=-1",0x00,0x8c,0x0
        .stabx  ":t3=*-2",0x00,0x8c,0x0
        .stabx  ":t4=*3",0x00,0x8c,0x0
        .stabx  ":t5=f-1;",0x00,0x8c,0x0
        .stabx  ":t6=k-2",0x00,0x8c,0x0
        .stabx  ":t7=ar0;0;4;6",0x00,0x8c,0x0
        .stabx  ":t21=Z",0x00,0x8c,0x0


        .csect  H.19.NO_SYMBOL{PR}, 5
.main:                                  # 0x00000000 (H.19.NO_SYMBOL)
        .stabx  "main:F-1",0x00,0x8e,0x0
        .function .main,.main,2,0
        mfspr   r0,LR
        st      r31,-4(SP)
        st      r30,-8(SP)
        st      r0,8(SP)
        stu     SP,-80(SP)
        l       r31,T.45.__STATIC(RTOC)
        l       r30,T.36.NO_SYMBOL(RTOC)
        st      r3,104(SP)
        st      r4,108(SP)
        .bf     6
        .stabx  "arg:p-1",0x068,0x82,0x0
        .stabx  "argv:p4",0x06c,0x82,0x0
        .bs     H.38.NO_SYMBOL{RO}
        .stabx  "__func__:V7",0x00,0x85,0x0
        .es
        .line   1
        l       r3,T.52.__STATIC_BSS(RTOC)
        l       r4,0(r3)
        l       r5,0(r31)
        cal     r3,8(r30)
        bl      .printf{PR}
        oril    r0,r0,0x0000
        .line   2
        cal     r3,0(r0)
        b       __L44
__L44:                                  # 0x00000044 (H.19.NO_SYMBOL+0x44)
        .line   3
        l       r0,88(SP)
        mtspr   LR,r0
        cal     SP,80(SP)
        l       r30,-8(SP)
        l       r31,-4(SP)
        bcr     BO_ALWAYS,CR0_LT
        .ef     8
        .long   0x00000000
# traceback table
        .byte   0x00                    # VERSION=0
        .byte   0x00                    # LANG=TB_C
        .byte   0x20                    # IS_GL=0,IS_EPROL=0,HAS_TBOFF=1
                                        # INT_PROC=0,HAS_CTL=0,TOCLESS=0
                                        # FP_PRESENT=0,LOG_ABORT=0
        .byte   0x41                    # INT_HNDL=0,NAME_PRESENT=1
                                        # USES_ALLOCA=0,CL_DIS_INV=WALK_ONCOND
                                        # SAVES_CR=0,SAVES_LR=1
        .byte   0x80                    # STORES_BC=1,FPR_SAVED=0
        .byte   0x02                    # GPR_SAVED=2
        .byte   0x02                    # FIXEDPARMS=2
        .byte   0x01                    # FLOATPARMS=0,PARMSONSTK=1
        .long   0x00000000              #
        .long   0x0000005c              # TB_OFFSET
        .short  4                       # NAME_LEN
        .byte   "main"
        .byte   0                       # padding
        .byte   0                       # padding
# End of traceback table
        .long   0x00000000              # "\0\0\0\0"
        .long   0x00000000              # "\0\0\0\0"
# End   csect   H.19.NO_SYMBOL{PR}

# .data section


        .toc                            # 0x00000080
T.56.main:
        .tc     H.56.main{TC},main{DS}
T.45.__STATIC:
        .tc     H.45.__STATIC{TC},E.40.__STATIC{RW}
T.36.NO_SYMBOL:
        .tc     H.36.NO_SYMBOL{TC},H.38.NO_SYMBOL{RO}
T.52.__STATIC_BSS:
        .tc     H.52.__STATIC_BSS{TC},E.47.__STATIC_BSS


        .csect  main{DS}
        .long   .main                   # "\0\0\0\0"
        .long   TOC{TC0}                # "\0\0\0\200"
        .long   0x00000000              # "\0\0\0\0"
# End   csect   main{DS}


        .csect  E.40.__STATIC{RW}
        .bs     E.40.__STATIC{RW}
        .stabx  "flag2:V-1",0x00,0x85,0x0
        .es
        .long   0x00000000              # "\0\0\0\0"
# End   csect   E.40.__STATIC{RW}


        .csect  H.38.NO_SYMBOL{RO}, 3
        .long   0x6d61696e              # "main"
        .long   0x0049424d              # "\0IBM"
        .long   0x666c6167              # "flag"
        .long   0x313a2564              # "1:%d"
        .long   0x20666c61              # " fla"
        .long   0x67323a25              # "g2:%"
# End   csect   H.38.NO_SYMBOL{RO}
        .long   0x640a0000              # "d\n\0\0"



# .bss section
        .lcomm  L.E.47.__STATIC_BSS, 4, E.47.__STATIC_BSS
        .bs     E.47.__STATIC_BSS{RW}
        .stabx  "flag1:V-1",0x00,0x85,0x0
        .es

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[michael.haubenwallner at salomon dot at]

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

Michael Haubenwallner <michael.haubenwallner at salomon dot at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael.haubenwallner at
                   |                            |salomon dot at

--- Comment #3 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-01-25 08:29:49 UTC ---
Same here with gcc-4.2.4 on AIX5.3 after upgrading from TL10 to TL12.

(need to figure out the exact details of the problem myself yet)

Which information is necessary here to help this getting fixed?

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[michael.haubenwallner at salomon dot at]

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

--- Comment #4 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-01-25 12:52:22 UTC ---
What exactly is the difference for gcc between not initializing a static
variable and initializing it to zero?

This is the difference in the generated assembler file:

  $ cat mytest.c
static int myvar;

int main(void)
{
    return myvar;
}

#if defined(IVAL)
static int myvar = IVAL;
#endif

For the compilation:

  $ gcc -g mytest.c -DIVAL=0
(success)
  $ gcc -g mytest.c
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 29) in object
/tmp//cc26KLXk.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
(fail)

For the analysis:

  $ gcc -g -S mytest.c -o mytestu.s
  $ gcc -g -S mytest.c -o mytest0.s -DIVAL=0
  $ diff -u mytestu.s mytest0.s 
--- mytestu.s   2011-01-25 13:39:43.000000000 +0100
+++ mytest0.s   2011-01-25 13:40:01.000000000 +0100
@@ -42,7 +42,7 @@
        .byte 31
        .align 2
  FE..main:
-       .bs     _mytest.bss_
+       .bs     _mytest.rw_[RW]
        .stabx  "myvar:S-1",myvar,133,0
        .es
  _section_.text:

Both gcc-4.5.1 and gcc-4.2.4 do make this difference.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[michael.haubenwallner at salomon dot at]

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

--- Comment #5 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-01-25 15:40:07 UTC ---
Created attachment 23120
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23120
Patch to simply not use bss section with .bs, but private-data-section instead

I'm going to try this patch with gcc-4.2.4 now...

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[michael.haubenwallner at salomon dot at]

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

--- Comment #6 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-02-09 09:03:05 UTC ---
(In reply to comment #5)
> Created attachment 23120 [details]
> Patch to simply not use bss section with .bs, but private-data-section instead
> 
> I'm going to try this patch with gcc-4.2.4 now...

This patch works quite well here.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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

Perry Smith <pedzsan at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pedzsan at gmail dot com

--- Comment #7 from Perry Smith <pedzsan at gmail dot com> 2011-02-24 01:21:52 UTC ---
This change must be within TL10 too.  I'm at

5300-10-05-1036

and have the same issue.  There are three APARs that came out in 5.3 TL10 SP02
that hit bind: IZ69311, IZ69515, and IZ70028.  One APAR in SP03: IZ73713.  And
one in SP04: IZ82696.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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

--- Comment #8 from Perry Smith <pedzsan at gmail dot com> 2011-03-18 17:10:32 UTC ---
It appears that this not a "gcc" bug but an AIX bug.  There is one change but
more changes are needed.  I'll try to update when I know more.  Expect it to be
a week or so.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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

--- Comment #9 from Daniel Richard G. <skunk at iskunk dot org> 2011-03-18 18:05:13 UTC ---
(In reply to comment #8)
> It appears that this not a "gcc" bug but an AIX bug.

The error was precipitated by an AIX system update, but at the same time, it
can be said that the AIX linker was previously being lenient in not requiring a
csect declaration for the bss section.

Whether this is an "AIX bug" or "GCC bug" isn't really relevant. IBM changed
how the AIX linker operates, and GCC needs to be updated accordingly.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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

--- Comment #10 from Perry Smith <pedzsan at gmail dot com> 2011-03-18 18:57:07 UTC ---
IZ81343 (or one of its sister APARs) fixes the original issue.  But, it leaves
a new issue.  The new error looks like:

ld: 0711-596 SEVERE ERROR: Object expand.o
        An RLD for section 2 (.data) refers to symbol 852,
        but the storage class of the symbol is not C_EXT or C_HIDEXT.

The word I have presently is that that too is going to turn out to be an AIX
assembler error.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[michael.haubenwallner at salomon dot at]

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

--- Comment #11 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-03-23 07:46:49 UTC ---
(In reply to comment #10)
> IZ81343 (or one of its sister APARs) fixes the original issue.  But, it leaves
> a new issue.  The new error looks like:

Perry, have you seen this on AIX 5.3 or 6.1 ?

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[david.kirkby at onetel dot net]

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

Dr. David Kirkby <david.kirkby at onetel dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.kirkby at onetel dot
                   |                            |net

--- Comment #12 from Dr. David Kirkby <david.kirkby at onetel dot net> 2011-03-23 10:34:54 UTC ---
I'm seeing this error on AIX 5.3. Two GNU projects effected by this are 
 * GNU patch
 * GSL (GNU Scientific library)

In the case of the former, if one configures with CFLAGS =-g0, so not to
include debugging information, the problem goes away. So when one compiles GNU
patch like this I see:

gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/usr/bin/ed\" -I. -I. -g0 quotesys.c


But the GSL Scientific library can't be compiled this way, as the users's -g0
gets in before the -g added by GSL, so one see something like:

gcc -g0 -g foo.c

which means the debugging information is still present.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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

--- Comment #13 from Perry Smith <pedzsan at gmail dot com> 2011-03-23 13:26:10 UTC ---
On Mar 23, 2011, at 2:47 AM, michael.haubenwallner at salomon dot at wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
> 
> --- Comment #11 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-03-23 07:46:49 UTC ---
> (In reply to comment #10)
>> IZ81343 (or one of its sister APARs) fixes the original issue.  But, it leaves
>> a new issue.  The new error looks like:
> 
> Perry, have you seen this on AIX 5.3 or 6.1 ?

5.3 -- something.  I thought I put it in my update.  I can check when I get to
work.  Seems like it was tl10 but a later SP than others reported.

Does that help?

Perry

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[david.kirkby at onetel dot net]

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

--- Comment #14 from Dr. David Kirkby <david.kirkby at onetel dot net> 2011-03-23 17:11:42 UTC ---
Has anyone with an AIX support contract ever raised this issue with IBM? If so,
is there a publicly viewable location for this? 

If not, can someone do it. My own RS/6000 is an ancient thing I personally own,
and so I have no support contract at all. 

It seems to me it could be a gcc bug or a bug in the AIX assembler or linker. 

It would be interesting to try to replace the systems linker and assembler with
versions from unpatched 5.3 or 6.1. That might give some clues. 

I can see this issue raised on an IBM AIX forum

http://www.ibm.com/developerworks/forums/thread.jspa?threadID=348558

but don't know if its even being considered by IBM.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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

--- Comment #15 from Perry Smith <pedzsan at gmail dot com> 2011-03-23 19:31:18 UTC ---
Let me try and recap.

The initial report was that 5.3 TL10 did *not* have the error.  I discovered
that 5.3 TL10 SP03 does.  See [1].

APAR IZ81343[2] and its sister APARs addresses this issue.  It is shipped (for
example) in 5.3 TL10 SP05 as IZ81339.

After you apply that APAR, you get a new issue where the linker now spews out:

ld: 0711-596 SEVERE ERROR: Object expand.o
        An RLD for section 2 (.data) refers to symbol 852,
        but the storage class of the symbol is not C_EXT or C_HIDEXT.

I got this when I tried to build GNU's make on 5.3 TL10 SP02 with just the
assembler APAR.  I tried two versions of GCC: 4.2.0 and 4.5.2.

IBM is aware of the issue (via me and others).  The last tidbit I have is that
it appears as if it is another assembler bug but that is not confirmed yet.  I
don't have a fix nor do I have an APAR number yet.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072#c7
[2] https://www-304.ibm.com/support/docview.wss?uid=isg1IZ81343

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[david.kirkby at onetel dot net]

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

--- Comment #16 from Dr. David Kirkby <david.kirkby at onetel dot net> 2011-03-24 13:22:28 UTC ---
(In reply to comment #15)
> Let me try and recap.
> 
> The initial report was that 5.3 TL10 did *not* have the error.  I discovered
> that 5.3 TL10 SP03 does.  See [1].
> 
> APAR IZ81343[2] and its sister APARs addresses this issue.  It is shipped (for
> example) in 5.3 TL10 SP05 as IZ81339.
> 
> After you apply that APAR, you get a new issue where the linker now spews out:
> 
> ld: 0711-596 SEVERE ERROR: Object expand.o
>         An RLD for section 2 (.data) refers to symbol 852,
>         but the storage class of the symbol is not C_EXT or C_HIDEXT.

This is odd. I have 

-bash-4.1$ oslevel -rq
Known Recommended Maintenance Levels
------------------------------------
5300-12
5300-11
5300-10
5300-09
5300-08
5300-07
5300-06
5300-05
5300-04
5300-03
5300-02
5300-01
5300-00

and whilst I can't see how to get the information on the service pack, I have
service pack 2. 

https://www-304.ibm.com/support/docview.wss?uid=isg1IZ83065

dated 17th Jan 2011. 

So why am I getting the error on this bug report (ld: 0711-593 SEVERE ERROR:
Symbol C_BSTAT) and not ld: 0711-596 SEVERE ERROR? 

If I understand you correctly, you are saying ld: 0711-593 SEVERE ERROR: Symbol
C_BSTAT) was fixed in AIX 5.3 5300-10 Service Pack 3, which is dated March 24,
2010

https://www-304.ibm.com/support/docview.wss?uid=isg1SSRVAIX53TL10071505_161

That is some 10 months prior to the service pack I have. 

I suspect I am mis-understanding something. 

I'm using a 32-bit RS/6000 7025 F50, with 4 x 332 MHz CPUs, 3 GB RAM, which I
know is an antique in computer terms. 

Dave

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[rockdreamer at gmail dot com]

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

--- Comment #17 from Claudio Bantaloukas <rockdreamer at gmail dot com> 2011-04-06 08:35:27 UTC ---
Comment on attachment 23120
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23120
Patch to simply not use bss section with .bs, but private-data-section instead

Hi *, I've been bitten by this bug too.

Patch 23120 resolves the C_SECT issue for me, however I get a new error when
compiling a c++ file.

----
ld: 0711-380 STABSTRING ERROR: Symbol table entry 1246, object file
../libpkg_mka.a[DB
2MkAQuery.cpp.o]
        Length of stabstring in .debug section is invalid.
        The stabstring is being deleted.
ld: 0711-380 STABSTRING ERROR: Symbol table entry 1248, object file
../libpkg_mka.a[Or
aMkAQuery.cpp.o]
        Length of stabstring in .debug section is invalid.
        The stabstring is being deleted.
collect2: ld returned 12 exit status
---

Any suggestions on how to add more details this are welcome!

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[michael.haubenwallner at salomon dot at]

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

--- Comment #18 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-04-07 07:59:00 UTC ---
(In reply to comment #15)
> ld: 0711-596 SEVERE ERROR: Object expand.o
>         An RLD for section 2 (.data) refers to symbol 852,
>         but the storage class of the symbol is not C_EXT or C_HIDEXT.
> 
> I got this when I tried to build GNU's make on 5.3 TL10 SP02 with just the
> assembler APAR.  I tried two versions of GCC: 4.2.0 and 4.5.2.
> 
> IBM is aware of the issue (via me and others).  The last tidbit I have is that
> it appears as if it is another assembler bug but that is not confirmed yet.  I
> don't have a fix nor do I have an APAR number yet.

Looks like this one is it:
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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

--- Comment #19 from Perry Smith <pedzsan at gmail dot com> 2011-04-07 12:55:19 UTC ---
Yes.  Thats the one.

Dave,

First, I believe this link is a public facing interface to "Fix Central"

http://www.ibm.com/support/fixcentral/

(it came from google).  If not, post back, and I'll try and find one.

I *think* you can do "instfix IZxxxxx" or something to that effect and it will
say yea or nah as to if you have the APAR.  I don't know for sure.  I usually
go by fileset and VRMF levels like bos.foo 4.3.2.1.  

I assume you know that each TL has its own APAR for each problem so you have to
look for "sister" APARs.  Fix central is suppose to be smart enough to do that
but I'm not sure about instfix.

Also you did flip around some things.  5.3 TL10 SP03 has the problem SP05 has
the first fix but not the second.  For 5.3 TL12, SP02 has the first fix as
IZ81341.  Note that the two issues are very similar.  The error number changed
and that is what I key off of.

You can do "oslevel -s" to get the service pack level that you have installed.

The reason I put the link to fix central is IBM charges for support -- not
updates.  As far as I can tell, anyone can go to fix central and download any
fix they want.

Hope this helps

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[david.kirkby at onetel dot net]

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

--- Comment #20 from Dr. David Kirkby <david.kirkby at onetel dot net> 2011-04-07 17:15:07 UTC ---
(In reply to comment #18)
> > IBM is aware of the issue (via me and others).  The last tidbit I have is that
> > it appears as if it is another assembler bug but that is not confirmed yet.  I
> > don't have a fix nor do I have an APAR number yet.
> 
> Looks like this one is it:
> https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134


Yes, that looks like it. The title is just right. "IZ98134: ASSEMBLER GENERATES
INVALID OBJECT FILE WITH GCC-PRODUCED FILES"

But what does
================================
APAR status

    *
      Closed as program error.

Problem conclusion

    *

      Fix logic handling debugging pseudo-ops.

=================================

mean? Does this mean IBM consider it a GCC bug? I don't find the explanations
on the page too useful. 



Dave

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[michael.haubenwallner at salomon dot at]

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

--- Comment #21 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-04-08 07:53:44 UTC ---
(In reply to comment #20)
> mean? Does this mean IBM consider it a GCC bug? I don't find the explanations
> on the page too useful. 

The notification for this APAR also contained this text:
"The record has been closed. A programming error was found. The problem will be
corrected. A fix is pending."

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[ppryor63 at gmail dot com]

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

--- Comment #22 from Paul Pryor <ppryor63 at gmail dot com> 2011-04-08 19:56:15 UTC ---
I found an workaround. When I realized that /usr/bin/as was the culprit (from
looking at IZ98134), I tried using as from other AIX box at TL4, and it worked
out just fine. Here is what I did:

Somehow find a copy of /usr/bin/as from older AIX box. Put in your home
directory or anywhere you want. I would not recommend replacing /usr/bin/as
with older copy because AIX may need new as features somewhere.

Dump the specs for gcc to a file as follows:

gcc –dump-specs > myspecs

Edit the myspecs file to force gcc to use your copy of as. Here is an example:

…
*invoke_as:
%{!S:-o %|.s |
  /home/ppryor/bin/as %(asm_options) %m.s %A }
…

Then compile your code using this syntax:

gcc –specs=$HOME/myspecs –g –c file.c -o file

I believe it is very safe alternative. Gcc does not make use of any new
features in /usr/bin/as that I know of. And AIX's as is stand alone with no
dependencies.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[david.kirkby at onetel dot net]

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

--- Comment #23 from Dr. David Kirkby <david.kirkby at onetel dot net> 2011-04-08 21:31:05 UTC ---
(In reply to comment #22)
> I found an workaround. When I realized that /usr/bin/as was the culprit (from
> looking at IZ98134), I tried using as from other AIX box at TL4, and it worked
> out just fine. Here is what I did:
> 
> Somehow find a copy of /usr/bin/as from older AIX box.

That's fine if you have an older AIX box. Mine is already a relic - a 32-bit
system with 332 MHz CPUs! Do you know how to find 'as' from the installation
media? Can you email me a copy from an AIX 5.3 machine? 

david dot kirkby <at> onetel.net

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[david.kirkby at onetel dot net]

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

--- Comment #24 from Dr. David Kirkby <david.kirkby at onetel dot net> 2011-04-12 02:38:22 UTC ---
(In reply to comment #23)
> (In reply to comment #22)
> > I found an workaround. When I realized that /usr/bin/as was the culprit (from
> > looking at IZ98134), I tried using as from other AIX box at TL4, and it worked
> > out just fine. Here is what I did:
> > 
> > Somehow find a copy of /usr/bin/as from older AIX box.
> 
> That's fine if you have an older AIX box. Mine is already a relic - a 32-bit
> system with 332 MHz CPUs! Do you know how to find 'as' from the installation
> media? Can you email me a copy from an AIX 5.3 machine? 
> 
> david dot kirkby <at> onetel.net


Someone kindly emailed me an older copy of "as", so I did something like:

# mv /usr/ccs/bin/as /usr/ccs/bin/as.nfg
# cp /tmp/as /usr/ccs/bin/as (where the older 'as' was in /tmp)

That has solved my problem. Of course it is not a perfect solution, but it does
at least allow me to compile files now. 

Dave

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[dje at gcc dot gnu.org]

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

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011.05.17 14:05:46
                 CC|                            |dje at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #25 from David Edelsohn <dje at gcc dot gnu.org> 2011-05-17 14:05:46 UTC ---
GCC uses the AIX assembler and probably is the most heavy user of the assembler
of all applications on AIX (IBM XL compilers generate object code directly). 
An upgrade to the AIX assembler has introduced a bug that can generate invalid
object files.  The is an AIX bug, not a GCC bug.  The broken assembler is
distributed in AIX 7.1 TL0, and updates for earlier levels of AIX: AIX 6.1 TL6
and AIX 5.3 TL12.

A number of PMRs have been reported about the problem:

PMR 32726, 379, 000
PMR 40999, 122, 000 (unable to compile after TL12 upgrade)
PMR 13417, 005, 000 (assembler-compiler errors at TL12 update)

An initial fix introduced other problems.  A new fix is available, but it still
is unclear when it generally will be available.  APARs:

IZ98134 for AIX 5.3 TL12
IZ98861 for AIX 6.1 TL6
IZ99344 for AIX 7.1 TL0

Other related APARs:
IZ98226 IZ98385 IZ98477 IZ98732 IZ99107

The fixed assembler is available as an efix for customers who ask.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[michael.haubenwallner at salomon dot at]

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

--- Comment #26 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-05-17 14:52:36 UTC ---
(In reply to comment #25)
> The fixed assembler is available as an efix for customers who ask.

We did do this here, but the efix'ed assembler just dumps core upon some C++
construct found in strstream.cc (and others) - IBM is already aware of this.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[david.kirkby at onetel dot net]

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

--- Comment #27 from Dr. David Kirkby <david.kirkby at onetel dot net> 2011-05-17 15:25:50 UTC ---
(In reply to comment #25)

> The fixed assembler is available as an efix for customers who ask.

Can you give me more precise details about how to get this. Who do I ask - I
don't have a service contract for my old AIX box. 

I have a workaround for this, as someone sent me an older version of the
assembler which works, but clearly using a later version would be preferable. 

Dave

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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

--- Comment #28 from Daniel Richard G. <skunk at iskunk dot org> 2011-05-17 18:12:26 UTC ---
(In reply to comment #25)
> An upgrade to the AIX assembler has introduced a bug that can generate invalid
> object files.  The is an AIX bug, not a GCC bug.

I'm not yet convinced that this is the case. It could well be that the
assembler (or linker) is being more strict in how it interprets code.

Does anyone here have the IBM XL compiler? It would be interesting to compare
the assembly that it produces (I presume it can be made to generate assembly
even if it normally emits object code directly) for the minimal test case to
GCC's.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[ppryor63 at gmail dot com]

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

--- Comment #29 from Paul Pryor <ppryor63 at gmail dot com> 2011-05-17 23:49:44 UTC ---
(In reply to comment #28)
> (In reply to comment #25)
> > An upgrade to the AIX assembler has introduced a bug that can generate invalid
> > object files.  The is an AIX bug, not a GCC bug.
> 
> I'm not yet convinced that this is the case. It could well be that the
> assembler (or linker) is being more strict in how it interprets code.
> 
> Does anyone here have the IBM XL compiler? It would be interesting to compare
> the assembly that it produces (I presume it can be made to generate assembly
> even if it normally emits object code directly) for the minimal test case to
> GCC's.

If you would look at comment #2, that is what I did.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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

--- Comment #30 from Daniel Richard G. <skunk at iskunk dot org> 2011-05-18 01:12:17 UTC ---
(In reply to comment #29)
> If you would look at comment #2, that is what I did.

Ah, thanks for the reminder.

The generated assembly appears to include artifacts (e.g. type declarations)
from system headers, however, likely from an #include<stdio.h> directive not in
the C code as quoted. Could you provide the xlc assembly output from the
minimal test-case program, which has no #includes, and "return 0" as the only
statement?

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[mrgcc at mailinator dot com]

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

mrgcc at mailinator dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrgcc at mailinator dot com

--- Comment #31 from mrgcc at mailinator dot com 2011-05-20 08:02:27 UTC ---
Hi *,

just my 2 cents

>From my poor understanding, to mee this seems like an "as" issue.
>From the same .s input the "old" and "new" as produces different .o files.
The dump util on the two .o shows more clear what the linker tries to say

testcode:
static int globstat;
int main() { static int innerstat; return 0;}
new as:

[48]    m   0x00000000         1     0    0x8f         0x0000     .bs
---------------------^
should be pointing to 68 = 0x44
and is illegal according to the specs
[49]    m   0x00000004        -2     0    0x85         0x0000     innerstat:V3
[50]    m   0x00000000         1     0    0x90         0x0000     .es
[51]    m   0x00000010         1     1    0x64         0x0000     .eb
[52]    a1           2         0     0       0       0
[53]    m   0x00000020         1     1    0x65         0x0000     .ef
[54]    a1           0         2     0       0       0
[55]    m   0x00000000         1     0    0x8f         0x0000     .bs
---------------------^
[56]    m   0x00000000        -2     0    0x85         0x0000     globstat:S3
[57]    m   0x00000000         1     0    0x90         0x0000     .es
[58]    m   0x00000038         2     1    0x6b         0x0000     _test.rw_
[59]    a4  0x00000000       0    0     25    5        0    0
[60]    m   0x00000038         2     1    0x6b         0x0000     main
[61]    a4  0x0000000c       0    0     17   10        0    0
[62]    m   0x00000038         2     1    0x02         0x0000     main
[63]    a4  0x0000003c       0    0      2   10        0    0
[64]    m   0x00000048         2     1    0x6b         0x0000     .data
[65]    a4  0x00000004       0    0     25    5        0    0
[66]    m   0x0000004c         2     1    0x6b         0x0000     TOC
[67]    a4  0x00000000       0    0     17   15        0    0
[68]    m   0x0000004c         3     1    0x6b         0x0000     _test.bss_
[69]    a4  0x00000008       0    0     19    9        0    0


old as:

[48]    m   0x00000044         1     0    0x8f         0x0000     .bs
---------------------^
IS pointing to 68 = 0x44
[49]    m   0x00000004        -2     0    0x85         0x0000     innerstat:V3
[50]    m   0x00000000         1     0    0x90         0x0000     .es
[51]    m   0x00000010         1     1    0x64         0x0000     .eb
[52]    a1           0         1     0       0       0
[53]    m   0x00000020         1     1    0x65         0x0000     .ef
[54]    a1           0         2     0       0       0
[55]    m   0x00000044         1     0    0x8f         0x0000     .bs
---------------------^
[56]    m   0x00000000        -2     0    0x85         0x0000     globstat:S3
[57]    m   0x00000000         1     0    0x90         0x0000     .es
[58]    m   0x00000038         2     1    0x6b         0x0000     _test.rw_
[59]    a4  0x00000000       0    0     25    5        0    0
[60]    m   0x00000038         2     1    0x6b         0x0000     main
[61]    a4  0x0000000c       0    0     17   10        0    0
[62]    m   0x00000038         2     1    0x02         0x0000     main
[63]    a4  0x0000003c       0    0      2   10        0    0
[64]    m   0x00000048         2     1    0x6b         0x0000     .data
[65]    a4  0x00000004       0    0     25    5        0    0
[66]    m   0x0000004c         2     1    0x6b         0x0000     TOC
[67]    a4  0x00000000       0    0     17   15        0    0
[68]    m   0x0000004c         3     1    0x6b         0x0000     _test.bss_
[69]    a4  0x00000008       0    0     19    9        0    0

Everything else is created in the object file (.bss .debug)
AFAIK the _test.bss_ csect is an outcome of the .lcomm pseudo-op

When adding a .csect _test.bss_[BS] the csect index in the toc is still 0. Even
worse: i get a duplicate toc entry for _test.bss_

I could add a new csect before each .bs to make it linkable, but gdb doesn't
find the stabs then...

Btw: this as issue doesn't seem new:
http://www.opensource.apple.com/source/cc/cc-798/cc/xcoffout.h
 see #define DBX_STATIC_BLOCK_START
http://www.opensource.apple.com/source/gcc/gcc-934.3/gcc/README.RS6000
 see AIX 4.3.0 assembler

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[vovata at gmail dot com]

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

vladimir penev <vovata at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vovata at gmail dot com

--- Comment #32 from vladimir penev <vovata at gmail dot com> 2011-09-15 08:30:55 UTC ---
An update on this subject at my side.
After some interactions with IBM AIX support there is a fix
https://www-304.ibm.com/support/docview.wss?uid=isg1IV06344 and after that the
assembler doesn't crash any more and works as well in the same time.
It has been validated on AIX 6.1 with GCC 4.5.2

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[vovata at gmail dot com]

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

--- Comment #33 from vladimir penev <vovata at gmail dot com> 2011-09-15 08:44:04 UTC ---
An update on this subject at my side.
After some interactions with IBM AIX support there is a fix
https://www-304.ibm.com/support/docview.wss?uid=isg1IV06344 and after that the
assembler doesn't crash any more and works as well in the same time.
It has been validated on AIX 6.1 TL6 with GCC 4.5.2

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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

--- Comment #34 from Daniel Richard G. <skunk at iskunk dot org> 2011-09-15 14:01:36 UTC ---
(In reply to comment #33)

Vladimir, this [GCC] bug report has nothing to do with the assembler
segfaulting. The problem is that the linker can't link what the assembler is
producing ("ld: 0711-593 SEVERE ERROR").

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[vovata at gmail dot com]

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

--- Comment #35 from vladimir penev <vovata at gmail dot com> 2011-09-15 14:14:16 UTC ---
Yes, it's true. And using the mentioned efix for AIX the problem doesn't exist
any more, the assembler generates correct code and the linker links it as well.
Nothing to do at GCC side. I just inform the affected people about the existing
of a fix.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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

Daniel Richard G. <skunk at iskunk dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID

--- Comment #36 from Daniel Richard G. <skunk at iskunk dot org> 2012-04-12 16:28:36 UTC ---
My sysadmin recently upgraded the troublesome AIX 5.3 machine in question, and
this has made the linker issues go away. The minimal test case now passes, and
I can compile and link programs again without any workarounds. This is true
both for GCC 4.5.1 (same build as in the original report), and the older GCC
2.9 bundled with the system.

I'll provide the same patch-level information as Paul Pryor did earlier:

$ oslevel -s
5300-12-05-1140

$ ls -l /usr/bin/ld
lrwxrwxrwx    1 bin      bin              15 Dec 02 2004  /usr/bin/ld ->
/usr/ccs/bin/ld
$ ls -l /usr/ccs/bin/ld
-r-xr-xr-x    1 bin      bin           38942 Aug 09 2011  /usr/ccs/bin/ld

$ lslpp -h bos.rte.bind_cmds
  Fileset         Level     Action       Status       Date         Time        
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  bos.rte.bind_cmds
                  5.3.0.0   COMMIT       COMPLETE     12/02/04     17:04:24    
                  5.3.0.1   COMMIT       COMPLETE     12/06/04     11:52:51    
                 5.3.0.30   COMMIT       COMPLETE     09/30/10     10:04:35    
                 5.3.0.40   COMMIT       COMPLETE     10/01/10     11:02:18    
                 5.3.0.53   COMMIT       COMPLETE     10/01/10     14:15:17    
                 5.3.0.65   COMMIT       COMPLETE     10/05/10     09:48:48    
                  5.3.7.5   COMMIT       COMPLETE     10/06/10     10:04:03    
                  5.3.8.6   COMMIT       COMPLETE     10/07/10     08:13:13    
                  5.3.9.7   COMMIT       COMPLETE     10/08/10     08:33:35    
                 5.3.10.4   COMMIT       COMPLETE     10/14/10     10:35:13    
                 5.3.11.4   COMMIT       COMPLETE     10/15/10     23:31:34    
                 5.3.12.1   COMMIT       COMPLETE     10/16/10     00:05:56    
                 5.3.12.4   COMMIT       COMPLETE     04/03/12     12:34:21    

$ lslpp -i bos.rte.bind_cmds
                        Vendor
  Fileset               Code    Product Id  Feature Id  Package Name
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  bos.rte.bind_cmds 5.3.0.0
                                5765-E6200  0000        bos


I will be happy to provide additional details about the configuration of this
system if anyone needs it.

There does not appear to be anything left to do here as far as GCC is
concerned, so I'm marking this bug as invalid. If anyone feels differently,
feel free to change it back.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[michael.haubenwallner at salomon dot at]

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

--- Comment #37 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2012-04-16 13:29:06 UTC ---
A few more references:
The fix for this one issue is:
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134

But this introduces /usr/ccs/bin/as coredump during gcc bootstrap
(strstream.o):
https://www-304.ibm.com/support/docview.wss?uid=isg1IV01126

Just guessing, but maybe the whole thing was introduced by:
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87535

Based on the filesets shown in the APARs for each AIX release/TL/SP, here's a
list of maybe broken/working AIX levels, although I'm unable to verify for
sure, as the broken machines got the interim fix installed here for IV01126
(supersedes interim fix for IZ98134):

             +--------------+----------------+
             | broken since |  fixed since   |
-------------+--------------+----------------+
AIX 5.3 TL9  |           <works>             |
        TL10 |  SP6 (1107)  | <still broken> |
        TL11 |  SP6 (1107)  |   SP8 (1140)   |
        TL12 |  SP3 (1107)  |   SP5 (1140)   |
-------------+--------------+----------------+
AIX 6.1 TL2  |           <works>             |
        TL3  |  SP9 (1112)  | <still broken> |
        TL4  |  SP9 (1112)  |   SP11 (1140)  |
        TL5  |  SP5 (1112)  |   SP7  (1140)  |
        TL6  |  SP4 (1112)  |   SP6  (1140)  |
        TL7  |           <works>             |
-------------+--------------+----------------+
AIX 7.1 TL0  |  SP3 (1115)  | <still broken> |
        TL1  |           <works>             |
-------------+--------------+----------------+

Even if AIX 7.1 TL0 SP4 was released at 1140 too, it doesn't seem to contain
IV01126 - maybe TL0 SP5 will do.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[jackie.rosen at hushmail dot com]

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

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #38 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Marked for reference. Resolved as fixed @bugzilla.