Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 158308

Summary: gcj failure on ppc (.jar -> >
Product: [Fedora] Fedora Reporter: Andrew Overholt <overholt>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-23 15:01:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Andrew Overholt 2005-05-20 14:42:56 UTC
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
2. gcj -g -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -O2 \
   -o ./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; generated

Comment 1 Andrew Overholt 2005-05-20 17:30:40 UTC



Comment 2 Jakub Jelinek 2005-05-20 21:54:21 UTC
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 15:01:09 UTC
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 18:11:41 UTC
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 09:18:57 UTC
Note that this affects ppc64 as well as ppc.

Comment 6 Gary Benson 2006-01-06 10:18:04 UTC
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.