Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 158308 - gcj failure on ppc (.jar -> >jar.so)
gcj failure on ppc (.jar -> >jar.so)
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2005-05-20 10:42 EDT by Andrew Overholt
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-23 11:01:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew Overholt 2005-05-20 10:42:56 EDT
Description of problem:
Compiling one of the Eclipse jars, compilation fails.

Version-Release number of selected component (if applicable):

How reproducible:

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
Comment 1 Andrew Overholt 2005-05-20 13:30:40 EDT

wget http://overholt.ca/org.eclipse.jdt.ui_3.1.0.jar

Comment 2 Jakub Jelinek 2005-05-20 17:54:21 EDT
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.
Comment 3 Jakub Jelinek 2005-05-23 11:01:09 EDT
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
Comment 4 Bryce McKinlay 2005-05-26 14:11:41 EDT
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?
Comment 5 Gary Benson 2005-07-08 05:18:57 EDT
Note that this affects ppc64 as well as ppc.
Comment 6 Gary Benson 2006-01-06 05:18:04 EST
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.

Note You need to log in before you can comment on or make changes to this bug.