c++ - ¿Por qué no usar siempre fpic(código independiente de la posición)?
gcc (2)
En algunas arquitecturas, incluida x86, -fPIC genera un código mucho peor (es decir, una llamada de función) para cargas / almacenes de datos. Si bien esto es tolerable para las bibliotecas, es indeseable para los ejecutables.
Uno de los principales puntos de venta del conjunto de instrucciones amd64 (y también el reciente gnu-x32 ABI) fue la adición de instrucciones de "carga / almacenamiento relativas a PC", que resuelven el problema de eficiencia.
Tenga en cuenta que los sistemas reforzados normalmente habilitan -fPIE para todos los ejecutables, ya que permite la aleatoriedad del diseño del espacio de direcciones.
Esta pregunta ya tiene una respuesta aquí:
Leí this post en PIC y parece que siempre es bueno usar PIC (siempre que sea exe / static / share llibrary).
¿Cuáles son las desventajas?
¿Hay ejemplos elaborando cuándo no usar PIC?
La respuesta aceptada en la pregunta vinculada es muy simplista y solo muestra una cosa que difiere entre el código PIC y el código no PIC, la generación de saltos que son relativos en lugar de absolutos.
Cuando crea un código PIC, no solo el código es independiente de la posición, sino también los datos. Y no se puede abordar todo el código o los datos simplemente mediante el uso de compensaciones relativas, tiene que resolverse en tiempo de carga (cuando la biblioteca / programa se carga en la memoria) o incluso durante el tiempo de ejecución.
Además, el uso de direccionamiento relativo significa que la CPU debe traducir las compensaciones relativas en direcciones absolutas, en lugar de que el compilador lo haga.
En el sistema con memoria virtual a menudo no hay necesidad de gastar tiempo de carga o ejecución en estas resoluciones de direcciones relativas cuando el compilador puede hacerlo de una vez por todas.