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.
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.
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
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?
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.
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...
(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.
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.
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.
(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.
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.
(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 ?
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.
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
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.
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
(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 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!
(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
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
(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
(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."
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.
(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
(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
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.
(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.
(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
(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.
(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.
(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?
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
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
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
(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").
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.
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.
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 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Marked for reference. Resolved as fixed @bugzilla.