Red Hat Bugzilla – Bug 158308
gcj failure on ppc (.jar -> >jar.so)
Last modified: 2007-11-30 17:11:06 EST
Description of problem:
Compiling one of the Eclipse jars, compilation fails.
Version-Release number of selected component (if applicable):
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
Lots of error messages like this:
/tmp/ccaw11gC.s:5156326: Error: operand out of range (0x000000000000c318 is not
between 0xffffffffffff8000 and 0x0000000000007fff)
No output; .jar.so generated
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
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
> 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.