CÓMO localizar y corregir relocalizaciones .text (TEXTRELs)Asegúrese de leer la Introducción al código independiente de la posición antes de abordar esta guía. Actualmente esta guía está centrada en la arquitectura x86. La razón para ello es que la mayoría de los ficheros objeto están rotos debido a código ensamblador x86 mal escrito y esto es a su vez, en la mayoría de las ocasiones, debido a que esta arquitectura tiene muy pocos registros. Otras arquitecturas tienen un conjunto mayor de registros suficientes para poder reservar uno de ellos como el "registro PIC" sin tener impacto en el rendimiento. Cada arquitectura debe tener en cuenta el uso de PIC y sus implicaciones. La arquitectura x86 simplemente parece la predominante en el mundo de escritorio del código abierto. Actualizaremos el documento para otras arquitecturas aparte de la x86 a medida que obtengamos detalles y ejemplos útiles. 2. Buscando código objeto roto Antes de empezar a corregir algo, obviamente necesita saber en primer lugar si está roto o no, ¿de acuerdo?. Por esta razón, hemos desarrollado un conjunto de herramientas llamadas utilidades PaX. Si no está familiarizado con estas utilidades, debería leer la guía de utilidades PaX ahora mismo. Los usuarios de Gentoo simplemente necesitan hacer emerge pax-utils. Los usuarios de otros sistemas debería encontrar una copia del tarball con los fuentes en distfiles en un servidor réplica de Gentoo Mirror. Una vez que tenga las utilidades PaX preparadas en su sistema, podemos empezar a jugar con scanelf. Recuerde que, aunque estas utilidades se llaman utilidades PaX, realmente no necesitan PaX o algo similar a ello instalado en su sistema. El nombre es un artificio histórico y los intentos de encontrar un nombre mejor no han sido fructíferos. Echemos un vistazo para ver si su sistema tiene algún fichero roto.
Idealmente, scanelf no debería mostrar ninguna salida, pero en un sistema x86 system, esto sucede raramente. Aquí tenemos seis librerías com TEXTRELs dentro de ellas. Para averiguar rápidamente a qué paquete pertenecen estas librerías, los usuarios de Gentoo pueden hacer emerge portage-utils y utilizar qfile.
Ahora que conocemos los ficheros problemáticos, podemos decidir. Podemos enviar una incidencia al equipo de desarrollo del paquete (normalmente no podrán atención a la incidencia a no ser que también les enviemos la corrección). También podemos enviar una incidencia a Gentoo Bugzilla (lo cual es una forma vaga de resolverlo) o podemos corregir el problema nosotros mismos (es por lo que está leyendo esta guía ¿no?). Debe comprobar que la versión del paquete que está instalado en su distribución es la misma que la última publicada por el equipo de desarrollo del paquete. Quien sabe, quizá tenga suerte y alguien ya lo ha corregido. Si necesita obtener consejos sobre su trabajo, no dude en contactar con el equipo Gentoo Hardened. A veces puede topar con un paquete que contiene gran cantidad de TEXTRELs que parecen no tener relación con ensamblador. Esto puede ser simplemente debido a que los objetos no se compilaron adecuadamente con la opción PIC . La solución es muy simple: asegúrese de que cada fichero objeto está enlazado con el fichero compartido final usando las opción PIC apropiada (normalmente -fPIC). Por ejemplo, echemos un vistazo al paquete. Este paquete construye algunos módulos, sin embargo, solo compila algunos de los objetos con -fPIC los cuales se enlazan en el módulo final libsilc_core.so. ¡La salida de scanelf en este caso es muy extensa!.
¿Un TEXTREL en la función fgetc() de glibc?. O se está llamando a fgetc() desde ensamblador (y se debería tener en cuenta) o algo distinto está ocurriendo. Una buena regla a seguir es que si cada referencia a una función o variable provoca un TEXTREL y todo está escrito en código C, entonces el fichero no se construyó como PIC. Simplemente revise la salida de la construcción y compruebe si la orden para compilar incluyó -fPIC. Si no, corrija el sistema de construcción ya que no necesita indagar en el código fuente. ¡Hemos esquivado la bala en esta ocasión!. 3. Diseccionando código objeto roto Hemos identificado algunas librerías rotas y queremos corregirlas. El problema es que el código de la librería puede ser enorme. Puede que tenga miles de funciones que proceden de miles de ficheros objeto y de miles de líneas de código fuente que ocupan varios megabytes (entre el código fuente y los objetos compilados). ¿Por dónde demonios empezamos?. Una vez más "Super Ratón" scanelf está aquí para ayudarnos. Antes de sumergirse en el código fuente, comprobemos algunas librerías.
La salida anterior nos dice que las funciones cpu_flags e IDCT_mmx son las responsables de nuestros TEXTRELs. El primer campo indica que se está realizando un uso muy pobre de las referencias a memoria. Lamentablemente, el nombre simbólico de la memoria que se referencia no se almacena en el código del objeto (probablemente porque el código se ha escrito a mano en ensamblador), por lo tanto, necesitaremos investigar un poco. Aquí es donde los desplazamientos de las direcciones nos van a servir de ayuda junto con la utilidad objdump del paquete binutils. La primera dirección (por ejemplo 0x2FB3C) es el desplazamiento del TEXTREL mientras que la segunda dirección es el desplazamiento de la función (por ejemplo 0x2FB10). Acostúmbrese a esto ya que lo normal es no almacenar el nombre de los símbolos.
Como puede ver aquí, las dos líneas remarcadas en el cuerpo de cpu_flags hacen referencia a direcciones de memoria absolutas. En este caso, ambas referencia a la dirección de memoria 0x3d3d0. Ya que debe ser posible que este objeto se cargue en cualquier dirección, obviamente, el uso de una referencia absoluta no funcionará. Esto significa que cada vez que libsmpeg se carga en memoria, el cargador dinámico tiene que reescribir 0x3d3d0 a la dirección correcta, haciendo el cálculo correspondiente.
De nuevo, podemos ver que muchas funciones (como dv_parse_ac_coeffs_pass0 y _dv_idct_block_mmx) tienen referencias absolutas a memoria. Lo que podemos ver también es que algunas funciones hacen referencias a variables. Por ejemplo, dv_decode_vlc hace un mal uso de la variable dv_vlc_class_index_mask y dv_parse_video_segment hace un mal uso de la variable dv_parse_ac_coeffs. Estos problemas son más fáciles de localizar en el código fuente cuando se conoce el nombre del símbolo.
Parece que no hay nada nuevo aquí. El mal uso de la memoria en funciones como _ConvertMMXpII32_24RGB888 y que no hay nombre del símbolo indica que probablemente se trata de código escrito a mano en ensamblador. La función SDL_SoftStretch no utiliza correctamente el símbolo _copy_row, y debido a que se ha conservado el nombre del símbolo, es probable que se trata de código ensamblador en línea. 4. Buscando el código fuente roto Hemos identificado las funciones, y en algunas ocasiones las variables que nos están causando dolores de cabeza. Sin embargo, antes de que podamos corregir estos problemas, debemos encontrar las líneas exactas del código fuente que los provocan. Como sabemos los nombres de las funciones y también el nombre del símbolo o su posición relativa dentro de la función, podremos focalizar nuestros esfuerzo fácilmente. Sumergirnos el código fuente de libsmpeg Comencemos con libsmpeg. Sabemos que, las funciones cpu_flags y IDCT_mmx están rotas. Pero, ¿dónde están definidas?.
Como sospechábamos, las funciones cpu_flags y IDCT_mmx se han escrito en código ensamblador puro. Esto hace que el seguimiento de las referencias a memoria que no tienen nombre sea más sencillo ya que el código fuente debería parecerse bastante a la salida de objdump. Si revisamos la salida de arriba, sabemos que se utiliza la instrucción cpuid. Ya que no es una instrucción muy común, podemos buscarla en el código fuente.
En el ensamblador de GNU, los registros tienen como prefijo el carácter % y las constantes utilizan el prefijo $, por ello flags parece sospechoso. También parece coincidir con la salida de objdump mostrada anteriormente. Por tanto, ¿qué es flags?
Parece que flags es una variable local de datos en mmxflags_asm.S cuyas funciones acceden usando referencias absolutas a memoria en lugar de utilizar referencias relativas. Casi hemos terminado. Esto es todo lo que necesitamos. Comenzamos con la librería libsmpeg.so y seguimos el camino hasta la función cpu_flags y la variable flags en el fichero video/mmxflags_asm.S. No fue tan duro como parecía ¿no?. Si analizamos la función IDCT_mmx, encontramos un patrón similar.
Sumergirse en el código de libSDL De nuevo, antes de entrar en el detalle de cómo solucionar estos problemas, analicemos algunos ficheros fuentes para tener una mejor visión para identificar el código problemático.
Demasiado simple, la función _ConvertMMXpII32_24RGB888 hace referencia a la variable mmx32_rgb888_mask.
Otra incidencia de resolución rápida. Una referencia a la variable _copy_row en ensamblador. Si pudiéramos hacer que gcc gestione la referencia a _copy_row ... 5. Cómo escribir PIC (en teoría) Ahora sabemos el aspecto que tiene el código roto. Podemos señalar a partes del código y declarar con seguridad "esa parte está rota". Aunque esto es bueno, no nos ayudará mucho si no sabemos como debería estar escrita. Comencemos con algunas reglas prácticas. Reglas generales
Reglas específicas para la arquitectura x86
Registros PIC para cada arquitectura
6. Correcciones molde para PIC Si se encuentra con código que utiliza el registro PIC en código ensamblador en línea, una posible corrección podría ser la utilización de un registro diferente. Por ejemplo, la arquitectura x86 posee seis registros de propósito general (eax, ebx, ecx, edx, esi, edi). Si el código utiliza solo eax y ebx, simplemente cambie todas las referencias a ebx por referencias a ecx y ¡ha terminado!. Una solución más limpia podría consistir en indicar a gcc que localice los registros de la forma apropiada. Si el código ensamblador en línea no tiene en cuenta los registros que utiliza, cambie las referencias a ebx por referencias a r en la lista de objetos (clobber list), ya haga referencia a la variable usando su número. O, si el código ensamblador utiliza una instrucción que siempre llena ebx (por ejemplo cpuid), simplemente oculte el valor en otro registro (por ejemplo esi). Si nada de esto funciona, puede utilizar el método (más lento) push/pop ebx usando la pila.
Mucho código x86 MMX/SSE carga máscaras de bits desde variables locales ya que necesitan llenar un registro que es mayor (MMX/64bits o SSE/128bits) que el ancho de bit nativo (x86/32bits). Esto se realizar definiendo la máscara en los bytes consecutivos en memoria y haciendo que la CPU cargue los datos desde la región de memoria. Una forma de evitar esto consiste en ser más creativo en el uso de la pila. En lugar de utilizar referencias absolutas a memoria para la máscara, se carga en la pila un puñado de valores de 32 bits y se utiliza la referencia a memoria que especifica el registro esp. Una vez haya terminado, simplemente añada una constante a esp en lugar de extraerla ya que los valores actuales no son importantes una vez se hayan cargado en los registros MMX/SSE.
Hagamos que gcc se ocupe de ello Gran parte del código ensamblador en línea se ha escrito con los nombres de los símbolos colocados correctamente en el código. En lugar de escribir código para gestionar PIC en ensamblador, simplemente hagamos que gcc se ocupe de ello. Pase el símbolo a través de la lista de operadores de entrada como una restricción de memoria ("m") y gcc se ocupará de todo.
Si se obtiene una advertencia/error sobre alguna de las entradas de memoria indicando que debe ser un lvalue, entonces, normalmente esto significa que se está intentando pasar un puntero a una matriz o estructura en lugar de la localización de memoria propiamente dicha. Esto normalmente se corrige simplemente dereferenciando la variable en la lista de restricciones en lugar del propio código ensamblador. El código ensamblador escrito de forma manual a veces necesita acceder a variables (bien sean locales o globales). Si ninguno de los trucos indicados anteriormente funcionaron, puede afilar sus dientes y sumergirse en el código para escribir referencias PIC reales utilizando la GOT. Asegúrese de que tiene en cuenta la primera regla general: No mezcle código objeto PIC y no PIC. Eso probablemente requiera preprocesar el código ensamblador escrito a mano antes de ensamblarlo, de modo que un fichero fuente ensamblador con un sufijo .s no funcionará, necesita tener un sufijo .S. También tenga en cuenta que el uso de @GOTOFF retornará la variable mientras que el uso de @GOT retornará un puntero a la variable. Por lo tanto, acceder a la variable a través de @GOT requerirá dos pasos.
Debido a que ocultamos los detalles de PIC detrás del preprocesador, (define __PIC__), sabemos que se generará el código correcto para los casos PIC y no PIC. La función __i686.get_pc_thunk.bx es un método estándar para obtener la dirección de la GOT en tiempo de ejecución y almacenar el resultado en ebx. Este nombre tan curioso es el que utiliza gcc por convención cuando genera objetos PIC, por lo que hemos utilizado el mismo nombre. La notación @GOT y @GOTOFF le indica al ensamblador donde puede encontrar las variables en memoria. La .section .gnu.linkonce.t es útil ya que le indica al enlazador que únicamente incluya una instancia de esta función el código objeto final. Por lo que, si tiene varios ficheros que declaran la misma función, los cuales se compilan y enlazan en la misma librería final, el enlazador descartará todas las duplicadas de la función, salvando así espacio (lo cual es siempre algo bueno). 7. Cómo corregir PIC roto (en la práctica) Si los fragmentos de código anteriores están rotos, se estará preguntando ¿Cómo deberían ser?. Averigüémoslo.
|
|