This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: difference between 32 bit and 64 bit .so


Ian Lance Taylor <iant@google.com> writes:

> Alan Modra <amodra@gmail.com> writes:
>
>>> I am wondering why this stops working on 64 bit machines?
>>
>> You'd sacrifice speed in executables if the compiler was forced to
>> generate code that could be used in shared libs.
>
> Another way to answer this is to observe that by default x86_64 uses the
> small memory model.  This means that non-PIC code uses 32-bit PC
> relative references for everything.  This means that in cases where the
> main executable overrides a symbol defined in a non-PIC shared library,
> the dynamic linker will only be able to resolve the reloc if the
> executable and the shared library have addresses within 32 bits.  Since
> the address space is 64 bits on x86_64, there is no way to guarantee
> that.
>
> I actually think that in general non-PIC shared libraries are useful,
> because they shift the PIC performance penalty to startup.  That is a
> poor choice in general, but a good choice for a long running program.
> Unfortunately there is no way to make it work on x86_64.
>
> Ian

2 options to make it work, if non-pic is still worth it on x86_64:

1) Use 64bit PC relative references.

2) Map objects close together and give runtime (load time) errors only
in cases where the relative distance actually does exceed 32bit. How
many binaries exceed 2GB size?

MfG
        Goswin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]