* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/hardened: pic-guide.xml
@ 2011-07-11 15:07 JosA MarAa Alonso (nimiux)
0 siblings, 0 replies; only message in thread
From: JosA MarAa Alonso (nimiux) @ 2011-07-11 15:07 UTC (permalink / raw
To: gentoo-commits
nimiux 11/07/11 15:07:16
Added: pic-guide.xml
Log:
New Spanish translation
Revision Changes Path
1.1 xml/htdocs/proj/es/hardened/pic-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/pic-guide.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/pic-guide.xml?rev=1.1&content-type=text/plain
Index: pic-guide.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide lang="es">
<title>Introducción al Código Independiente de la Posición</title>
<author title="Autor">
<mail link="solar@gentoo.org">solar</mail>
</author>
<author title="Editor">
<mail link="pappy@gentoo.org">Alexander Gabert</mail>
</author>
<author title="Traductor">
<mail link="nimiux"/>
</author>
<abstract>
Lo que cualquier desarrollador debe saber sobre el Código Independiente de
la Posición
</abstract>
<!-- El contenido de este documento es de dominio públic, diviértase -->
<license/>
<version>1.2</version>
<date>2005-10-11</date>
<chapter>
<title>Introducción a PIC (Código Independiente de la Posición)</title>
<section>
<body>
<p>
El código PIC se diferencia radicalmente del código convencional en la forma
en que se llama a las funciones y se opera con variables de datos.<br/>
A estas funciones se accede a través de una tabla de indirecciones, la
"Tabla Global de Desplazamientos" ("Global Offset Table" o GOT), se accede
usando el nombre reservado "_GLOBAL_OFFSET_TABLE_" por una convención en
el software.<br/>
El mecanismo exacto utilizado depende de la arquitectura hardware, pero
normalmente se reserva un registro especial de la máquina para definir
la localización de la GOT cuando se entra en una función.<br/>
La razón detrás de esta acceso indirecto a las direcciones, es generar
código que pueda se accedido independientemente de la dirección cargada
en ese momento.<br/>
En una librería PIC real sin relocalizaciones en el segmento de texto,
únicamente los símbolos exportados a la "Tabla Global de Desplazamientos"
necesitan ser actualizados en tiempo de ejecución en el espacio de
direcciones del proceso que está corriendo dependiendo de la dirección
de carga actual de las distintas librerías compartidas (shared).
</p>
<p>
Del mismo modo, las llamadas procedimentales a funciones definidas
globalmente son redirigidas a través de la "Tabla de Enlazado de
Procedimientos" ("Procedure Linkage Table" o PLT) que reside en el
segmento de datos de la imagen principal. De nuevo, esto se hace para
evitar modificaciones del segmento de texto en tiempo de ejecución.
</p>
<p>
El enlazador-editor crea la Tabla Global de Desplazamientos y la Tabla de
Enlazado de Procedimientos cuando combina ficheros objeto PIC en una
imagen apropiada para el mapeo en el espacio de direcciones del proceso.
También recolecta todos los símbolos que se pueda necesitar el
enlazador-editor en tiempo de ejecución y las almacena junto con los
bits de texto y datos de la imagen. Otro símbolo reservado, _DYNAMIC
se usa para indicar la presencia de las estructuras de enlazado en tiempo
de ejecución. Cada vez que se relocaliza _DYNAMIC a 0, no hay necesidad
de invocar el enlazador-editor en tiempo de ejecución. Si este símbolo es
distinto de cero, apuntará a la estructura de datos desde la cual se puede
derivar la localización de la información necesaria para la relocalización
e información de los símbolos. Esto es usado notablemente por el módulo
de inicio, crt0, crt1S y más recientemente por Scrt1. La estructura
_DYNAMIC es localizada por convención al comienzo del segmento de datos
de la imagen a la que pertenece.
</p>
<p>
En la mayoría de arquitecturas, cuando se compila el código fuente a
código objeto, se necesitará especificar si el código objeto debe ser
independiente de posición o no. En otras arquitecturas no se hace esta
distinción, normalmente debido que todo el código objeto es independiente
de la posición en virtud de la Interfaz Binaria de Aplicación
("Application Binary Interface" o ABI), o menos frecuentemente porque
la dirección de carga del objeto se fija en tiempo de compilación, lo
cual implica que las librerías compartidas no están soportadas en estas
plataformas. Si un objeto se compila como independiente de la posición
(PIC), entonces el sistema operativo puede cargar el objeto en cualquier
dirección cuando lo prepara para su ejecución. Esto implica un tiempo
extra para sustituir las referencias a direcciones directas por
direcciones relativas generadas en tiempo de compilación. También implica
un espacio extra para mantener información que ayude al cargador a rellenar
las direcciones no resueltas en tiempo de ejecución.
Consecuentemente, los objetos PIC son normalmente más grandes y lentos que
los objetos que no son PIC. La ventaja de compartir código de librerías en
disco y en memoria, compensa estos problemas ya que el código PIC en
las librerías compartidas es reutilizado.
</p>
<p>
Se requiere que Los objetos que son parte de una librería compartida
sean compilados usando PIC. Consecuentemente, libtool construye objetos
PIC para el uso con librerías compartidas y objetos que no son PIC para
el uso con librerías estáticas. Cada vez que libtool indica al compilador
que genere un objeto PIC, también define el símbolo `PIC' del
preprocesador de modo que el código ensamblador tenga en cuenta si
reside en in objeto PIC o no.
</p>
<p>
Normalmente, cuando libtool compila los fuentes, generará un objeto `.lo'
como PIC, y un objeto `.o' como no PIC, y entonces usará el adecuado cuando
haya que enlazar ejecutables y librerías de varios tipos. En las
arquitecturas en las que no hay distinción, el fichero `.lo' en simplemente
un enlace simbólico al fichero `.o'.
</p>
<p>
En la práctica, se puede enlazar objetos PIC en un archivo estático para
que haya poca penalización en la ejecución y en la velocidad de carga, y
a menudo, se pueden enlazar de forma similar objetos que no sean PIC en
archivos compartidos.
</p>
<p>
Cuando se utiliza código independiente de la posición, las referencias
relocalizables se genera como una indirección que utiliza datos en el
segmento de datos del objeto compartido. El código del segmento de
texto no se puede modificar, y todas las actualizaciones de relocalización
se aplican a las correspondientes entradas en el segmento de datos.
</p>
<p>
Si un objeto compartido se construye a partir de código que no es
independiente de la posición, el segmento de texto normalmente requerirá
un mayor número de relocalizaciones realizadas en tiempo de ejecución.
Aunque el enlazador (en tiempo de ejecución) está preparado para realizar
esto, la sobrecarga del sistema que crea esto puede causar una seria
degradación de la rendimiento.
</p>
<p>
Puede identificar un objeto compartido que requiere relocalizaciones
contra su segmento de texto usando herramientas como 'readelf -d foo' e
inspeccionado la salida de cualquier entrada TEXTREL. El valor de la entrada
TEXTREL es irrelevante. Su presencia en un objeto compartido, indica que
existe una relocalización de texto.
</p>
<p>
Referencias:
</p>
<ul>
<li>
<uri link="link.5.html">NetBSD link(5) Manual de Formatos de Fichero</uri>
</li>
<li>
<uri
link="http://sources.redhat.com/autobook/autobook/autobook_71.html#SEC71">
Autobook (Position Independent Code). Capítulo 10.2.1</uri>
</li>
<li>
<uri
link="http://docs.sun.com/app/docs/doc/817-1984">docs.sun.com: Guía
del Enlazador y Librerías
</uri>
</li>
<li>
Enlazadores y Cargadores
<uri link="http://www.iecc.com/linker/linker08.html">capítulo 8</uri> y
<uri link="http://www.iecc.com/linker/linker10.html">capítulo 10</uri>
</li>
</ul>
</body>
</section>
</chapter>
</guide>
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2011-07-11 15:07 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-11 15:07 [gentoo-commits] gentoo commit in xml/htdocs/proj/es/hardened: pic-guide.xml JosA MarAa Alonso (nimiux)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox