Re: why does -fno-pic coge generation on x64 require the large model?

[Ian Lance Taylor <iant@google.com>]

Eli Bendersky <eliben@gmail.com> writes:

>>> What I'm trying to see is how to convince GCC to generate NON-PIC code
>>> and link it into a shared library for x64. I only managed to do this
>>> with "-fno-PIC -mcmodel=large", and I wonder why with other memory
>>> models it doesn't work out. I suspect this has to do with some
>>> artifact of x64's addressing modes for symbol offsets.
>>
>> Yes.  If it were easy to permit non-PIC x86_64 code in a shared library,
>> gcc would do it.  But the only way to do that is, as you say, to use the
>> large memory model, which is relatively inefficient.
>>
>
> Yes, I realize this. Hence my original question - *why* is the large
> memory model the only way to do it? I know it's relatively
> inefficient, because it's the most general and flexible in terms of
> addressing. Why aren't the small & medium models flexible enough?

It's straightforward if you think about it and try to write down the
actual code sequences.

To write position independent code you need to be able to write a
position independent reference to a global variable which may be defined
in a different shared library.  When compiling with -fPIC the compiler
arranges to load the address of the global variable from the GOT.  The
dynamic linker fills in the GOT at runtime.  The GOT is always in the
same shared library, so you can reasonably use a 32-bit PC-relative
reference (this assumes that a single shared library will be 2G or less
in total address space, which is a reasonable assumption).  Of course,
you pay the price of a double indirection for each reference to a global
variable.

When you don't compile with -fPIC, then global variables are referenced
directly, rather than via a GOT.  When a shared library not loaded in
the low 32 bits of memory needs to refer to a global variable loaded in
a different shared library also not loaded in the low 32 bits of memory,
then the library needs to use a 64-bit address.  The compiler will only
generate a 64-bit address when using the large model.


>> The x86 shared library loader has a kludge where pages that contain
>> non-PIC code are remapped and relocated, so every process ends up with
>> its own copy of each relocated page.  This is provided for
>> compatibility with older libraries.  x86_64 is a new architecture, so
>> it wasn't necessary to provide backwards compatibility for non-PIC
>> libraries.
>
> So non-PIC code on x86_64 is actually different from non-PIC code on
> x86? It *doesn't* need page relocation? What's non-PIC about it then,
> and again, why only the large memory model allows it?

Code on x86 is different from code on x86_64 because it uses a different
instruction set.  There is no limitation on x86 non-PIC code in a shared
library because non-PIC x86 code uses a 32-bit absolute address to refer
to a global variable, and that is enough to refer to a shared library
loaded anywhere in the address space.

Ian