Mix PIC code and Non-PIC code
Hi folks,
I am trying to mix PIC and non-PIC code into one shared object library since some of the modules have significant amount of PIC overhead (it accesses a lot of global data and invokes a lot of external functions). The library works fine on Solaris 10 x86 platform, but I got the following errors on amd64 platform. I am using sun studio 11 by the way.
dl failure on line 714Error: failed /PrtReliabilityDir/JDKs/jdk1.6/jre/lib/amd64/server/libjvm.so, because ld.so.1: java: fatal: relocation error: R_AMD64_32: file /PrtReliabilityDir/JDKs/jdk1.6/jre/lib/amd64/server/libjvm.so: symbol (unknown): value 0xfffffd7ffe600000 does not fit
So is this a bug? Thanks,
-Xiaobin
[709 byte] By [
jxlu] at [2007-11-26 11:11:55]
# 1
You should not put non-PIC code in a shared library. The library cannot actually be shared if it contains any non-PIC code. You wind up with most of the disadvantages of shared libraries, and almost none of the advantages.
If you really can't stand the overhead of PIC access, consider putting that part of the code into a static (.a) library and linking it to the main program.
The error message you are getting looks like you are mixing 32-bit into a 64-bit program. You can't do that. All the code must be compiled in 64-bit mode.
Run the "file" command on every .o in your application (before putting them into a library), and see if any files are reported as 32-bit code.
If none of the code is actually 32-bit code, you probably have run into a compiler bug. If you are not already using Sun Studio 11, upgrade to it. In any event, apply all the latest compiler patches. You can find them here:
http://developers.sun.com/sunstudio/downloads/patches/index.jsp
If that doesn't fix the problem, try to create a small test case that demonstrates the problem and file a bug report at bugs.sun.com. (If you have a service contract with Sun, use your Sun support channel instead.)
# 2
Putting on-pic code in a shared library works sometimes because
the runtime linker can go through and patch up every reloction
in the code (as if you were doing it at link time). But this only
works for some kinds of relocations.
It is sometimes possible to compile your non-PIC code with
a special option to use less efficient NONPIC relocations, which can
be patched up by the runtime linker.
It is much simpler to just use PIC everywhere.
Officially this is not a bug, we don't promise your program will
work if you try to link non-pic code into a shared library.
But there are sometimes workarounds to make it work.
So the library you are mixing your code in is libjvm.so?
You can find out more specific information about relocations by
reading the Linker and Libraries Guide on docs.sun.com.
You can also ask linker-related questions on the alias tools-linking@opensolaris.org
--chris
# 3
Thanks for the reply.
I installed Solaris 10 u2 on my Ultra 20 opteron box. Then I downloaed Sun Studio 11. After that, I tried to apply the patch I got from updatemanager. However, I failed to do so. I took a look at the log files for installing these patches. Almost all of the log files show the same error as following:
jaws:/var/sadm/patch/121022-02 4 % more log
pkgadd: ERROR: The package <SPROl90s> is currently installed on the system in the
global zone. To install the new instance of this package in the global
zone only, you must specify the -G option. To install the new instance
of this package in all zones you must first remove the existing instance
of this package from the global zone first (via pkgrm) and then install
the new instance of this package in all zones.
pkgadd: ERROR: package <SPROl90s> cannot be installed on this system/zone
I have no idea of what this means. I would like to file a bug on this. Could anyone point me the product and category for studio 11.
Thanks again.
jxlu at 2007-7-7 3:26:27 >
# 4
I'd love to compile our code (libjvm.so, yes, hotspot VM) with PIC flag. However, some of our experiments show that by compiling some of the object files, e.g. garbage collection code, in non-PIC mode, the GC pause time decreases by more 10%.
Another way to work around this, as pointed above, is to compile VM code with launcher (java). However, it might be difficult to do so since we don't own the launcher code. I know, it sounds ridiculous, but that is the reality...
jxlu at 2007-7-7 3:26:27 >
# 5
> jaws:/var/sadm/patch/121022-02 4 % more log
> kgadd: ERROR: The package <SPROl90s> is currently
> installed on the system in the
> global zone. To install the new instance of this
> package in the global
> zone only, you must specify the -G option.
This is a documented problem with Solaris 10 and zones. As explained in the error message, you must add the -G option when installing the patches.
Refer to the Sun Studio Installation Guide for more information.
