Eli Bendersky <eliben@xxxxxxxxx> 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
