Bug 46072 - AIX linker chokes on debug info for uninitialized static variables
Summary: AIX linker chokes on debug info for uninitialized static variables
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.5.1
: P3 major
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-18 18:48 UTC by Daniel Richard G.
Modified: 2018-07-18 03:18 UTC (History)
9 users (show)

See Also:
Host: powerpc-ibm-aix5.3.0.0
Target: powerpc-ibm-aix5.3.0.0
Build: powerpc-ibm-aix5.3.0.0
Known to work:
Known to fail:
Last reconfirmed: 2011-05-17 14:05:46


Attachments
Tarball containing a minimal test case (334 bytes, application/x-tar)
2010-10-18 18:48 UTC, Daniel Richard G.
Details
Patch to simply not use bss section with .bs, but private-data-section instead (330 bytes, patch)
2011-01-25 15:40 UTC, Michael Haubenwallner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Richard G. 2010-10-18 18:48:50 UTC
Created attachment 22082 [details]
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.
Comment 1 Daniel Richard G. 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.
Comment 2 Paul Pryor 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
Comment 3 Michael Haubenwallner 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?
Comment 4 Michael Haubenwallner 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.
Comment 5 Michael Haubenwallner 2011-01-25 15:40:07 UTC
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...
Comment 6 Michael Haubenwallner 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.
Comment 7 Perry Smith 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.
Comment 8 Perry Smith 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.
Comment 9 Daniel Richard G. 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.
Comment 10 Perry Smith 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.
Comment 11 Michael Haubenwallner 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 ?
Comment 12 Dr. David Kirkby 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.
Comment 13 Perry Smith 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
Comment 14 Dr. David Kirkby 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.
Comment 15 Perry Smith 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
Comment 16 Dr. David Kirkby 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
Comment 17 Claudio Bantaloukas 2011-04-06 08:35:27 UTC
Comment on attachment 23120 [details]
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!
Comment 18 Michael Haubenwallner 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
Comment 19 Perry Smith 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
Comment 20 Dr. David Kirkby 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
Comment 21 Michael Haubenwallner 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."
Comment 22 Paul Pryor 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.
Comment 23 Dr. David Kirkby 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
Comment 24 Dr. David Kirkby 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
Comment 25 David Edelsohn 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.
Comment 26 Michael Haubenwallner 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.
Comment 27 Dr. David Kirkby 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
Comment 28 Daniel Richard G. 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.
Comment 29 Paul Pryor 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.
Comment 30 Daniel Richard G. 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?
Comment 31 mrgcc 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
Comment 32 vladimir penev 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
Comment 33 vladimir penev 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
Comment 34 Daniel Richard G. 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").
Comment 35 vladimir penev 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.
Comment 36 Daniel Richard G. 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.
Comment 37 Michael Haubenwallner 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.
Comment 38 Jackie Rosen 2014-02-16 10:01:33 UTC Comment hidden (spam)