Bug 158308 - gcj failure on ppc (.jar -> >jar.so)
Summary: gcj failure on ppc (.jar -> >jar.so)
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-20 14:42 UTC by Andrew Overholt
Modified: 2007-11-30 22:11 UTC (History)
0 users

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

Attachments (Terms of Use)

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 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 17:30:40 UTC

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


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.

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