This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix libjava x86-64 multilib
- From: Ulrich Weigand <weigand at immd1 dot informatik dot uni-erlangen dot de>
- To: jakub at redhat dot com
- Cc: aoliva at redhat dot com, bo at sonofthor dot dk, gcc-patches at gcc dot gnu dot org
- Date: Thu, 3 Oct 2002 01:01:20 +0200 (MET DST)
- Subject: Re: Fix libjava x86-64 multilib
Jakub Jelinek wrote:
>On Wed, Oct 02, 2002 at 05:04:57PM -0300, Alexandre Oliva wrote:
>> On Oct 2, 2002, "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com> wrote:
>>
>> > Same on s390x. The linker will build a shared library from non-PIC
>> > objects, but it will crash at runtime (unless you ensure that all
>> > other referenced objects are within +-2GB).
>>
>> Is +-2GB a reasonable assumption given the way the kernel chooses the
>> location where shared libraries are loaded? I suppose it might be,
>> and then you might want to use pass_all for now
>
>It is not. Consider say taking address of function which has PLT slot in
>main binary. The shared library will have R_390_PC32DBL reloc for this,
>yet the binary will be some ~ 0x4000000000 bytes away.
Indeed. B.t.w. this is not just a theoretical possibility, but we've
seen this happen quite a number of times in customer bug reports;
the typical case being something like the Apache mod_perl module,
which is a shared library that is linked against the static libperl.a
archive, which by default contains objects compiled without -fpic.
That mod_perl will reliably crash when loaded ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de