Description of problem: Compiling one of the Eclipse jars, compilation fails. Version-Release number of selected component (if applicable): 4.0.0-7 How reproducible: Always. Steps to Reproduce: 1. wget http://people.redhat.com/overholt/org.eclipse.jdt.ui_3.1.0.jar 2. gcj -g -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -O2 \ -o org.eclipse.jdt.ui_3.1.0.jar.so ./plugins/org.eclipse.jdt.ui_3.1.0.jar Actual results: Lots of error messages like this: /tmp/ccaw11gC.s:5156326: Error: operand out of range (0x000000000000c318 is not between 0xffffffffffff8000 and 0x0000000000007fff) Expected results: No output; .jar.so generated
Try: wget http://overholt.ca/org.eclipse.jdt.ui_3.1.0.jar instead.
I believe you just hit a ppc architectural limitation. Although the linker supports multi-got, none of the .o files that are linked together can be too big, even with -fPIC. The above .jar file results in 212MB of assembly, but the problem is that it exceeds 64KB .got2 section size. If each .o file has < 64KB .got2, then multi-got can handle creating even very large libraries, but unfortunately compiling a .jar file as a hole results in a single .s file. I'm afraid the only solution for this is to compile individual classes or some subsets of them and then link everything together.
Maybe when the current immature IMA framework is replaced with something usable GCC will be able to spit out separate .s files for smaller chunks, or e.g. have per function-group got instead of per-file. But that will certainly not happen overnight.
I think the best solution for this is to implement proper support for the BC-ABI in the C++ compiler (ie for CNI). This will mean we can make most Java symbols private for the BC-ABI, vastly reducing the number of GOT entries. Presumably, private symbols will not require entries in the GOT?
Note that this affects ppc64 as well as ppc.
Andrew Haley wrote: > The power PC has no instructions that can access a full 64-bit > immediate datum from a register. However, it has an instruction > that can load via a register, so something like > > ldx r1, 334(r2) > > will do a full 64-bit load. In position-independent code, the way > to load a 64-bit constant is to keep a register that points to the > base of a constant pool and use indexed addressing from that > register. > > The trouble is that the offset field in an indexed load instruction > (such as the one above) is 16 bits long, and that places an absolute > 64k byte limit on the size of the constant pool. > > This applies to statically-allocated data as well as constants, > becasue you access static data by loading a relative address from a > table. It's a fundamental design restriction due to the processor > architecture. It can be avoided. but only at the cost of generating > more instructions, which gcj doesn't do.