On 06/23/2011 02:35 PM, Agner Fog wrote: > I wonder why position-independent code (PIC) and global offset tables > (GOT) are used in shared objects (.so) when these features are wasting > resources and apparently unnecessary. The wasteful use of PIC and GOT in > Linux is apparent in the following questions: > > Question 1: > --------------- > To access a global or static variable in PIC, gcc first calculates a > self-relative address to the GOT, then loads a pointer from the GOT, > then accesses the variable through the pointer. This obviously makes the > code slower. Why not calculate a self-relative address to the variable > rather than to the GOT. The example below shows that this is possible > and it works fine. > > Question 2: > ---------------- > It is possible to put absolute addresses into a .so and it works. I > tried this in Ubuntu, and it works with 32 bit absolute addresses in a > 32 bit .so, and with 64 bit absolute addresses in a 64 bit .so. The only > thing that doesn't work is 32 bit absolute addresses in a 64 bit so. In > many cases, this is faster than making PIC. I guess this was implemented > for the sake of virtual tables, jump tables, etc. My question is: Does > this work in all versions of Linux, BSD, MacOS? Which platforms or > versions do not allow absolute addresses in shared objects? > > Question 3: > ---------------- > When I make a self-relative reference to a public variable in a 64-bit > .so I get the linker error: > relocation R_X86_64_PC32 against `VariableName' can not be used when > making a shared object; recompile with -fPIC > This message is illogical because the reference is indeed > position-independent. It appears only when the variable is public, not > when it is local. Think about what happens if the executable defines that same symbol. If that happens, all references to that symbol must refer to the same location in the executable. > Apparently, gcc avoids the problem by using a GOT > entry when the variable is public. I can solve the problem in assembly > by giving the variable two names, one public and one local, and making a > relative reference to the local name. > Why does gcc not use the same trick? Because it's broken: there can only be one instance of a symbol X in a running program, and every reference to X must refer to the same memory. Andrew.
