[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 Jackie Rosen jackie.rosen at hushmail dot com changed: What|Removed |Added CC||jackie.rosen at hushmail dot com --- Comment #38 from Jackie Rosen jackie.rosen at hushmail dot com --- *** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Marked for reference. Resolved as fixed @bugzilla.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #37 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-04-16 13:29:06 UTC --- A few more references: The fix for this one issue is: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134 But this introduces /usr/ccs/bin/as coredump during gcc bootstrap (strstream.o): https://www-304.ibm.com/support/docview.wss?uid=isg1IV01126 Just guessing, but maybe the whole thing was introduced by: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87535 Based on the filesets shown in the APARs for each AIX release/TL/SP, here's a list of maybe broken/working AIX levels, although I'm unable to verify for sure, as the broken machines got the interim fix installed here for IV01126 (supersedes interim fix for IZ98134): +--++ | broken since | fixed since | -+--++ AIX 5.3 TL9 | works | TL10 | SP6 (1107) | still broken | TL11 | SP6 (1107) | SP8 (1140) | TL12 | SP3 (1107) | SP5 (1140) | -+--++ AIX 6.1 TL2 | works | TL3 | SP9 (1112) | still broken | TL4 | SP9 (1112) | SP11 (1140) | TL5 | SP5 (1112) | SP7 (1140) | TL6 | SP4 (1112) | SP6 (1140) | TL7 | works | -+--++ AIX 7.1 TL0 | SP3 (1115) | still broken | TL1 | works | -+--++ Even if AIX 7.1 TL0 SP4 was released at 1140 too, it doesn't seem to contain IV01126 - maybe TL0 SP5 will do.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 Daniel Richard G. skunk at iskunk dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #36 from Daniel Richard G. skunk at iskunk dot org 2012-04-12 16:28:36 UTC --- My sysadmin recently upgraded the troublesome AIX 5.3 machine in question, and this has made the linker issues go away. The minimal test case now passes, and I can compile and link programs again without any workarounds. This is true both for GCC 4.5.1 (same build as in the original report), and the older GCC 2.9 bundled with the system. I'll provide the same patch-level information as Paul Pryor did earlier: $ oslevel -s 5300-12-05-1140 $ ls -l /usr/bin/ld lrwxrwxrwx1 bin bin 15 Dec 02 2004 /usr/bin/ld - /usr/ccs/bin/ld $ ls -l /usr/ccs/bin/ld -r-xr-xr-x1 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 CodeProduct Id Feature Id Package Name Path: /usr/lib/objrepos bos.rte.bind_cmds 5.3.0.0 5765-E6200 bos I will be happy to provide additional details about the configuration of this system if anyone needs it. There does not appear to be anything left to do here as far as GCC is concerned, so I'm marking this bug as invalid. If anyone feels differently, feel free to change it back.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 vladimir penev vovata at gmail dot com changed: What|Removed |Added CC||vovata at gmail dot com --- Comment #32 from vladimir penev vovata at gmail dot com 2011-09-15 08:30:55 UTC --- An update on this subject at my side. After some interactions with IBM AIX support there is a fix https://www-304.ibm.com/support/docview.wss?uid=isg1IV06344 and after that the assembler doesn't crash any more and works as well in the same time. It has been validated on AIX 6.1 with GCC 4.5.2
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #33 from vladimir penev vovata at gmail dot com 2011-09-15 08:44:04 UTC --- An update on this subject at my side. After some interactions with IBM AIX support there is a fix https://www-304.ibm.com/support/docview.wss?uid=isg1IV06344 and after that the assembler doesn't crash any more and works as well in the same time. It has been validated on AIX 6.1 TL6 with GCC 4.5.2
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #34 from Daniel Richard G. skunk at iskunk dot org 2011-09-15 14:01:36 UTC --- (In reply to comment #33) Vladimir, this [GCC] bug report has nothing to do with the assembler segfaulting. The problem is that the linker can't link what the assembler is producing (ld: 0711-593 SEVERE ERROR).
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #35 from vladimir penev vovata at gmail dot com 2011-09-15 14:14:16 UTC --- Yes, it's true. And using the mentioned efix for AIX the problem doesn't exist any more, the assembler generates correct code and the linker links it as well. Nothing to do at GCC side. I just inform the affected people about the existing of a fix.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
mrgcc at mailinator dot com changed:
What|Removed |Added
CC||mrgcc at mailinator dot com
--- Comment #31 from mrgcc at mailinator dot com 2011-05-20 08:02:27 UTC ---
Hi *,
just my 2 cents
From my poor understanding, to mee this seems like an as issue.
From the same .s input the old and new as produces different .o files.
The dump util on the two .o shows more clear what the linker tries to say
testcode:
static int globstat;
int main() { static int innerstat; return 0;}
new as:
[48]m 0x 1 00x8f 0x .bs
-^
should be pointing to 68 = 0x44
and is illegal according to the specs
[49]m 0x0004-2 00x85 0x innerstat:V3
[50]m 0x 1 00x90 0x .es
[51]m 0x0010 1 10x64 0x .eb
[52]a1 2 0 0 0 0
[53]m 0x0020 1 10x65 0x .ef
[54]a1 0 2 0 0 0
[55]m 0x 1 00x8f 0x .bs
-^
[56]m 0x-2 00x85 0x globstat:S3
[57]m 0x 1 00x90 0x .es
[58]m 0x0038 2 10x6b 0x _test.rw_
[59]a4 0x 00 25500
[60]m 0x0038 2 10x6b 0x main
[61]a4 0x000c 00 17 1000
[62]m 0x0038 2 10x02 0x main
[63]a4 0x003c 00 2 1000
[64]m 0x0048 2 10x6b 0x .data
[65]a4 0x0004 00 25500
[66]m 0x004c 2 10x6b 0x TOC
[67]a4 0x 00 17 1500
[68]m 0x004c 3 10x6b 0x _test.bss_
[69]a4 0x0008 00 19900
old as:
[48]m 0x0044 1 00x8f 0x .bs
-^
IS pointing to 68 = 0x44
[49]m 0x0004-2 00x85 0x innerstat:V3
[50]m 0x 1 00x90 0x .es
[51]m 0x0010 1 10x64 0x .eb
[52]a1 0 1 0 0 0
[53]m 0x0020 1 10x65 0x .ef
[54]a1 0 2 0 0 0
[55]m 0x0044 1 00x8f 0x .bs
-^
[56]m 0x-2 00x85 0x globstat:S3
[57]m 0x 1 00x90 0x .es
[58]m 0x0038 2 10x6b 0x _test.rw_
[59]a4 0x 00 25500
[60]m 0x0038 2 10x6b 0x main
[61]a4 0x000c 00 17 1000
[62]m 0x0038 2 10x02 0x main
[63]a4 0x003c 00 2 1000
[64]m 0x0048 2 10x6b 0x .data
[65]a4 0x0004 00 25500
[66]m 0x004c 2 10x6b 0x TOC
[67]a4 0x 00 17 1500
[68]m 0x004c 3 10x6b 0x _test.bss_
[69]a4 0x0008 00 19900
Everything else is created in the object file (.bss .debug)
AFAIK the _test.bss_ csect is an outcome of the .lcomm pseudo-op
When adding a .csect _test.bss_[BS] the csect index in the toc is still 0. Even
worse: i get a duplicate toc entry for _test.bss_
I could add a new csect before each .bs to make it linkable, but gdb doesn't
find the stabs then...
Btw: this as issue doesn't seem new:
http://www.opensource.apple.com/source/cc/cc-798/cc/xcoffout.h
see #define DBX_STATIC_BLOCK_START
http://www.opensource.apple.com/source/gcc/gcc-934.3/gcc/README.RS6000
see AIX 4.3.0 assembler
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.17 14:05:46 CC||dje at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #25 from David Edelsohn dje at gcc dot gnu.org 2011-05-17 14:05:46 UTC --- GCC uses the AIX assembler and probably is the most heavy user of the assembler of all applications on AIX (IBM XL compilers generate object code directly). An upgrade to the AIX assembler has introduced a bug that can generate invalid object files. The is an AIX bug, not a GCC bug. The broken assembler is distributed in AIX 7.1 TL0, and updates for earlier levels of AIX: AIX 6.1 TL6 and AIX 5.3 TL12. A number of PMRs have been reported about the problem: PMR 32726, 379, 000 PMR 40999, 122, 000 (unable to compile after TL12 upgrade) PMR 13417, 005, 000 (assembler-compiler errors at TL12 update) An initial fix introduced other problems. A new fix is available, but it still is unclear when it generally will be available. APARs: IZ98134 for AIX 5.3 TL12 IZ98861 for AIX 6.1 TL6 IZ99344 for AIX 7.1 TL0 Other related APARs: IZ98226 IZ98385 IZ98477 IZ98732 IZ99107 The fixed assembler is available as an efix for customers who ask.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #26 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-05-17 14:52:36 UTC --- (In reply to comment #25) The fixed assembler is available as an efix for customers who ask. We did do this here, but the efix'ed assembler just dumps core upon some C++ construct found in strstream.cc (and others) - IBM is already aware of this.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #27 from Dr. David Kirkby david.kirkby at onetel dot net 2011-05-17 15:25:50 UTC --- (In reply to comment #25) The fixed assembler is available as an efix for customers who ask. Can you give me more precise details about how to get this. Who do I ask - I don't have a service contract for my old AIX box. I have a workaround for this, as someone sent me an older version of the assembler which works, but clearly using a later version would be preferable. Dave
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #28 from Daniel Richard G. skunk at iskunk dot org 2011-05-17 18:12:26 UTC --- (In reply to comment #25) An upgrade to the AIX assembler has introduced a bug that can generate invalid object files. The is an AIX bug, not a GCC bug. I'm not yet convinced that this is the case. It could well be that the assembler (or linker) is being more strict in how it interprets code. Does anyone here have the IBM XL compiler? It would be interesting to compare the assembly that it produces (I presume it can be made to generate assembly even if it normally emits object code directly) for the minimal test case to GCC's.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #29 from Paul Pryor ppryor63 at gmail dot com 2011-05-17 23:49:44 UTC --- (In reply to comment #28) (In reply to comment #25) An upgrade to the AIX assembler has introduced a bug that can generate invalid object files. The is an AIX bug, not a GCC bug. I'm not yet convinced that this is the case. It could well be that the assembler (or linker) is being more strict in how it interprets code. Does anyone here have the IBM XL compiler? It would be interesting to compare the assembly that it produces (I presume it can be made to generate assembly even if it normally emits object code directly) for the minimal test case to GCC's. If you would look at comment #2, that is what I did.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #30 from Daniel Richard G. skunk at iskunk dot org 2011-05-18 01:12:17 UTC --- (In reply to comment #29) If you would look at comment #2, that is what I did. Ah, thanks for the reminder. The generated assembly appears to include artifacts (e.g. type declarations) from system headers, however, likely from an #includestdio.h directive not in the C code as quoted. Could you provide the xlc assembly output from the minimal test-case program, which has no #includes, and return 0 as the only statement?
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #24 from Dr. David Kirkby david.kirkby at onetel dot net 2011-04-12 02:38:22 UTC --- (In reply to comment #23) (In reply to comment #22) I found an workaround. When I realized that /usr/bin/as was the culprit (from looking at IZ98134), I tried using as from other AIX box at TL4, and it worked out just fine. Here is what I did: Somehow find a copy of /usr/bin/as from older AIX box. That's fine if you have an older AIX box. Mine is already a relic - a 32-bit system with 332 MHz CPUs! Do you know how to find 'as' from the installation media? Can you email me a copy from an AIX 5.3 machine? david dot kirkby at onetel.net Someone kindly emailed me an older copy of as, so I did something like: # mv /usr/ccs/bin/as /usr/ccs/bin/as.nfg # cp /tmp/as /usr/ccs/bin/as (where the older 'as' was in /tmp) That has solved my problem. Of course it is not a perfect solution, but it does at least allow me to compile files now. Dave
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #21 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-04-08 07:53:44 UTC --- (In reply to comment #20) mean? Does this mean IBM consider it a GCC bug? I don't find the explanations on the page too useful. The notification for this APAR also contained this text: The record has been closed. A programming error was found. The problem will be corrected. A fix is pending.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #22 from Paul Pryor ppryor63 at gmail dot com 2011-04-08 19:56:15
UTC ---
I found an workaround. When I realized that /usr/bin/as was the culprit (from
looking at IZ98134), I tried using as from other AIX box at TL4, and it worked
out just fine. Here is what I did:
Somehow find a copy of /usr/bin/as from older AIX box. Put in your home
directory or anywhere you want. I would not recommend replacing /usr/bin/as
with older copy because AIX may need new as features somewhere.
Dump the specs for gcc to a file as follows:
gcc –dump-specs myspecs
Edit the myspecs file to force gcc to use your copy of as. Here is an example:
…
*invoke_as:
%{!S:-o %|.s |
/home/ppryor/bin/as %(asm_options) %m.s %A }
…
Then compile your code using this syntax:
gcc –specs=$HOME/myspecs –g –c file.c -o file
I believe it is very safe alternative. Gcc does not make use of any new
features in /usr/bin/as that I know of. And AIX's as is stand alone with no
dependencies.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #23 from Dr. David Kirkby david.kirkby at onetel dot net 2011-04-08 21:31:05 UTC --- (In reply to comment #22) I found an workaround. When I realized that /usr/bin/as was the culprit (from looking at IZ98134), I tried using as from other AIX box at TL4, and it worked out just fine. Here is what I did: Somehow find a copy of /usr/bin/as from older AIX box. That's fine if you have an older AIX box. Mine is already a relic - a 32-bit system with 332 MHz CPUs! Do you know how to find 'as' from the installation media? Can you email me a copy from an AIX 5.3 machine? david dot kirkby at onetel.net
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #18 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-04-07 07:59:00 UTC --- (In reply to comment #15) ld: 0711-596 SEVERE ERROR: Object expand.o An RLD for section 2 (.data) refers to symbol 852, but the storage class of the symbol is not C_EXT or C_HIDEXT. I got this when I tried to build GNU's make on 5.3 TL10 SP02 with just the assembler APAR. I tried two versions of GCC: 4.2.0 and 4.5.2. IBM is aware of the issue (via me and others). The last tidbit I have is that it appears as if it is another assembler bug but that is not confirmed yet. I don't have a fix nor do I have an APAR number yet. Looks like this one is it: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #19 from Perry Smith pedzsan at gmail dot com 2011-04-07 12:55:19 UTC --- Yes. Thats the one. Dave, First, I believe this link is a public facing interface to Fix Central http://www.ibm.com/support/fixcentral/ (it came from google). If not, post back, and I'll try and find one. I *think* you can do instfix IZx or something to that effect and it will say yea or nah as to if you have the APAR. I don't know for sure. I usually go by fileset and VRMF levels like bos.foo 4.3.2.1. I assume you know that each TL has its own APAR for each problem so you have to look for sister APARs. Fix central is suppose to be smart enough to do that but I'm not sure about instfix. Also you did flip around some things. 5.3 TL10 SP03 has the problem SP05 has the first fix but not the second. For 5.3 TL12, SP02 has the first fix as IZ81341. Note that the two issues are very similar. The error number changed and that is what I key off of. You can do oslevel -s to get the service pack level that you have installed. The reason I put the link to fix central is IBM charges for support -- not updates. As far as I can tell, anyone can go to fix central and download any fix they want. Hope this helps
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #20 from Dr. David Kirkby david.kirkby at onetel dot net 2011-04-07 17:15:07 UTC --- (In reply to comment #18) IBM is aware of the issue (via me and others). The last tidbit I have is that it appears as if it is another assembler bug but that is not confirmed yet. I don't have a fix nor do I have an APAR number yet. Looks like this one is it: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134 Yes, that looks like it. The title is just right. IZ98134: ASSEMBLER GENERATES INVALID OBJECT FILE WITH GCC-PRODUCED FILES But what does APAR status * Closed as program error. Problem conclusion * Fix logic handling debugging pseudo-ops. = mean? Does this mean IBM consider it a GCC bug? I don't find the explanations on the page too useful. Dave
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #17 from Claudio Bantaloukas rockdreamer at gmail dot com 2011-04-06 08:35:27 UTC --- Comment on attachment 23120 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23120 Patch to simply not use bss section with .bs, but private-data-section instead Hi *, I've been bitten by this bug too. Patch 23120 resolves the C_SECT issue for me, however I get a new error when compiling a c++ file. ld: 0711-380 STABSTRING ERROR: Symbol table entry 1246, object file ../libpkg_mka.a[DB 2MkAQuery.cpp.o] Length of stabstring in .debug section is invalid. The stabstring is being deleted. ld: 0711-380 STABSTRING ERROR: Symbol table entry 1248, object file ../libpkg_mka.a[Or aMkAQuery.cpp.o] Length of stabstring in .debug section is invalid. The stabstring is being deleted. collect2: ld returned 12 exit status --- Any suggestions on how to add more details this are welcome!
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #16 from Dr. David Kirkby david.kirkby at onetel dot net 2011-03-24 13:22:28 UTC --- (In reply to comment #15) Let me try and recap. The initial report was that 5.3 TL10 did *not* have the error. I discovered that 5.3 TL10 SP03 does. See [1]. APAR IZ81343[2] and its sister APARs addresses this issue. It is shipped (for example) in 5.3 TL10 SP05 as IZ81339. After you apply that APAR, you get a new issue where the linker now spews out: ld: 0711-596 SEVERE ERROR: Object expand.o An RLD for section 2 (.data) refers to symbol 852, but the storage class of the symbol is not C_EXT or C_HIDEXT. This is odd. I have -bash-4.1$ oslevel -rq Known Recommended Maintenance Levels 5300-12 5300-11 5300-10 5300-09 5300-08 5300-07 5300-06 5300-05 5300-04 5300-03 5300-02 5300-01 5300-00 and whilst I can't see how to get the information on the service pack, I have service pack 2. https://www-304.ibm.com/support/docview.wss?uid=isg1IZ83065 dated 17th Jan 2011. So why am I getting the error on this bug report (ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT) and not ld: 0711-596 SEVERE ERROR? If I understand you correctly, you are saying ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT) was fixed in AIX 5.3 5300-10 Service Pack 3, which is dated March 24, 2010 https://www-304.ibm.com/support/docview.wss?uid=isg1SSRVAIX53TL10071505_161 That is some 10 months prior to the service pack I have. I suspect I am mis-understanding something. I'm using a 32-bit RS/6000 7025 F50, with 4 x 332 MHz CPUs, 3 GB RAM, which I know is an antique in computer terms. Dave
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #11 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-03-23 07:46:49 UTC --- (In reply to comment #10) IZ81343 (or one of its sister APARs) fixes the original issue. But, it leaves a new issue. The new error looks like: Perry, have you seen this on AIX 5.3 or 6.1 ?
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 Dr. David Kirkby david.kirkby at onetel dot net changed: What|Removed |Added CC||david.kirkby at onetel dot ||net --- Comment #12 from Dr. David Kirkby david.kirkby at onetel dot net 2011-03-23 10:34:54 UTC --- I'm seeing this error on AIX 5.3. Two GNU projects effected by this are * GNU patch * GSL (GNU Scientific library) In the case of the former, if one configures with CFLAGS =-g0, so not to include debugging information, the problem goes away. So when one compiles GNU patch like this I see: gcc -c -DHAVE_CONFIG_H -Ded_PROGRAM=\/usr/bin/ed\ -I. -I. -g0 quotesys.c But the GSL Scientific library can't be compiled this way, as the users's -g0 gets in before the -g added by GSL, so one see something like: gcc -g0 -g foo.c which means the debugging information is still present.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #13 from Perry Smith pedzsan at gmail dot com 2011-03-23 13:26:10 UTC --- On Mar 23, 2011, at 2:47 AM, michael.haubenwallner at salomon dot at wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #11 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-03-23 07:46:49 UTC --- (In reply to comment #10) IZ81343 (or one of its sister APARs) fixes the original issue. But, it leaves a new issue. The new error looks like: Perry, have you seen this on AIX 5.3 or 6.1 ? 5.3 -- something. I thought I put it in my update. I can check when I get to work. Seems like it was tl10 but a later SP than others reported. Does that help? Perry
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #14 from Dr. David Kirkby david.kirkby at onetel dot net 2011-03-23 17:11:42 UTC --- Has anyone with an AIX support contract ever raised this issue with IBM? If so, is there a publicly viewable location for this? If not, can someone do it. My own RS/6000 is an ancient thing I personally own, and so I have no support contract at all. It seems to me it could be a gcc bug or a bug in the AIX assembler or linker. It would be interesting to try to replace the systems linker and assembler with versions from unpatched 5.3 or 6.1. That might give some clues. I can see this issue raised on an IBM AIX forum http://www.ibm.com/developerworks/forums/thread.jspa?threadID=348558 but don't know if its even being considered by IBM.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #15 from Perry Smith pedzsan at gmail dot com 2011-03-23 19:31:18 UTC --- Let me try and recap. The initial report was that 5.3 TL10 did *not* have the error. I discovered that 5.3 TL10 SP03 does. See [1]. APAR IZ81343[2] and its sister APARs addresses this issue. It is shipped (for example) in 5.3 TL10 SP05 as IZ81339. After you apply that APAR, you get a new issue where the linker now spews out: ld: 0711-596 SEVERE ERROR: Object expand.o An RLD for section 2 (.data) refers to symbol 852, but the storage class of the symbol is not C_EXT or C_HIDEXT. I got this when I tried to build GNU's make on 5.3 TL10 SP02 with just the assembler APAR. I tried two versions of GCC: 4.2.0 and 4.5.2. IBM is aware of the issue (via me and others). The last tidbit I have is that it appears as if it is another assembler bug but that is not confirmed yet. I don't have a fix nor do I have an APAR number yet. [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072#c7 [2] https://www-304.ibm.com/support/docview.wss?uid=isg1IZ81343
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #8 from Perry Smith pedzsan at gmail dot com 2011-03-18 17:10:32 UTC --- It appears that this not a gcc bug but an AIX bug. There is one change but more changes are needed. I'll try to update when I know more. Expect it to be a week or so.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #9 from Daniel Richard G. skunk at iskunk dot org 2011-03-18 18:05:13 UTC --- (In reply to comment #8) It appears that this not a gcc bug but an AIX bug. The error was precipitated by an AIX system update, but at the same time, it can be said that the AIX linker was previously being lenient in not requiring a csect declaration for the bss section. Whether this is an AIX bug or GCC bug isn't really relevant. IBM changed how the AIX linker operates, and GCC needs to be updated accordingly.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #10 from Perry Smith pedzsan at gmail dot com 2011-03-18 18:57:07 UTC --- IZ81343 (or one of its sister APARs) fixes the original issue. But, it leaves a new issue. The new error looks like: ld: 0711-596 SEVERE ERROR: Object expand.o An RLD for section 2 (.data) refers to symbol 852, but the storage class of the symbol is not C_EXT or C_HIDEXT. The word I have presently is that that too is going to turn out to be an AIX assembler error.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 Perry Smith pedzsan at gmail dot com changed: What|Removed |Added CC||pedzsan at gmail dot com --- Comment #7 from Perry Smith pedzsan at gmail dot com 2011-02-24 01:21:52 UTC --- This change must be within TL10 too. I'm at 5300-10-05-1036 and have the same issue. There are three APARs that came out in 5.3 TL10 SP02 that hit bind: IZ69311, IZ69515, and IZ70028. One APAR in SP03: IZ73713. And one in SP04: IZ82696.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #6 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-02-09 09:03:05 UTC --- (In reply to comment #5) Created attachment 23120 [details] Patch to simply not use bss section with .bs, but private-data-section instead I'm going to try this patch with gcc-4.2.4 now... This patch works quite well here.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 Michael Haubenwallner michael.haubenwallner at salomon dot at changed: What|Removed |Added CC||michael.haubenwallner at ||salomon dot at --- Comment #3 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-01-25 08:29:49 UTC --- Same here with gcc-4.2.4 on AIX5.3 after upgrading from TL10 to TL12. (need to figure out the exact details of the problem myself yet) Which information is necessary here to help this getting fixed?
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #4 from Michael Haubenwallner michael.haubenwallner at salomon dot
at 2011-01-25 12:52:22 UTC ---
What exactly is the difference for gcc between not initializing a static
variable and initializing it to zero?
This is the difference in the generated assembler file:
$ cat mytest.c
static int myvar;
int main(void)
{
return myvar;
}
#if defined(IVAL)
static int myvar = IVAL;
#endif
For the compilation:
$ gcc -g mytest.c -DIVAL=0
(success)
$ gcc -g mytest.c
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 29) in object
/tmp//cc26KLXk.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
collect2: ld returned 12 exit status
(fail)
For the analysis:
$ gcc -g -S mytest.c -o mytestu.s
$ gcc -g -S mytest.c -o mytest0.s -DIVAL=0
$ diff -u mytestu.s mytest0.s
--- mytestu.s 2011-01-25 13:39:43.0 +0100
+++ mytest0.s 2011-01-25 13:40:01.0 +0100
@@ -42,7 +42,7 @@
.byte 31
.align 2
FE..main:
- .bs _mytest.bss_
+ .bs _mytest.rw_[RW]
.stabx myvar:S-1,myvar,133,0
.es
_section_.text:
Both gcc-4.5.1 and gcc-4.2.4 do make this difference.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #5 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-01-25 15:40:07 UTC --- Created attachment 23120 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23120 Patch to simply not use bss section with .bs, but private-data-section instead I'm going to try this patch with gcc-4.2.4 now...
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
Paul Pryor ppryor63 at gmail dot com changed:
What|Removed |Added
CC||ppryor63 at gmail dot com
--- Comment #2 from Paul Pryor ppryor63 at gmail dot com 2010-11-10 13:01:48
UTC ---
I encountered the same problem in AIX 5.3 on both boxes that were patched to
5300-12-02-1036 recently. If you need any more information please contact me. I
am attaching all diagnostic information below.
---
$ oslevel -s
5300-12-02-1036
---
$ ls -l /usr/bin/ld
lrwxrwxrwx1 bin bin 15 Jun 10 2009 /usr/bin/ld -
/usr/ccs/bin/ld
$ ls -l /usr/ccs/bin/ld
-r-xr-xr-x1 bin bin 38942 Aug 06 17:05 /usr/ccs/bin/ld
$ lslpp -w /usr/ccs/bin/ld
FileFileset 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 CodeProduct Id Feature Id Package Name
Path: /usr/lib/objrepos
bos.rte.bind_cmds 5.3.0.40
5765-E6200 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:t...@s128;r1;;03;,0,140,0
.stabx
__uint128_t:t...@s128;r2;;03;,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
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #1 from Daniel Richard G. skunk at iskunk dot org 2010-10-19 21:51:44 UTC --- I'd like to add: We've been able to work around this issue in our C codebase simply by ensuring that every static variable is initialized with a value. The bug behavior makes the uninitialized ones easy to track down as a matter of course. However, we can't do the same for our C++ codebase. There is at least one static declaration (std::__ioinit) in the C++ header files that we can't touch, so unless we turn off debug information altogether, there's not much of a way to avoid the linker error.
