Comment 3 for bug 139435

PIE without PIC is possible, because every hard-coded address in the generated code gets entered into a table of TEXTRELs in the binary. The dynamic linker rewrites these addresses (read: rewrites executable code) at load time, giving slowdowns and crippling certain security enhancements. The level at which this crippling can be addressed is debatable.

On mitigation of the crippling of such security enhancements, PaX for example has textrel emulation that allows exactly one cycle of mprotect(...PROT_WRITE) mprotect(...PROT_EXEC) on a library after it's loaded iff it contains textrels. A ret2libc chain can mmap() a library, mprotect(...PROT_WRITE), memcpy(shellcode), mprotect(...PROT_EXEC) if it likes, and then can execute injected code; however, such an attack pretty much owns the execution flow, and (because glibc for some unknown reason contains the string '/bin/sh' like 7 times) can just return to system('/bin/sh') even without knowing the address of the stack (which, by the way, you typically need for these long chains). (About to file a glibc bug...)

On x86-64, you definitely use PIC because it causes no performance loss due to the special addressing modes x86-64 supplies to support PIC natively.