Hi NG

I use AIX 5.3, GCC 4.2.2 and ld 1.65.2.4 (2/8/07).

I have a problem when linking some binaries which are part of our product.
I could reduce the problem to a hello-world program. I get the following
errors when linking my hello-world program with the libraries of our
product:

ld: 0711-783 WARNING: TOC overflow. TOC size: 955784 Maximum size: 65536
Extra instructions are being generated for each reference to a TOC
symbol if the symbol is in the TOC overflow area.
ld: 0711-780 SEVERE ERROR: Symbol .global constructors keyed to
..._.._.._.._.._gcc_4.2.2_libstdc___v3_src_locale_ inst.cc_6FCA3617_17007445(entry
14303) in object
/opt/pware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.2/../../../ppc64/libstdc++.a[locale-inst.o]:
Relocation overflow in reference to: .text (entry 712)
Address: 0x00009f80; RLD type: R_RBR; RLD length: 26
ld: 0711-780 SEVERE ERROR: Symbol .global constructors keyed to
..._.._.._.._.._gcc_4.2.2_libstdc___v3_src_wlocale _inst.cc_76D38880_3E573169(entry
13434) in object
/opt/pware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.2/../../../ppc64/libstdc++.a[wlocale-inst.o]:
Relocation overflow in reference to: .text (entry 992)
Address: 0x00009ca8; RLD type: R_RBR; RLD length: 26
collect2: ld returned 12 exit status


The g++ call looks like this:

g++ -o testprog -maix64 -Wl,-bbigtoc -Wl,-brtl
testprog.o -lLib1 -lLib2 -lLib3 -lodm -lc_r -lld -ldl -lstdc++ -lclntsh -lpthread
-lz -lm_r

Most of these libraries are unnecessary for this hello-world program and
when I leave them, I have no problems building my test program. E.g. when I
leave -lLib2 -lLib3 the no error occurs. So I suppose the error is in one
of these two libraries. Of course I need the libraries for the mentioned
binaries of our product, so I cannot solve the problem by leaving out these
libs.
I googled "ld: 0711-780" and found some results which didn't really help me.
I tried different compiler and linker options but no one solved the problem
(-mlongcall, infos got from -bnoquiet, ...).

1. Is this a known problem?
2. Does it have to do with the TOC overflow warning? (Please note that I
already link with -bbigtoc)
3. What does this error description mean and what is meant by "Symbol
..global constructors"? I don't understand it.

Let me know if you need some more info to be able to help.
Thanks in advance!

Regards, Chris

On Jan 18, 2:55 pm, "Christian Meier" <chris@no_spam.com> wrote:
> Hi NG
>
> I use AIX 5.3, GCC 4.2.2 and ld 1.65.2.4 (2/8/07).
>
> I have a problem when linking some binaries which are part of our product.
> I could reduce the problem to a hello-world program. I get the following
> errors when linking my hello-world program with the libraries of our
> product:
>
> ld: 0711-783 WARNING: TOC overflow. TOC size: 955784 Maximum size: 65536
> Extra instructions are being generated for each reference to a TOC
> symbol if the symbol is in the TOC overflow area.
From
http://www-304.ibm.com/jct09002c/isv...sp?oid=1:15856
....
On AIX 4.x there is no limit for TOC size. You can use -bbigtoc flag
and get around MAX TOC size using regular ld/bind. You will still get
the WARNING: TOC overflow message. This warning is expected whenever
TOC overflow occurs and the -bbigtoc option is used.

So i would assume the same for AIX 5.3

hth
hajo

"Hajo Ehlers" <service@metamodul.com> schrieb im Newsbeitrag
news:9e4fa7e3-6e5e-4d0f-8ebb-7a90346a24c0@k2g2000hse.googlegroups.com...
> On Jan 18, 2:55 pm, "Christian Meier" <chris@no_spam.com> wrote:
>> Hi NG
>>
>> I use AIX 5.3, GCC 4.2.2 and ld 1.65.2.4 (2/8/07).
>>
>> I have a problem when linking some binaries which are part of our
>> product.
>> I could reduce the problem to a hello-world program. I get the following
>> errors when linking my hello-world program with the libraries of our
>> product:
>>
>> ld: 0711-783 WARNING: TOC overflow. TOC size: 955784 Maximum size:
>> 65536
>> Extra instructions are being generated for each reference to a
>> TOC
>> symbol if the symbol is in the TOC overflow area.
> From
> http://www-304.ibm.com/jct09002c/isv...sp?oid=1:15856
> ...
> On AIX 4.x there is no limit for TOC size. You can use -bbigtoc flag
> and get around MAX TOC size using regular ld/bind. You will still get
> the WARNING: TOC overflow message. This warning is expected whenever
> TOC overflow occurs and the -bbigtoc option is used.
>
> So i would assume the same for AIX 5.3
>
> hth
> hajo


Thanks for your answer.

This warning is not my problem. I posted it because I don't know whether it
is relevant or not for the error which occurs while linking.
Btw, I use the -bbigtoc option as mentioned in my first post.

>> 2. Does it have to do with the TOC overflow warning? (Please note that I
>> already link with -bbigtoc)


Regards, Chris

>>> Hi NG
>>>
>>> I use AIX 5.3, GCC 4.2.2 and ld 1.65.2.4 (2/8/07).
>>>
>>> I have a problem when linking some binaries which are part of our
>>> product.
>>> I could reduce the problem to a hello-world program. I get the following
>>> errors when linking my hello-world program with the libraries of our
>>> product:
>>>
>>> ld: 0711-783 WARNING: TOC overflow. TOC size: 955784 Maximum size:
>>> 65536
>>> Extra instructions are being generated for each reference to a
>>> TOC
>>> symbol if the symbol is in the TOC overflow area.
>> From
>> http://www-304.ibm.com/jct09002c/isv...sp?oid=1:15856
>> ...
>> On AIX 4.x there is no limit for TOC size. You can use -bbigtoc flag
>> and get around MAX TOC size using regular ld/bind. You will still get
>> the WARNING: TOC overflow message. This warning is expected whenever
>> TOC overflow occurs and the -bbigtoc option is used.
>>
>> So i would assume the same for AIX 5.3
>>
>> hth
>> hajo
>
>
> Thanks for your answer.
>
> This warning is not my problem. I posted it because I don't know whether
> it is relevant or not for the error which occurs while linking.
> Btw, I use the -bbigtoc option as mentioned in my first post.
>
>>> 2. Does it have to do with the TOC overflow warning? (Please note that I
>>> already link with -bbigtoc)
>
>
> Regards, Chris
>

Hi NG

I could not solve the problem above by myself in the meantime.
Finally, some AIX guys were able to help.
Here is the last mail they've written to me which includes the solution:

> This is a bug in gcc (or g++), as evidenced by locale-init.o (and I
> suspect wlocale-init.o).
>
> There are multiple .text csects in locale-init.o, and there is a branch
> from 1 csect to another. When the linker assigns addresses to the
> csects, the csects are far enough apart that the branch overflows.
> Normally, the overflowing branch instruction would be replaced (by the
> linker) with a branch to a branch, ultimately reaching the desired target
> instruction.
>
> Unfortunately, the referenced symbol used for the branch causes the
> overflow fixup code to fail. In order for branches to be fixed up
> properly, the branch has to be a branch to the target symbol, not the
> target plus an offset. That is, if you have :
> .extern .foo
> bl .foo+4
>
> This instruction can't be fixed up, because of the "+4".
>
> In locale-init.o, symbol 8818 is a csect containing 2 labels: symbol
> 9656 and 9753. Symbol 9565 has an address of 0, while symbol 9753 has
> an address of 0x130
>
> The branch instruction is in the csect at symbol 14092, whose only label
> is at 14094. The address of the branch is 0x9f7c, and it is generated as
> a branch to 0x130 (the address of symbol 9753).
>
> The relocation for this branch (which you can see by extracting
> locale-inst.o and running dump -X64 -r locale-inst.o | grep 0009f7c) is
> based on symbol 8818 (=3D0x2272).
>
> If the relocation were to symbol 9753, the target of the branch would be
> to the address of the referenced symbol with no offset, and fixup would
> work. Other branches were fixed up successfully.
>
> A workaround is to use -Wl,-bnoobjreorder. This keeps .text csects in
> the same object file together, so no branch overflow occurs.
> Nevertheless, the compiler problem should be reported to the gcc (g++)
> developers.
>
>
> (By the way, the limit on the size of a single csect containing branches
> to other csects is not explicitly documented, but it is implied by the
> PowerPC architecture, where the branch instruction is described. This is
> similar to the restriction on the target of a conditional branch
> instruction, which contains a signed, 16-bit offset.)
>

With the option -Wl,-bnoobjreorder everything works fine.
I've not reported the bug to gcc.

Greetings Chris