PIC on OSX's GCC

Why does th开发者_运维知识库e GCC on OSX 10.5 has the -fPIC option turned on by default? Afterall, doesn't it generate larger and slower code?

---

Unless your program has a lot of very small functions, all of which use global or static variables, or objective-c, any performance decrease or size difference will be unnoticeable. PIC isn't used for automatic local variables since they are already accessed using the stack. In functions which need it, the set up only requires four instructions, which isn't much compared to the code in the function. Each access using PIC is only one byte longer than an access without it, so again there isn't much difference.

If you are building for 64 bit, PIC will probably be smaller, and there will likely be no performance difference. The x86-64 architecture added a new instruction-relative addressing, which means there is no set up required for PIC. This new addressing mode is actually one byte shorter than encoding the absolute address in the instruction, since the SIB byte isn't used.

Finally, using PIC makes your code more secure. If your code has to be loaded at the same place every time, then someone could find the location of important functions and data and cause problems at runtime. However, if the OS can choose to load your code at a different address, anyone trying to cause problems has to find out where the functions and data structures are every time the program is run.