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

[Eli Bendersky]

On Mon, Nov 7, 2011 at 17:37, Ian Lance Taylor <iant@google.com> wrote:
> Eli Bendersky <eliben@gmail.com> writes:
>
>> I'm experimenting with generating PIC and non-PIC code on x64 Ubuntu.
>> It's possible to generate non PIC code as follows:
>>
>>   gcc -fno-PIC -mcmodel=large -shared -c file.c
>>
>> However, I noticed that for other models (i.e. -mcmodel=small, or by
>> default, without the -mcmodel argument), the code being generated is
>> not really suitable for PIC as it has problematic load-time
>> relocations.
>>
>> My question is - why is the large model required to generate true PIC code?
>
> It's odd to try to create PIC while using -fno-PIC.  I think you must
> have some goal in mind for what you want your generated code to look
> like, but I don't know what that is.  It most likely does not correspond
> to gcc's goal when using -fno-PIC, which is to not generate PIC.
>

As I read my question, I realize my intention has not been clear
enough. When I wrote "not really suitable for PIC", I actually meant
"not really suitable for a shared library". I will try to clarify:

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.

I should also add that my intention here is just curiosity. I was
trying to understand how PIC code works on x64, and got intrigued by
the fact that GCC seemingly forces me to use PIC code for shared
libraries on this architecture, unlike x86 where non-PIC code in
shared libraries is fine.

Eli