.\" -*- coding: UTF-8 -*- .\" %%%LICENSE_START(PUBLIC_DOMAIN) .\" This is in the public domain .\" %%%LICENSE_END .\" Various parts: .\" Copyright (C) 2007-9, 2013, 2016 Michael Kerrisk .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH ld.so 8 "8 Mayo 2024" "Páginas de Manual de Linux 6.8" .SH NOMBRE ld.so, ld\-linux.so \- enlazador/cargador dinámico .SH SINOPSIS El enlazador dinámico puede ejecutarse bien indirectamente, al ejecutar un programa o biblioteca enlazado dinámicamente (en cuyo caso no pueden pasarse opciones en la línea de órdenes al enlazador dinámico y, en el caso del formato ELF, se ejecuta el enlazador dinámico que se encuentra almacenado en la sección \fB.interp\fP del programa), bien directamente ejecutando: .P \fI/lib/ld\-linux.so.*\fP [OPCIONES] [PROGRAMA [ARGUMENTOS]] .SH DESCRIPCIÓN Los programas \fBld.so\fP y \fBld\-linux.so*\fP encuentran y cargan las bibliotecas compartidas requeridas por un programa, preparan al programa para ejecutarse y lo ejecutan. .P Los ficheros binarios en Linux requieren enlace dinámico (enlace en tiempo de ejecución) a menos que se dé la opción \fB\- static\fP a \fBld\fP(1) durante la compilación. .P El programa \fBld.so\fP maneja ficheros binarios con el formato a.out, un formato usado hace tiempo. El programa \fBld\-linux.so*\fP maneja el formato ELF (\fB/lib/ld\-linux.so.1\fP para libc5, \fB/lib/ld\-linux.so.2\fP para glibc2), más moderno. Por lo demás, ambos tienen el mismo comportamiento y usan los mismos ficheros de configuración y programas (\fBldd\fP(1), \fBldconfig\fP(8) y \fI/etc/ld.so.conf\fP). .P Cuando se resuelven las dependencias de objetos compartidos, el enlazador dinámico empieza por comprobar cada dependencia para ver si contiene alguna barra (lo cual puede ocurrir si, al enlazar, definimos una ruta que contenía alguna). Si se encuentra una barra, la cadena se interpreta como un nombre de ruta (puede ser absoluto o relativo) y se cargará el objeto compartido con dicha ruta. .P Si la dependencia del objeto compartido no contiene ninguna barra, ésta se buscara en este orden: .IP (1) 5 Se utilizan los directorios especificados en el atributo de sección dinámica DT_RPATH del binario si está y si no existe el atributo DT_RUNPATH. .IP (2) Usando la variable de entorno \fBLD_LIBRARY_PATH\fP, salvo cuando se ejecute en modo seguro, en cuyo caso la variable será ignorada. .IP (3) Mediante los directorios definidos en el atributo de la sección dinámica de DT_RUNPATH del binario, si existe. Solo se buscará en estos directorios los objetos requeridos en las entradas de DT_NEEDED (dependencias directas) pero no en los descendientes de estos objetos. Éstos últimos deben tener su propia entrada DT_RUNPATH. Esto es distinto de DT_RPATH, que se usa para buscar a todos los descendientes en el árbol de dependencias. .IP (4) A partir del fichero de caché \fI/etc/ld.so.cache\fP, que contiene una lista compilada de bibliotecas candidatas encontradas previamente en la ruta de bibliotecas ampliada. Sin embargo, si el binario fue enlazado con la opción \fB\-z nodefaultlib\fP, se omitirán las bibliotecas que se encuentran en las rutas predeterminadas. Se prefieren los objetos compartidos instalados en directorios de capacidades de hardware (vea más adelante) antes que los otros. .IP (5) .\" En las rutas por defecto: \fI/lib\fP y \fI/usr/lib\fP (en algunas arquitecturas de 64 bits, las rutas por defecto para estos objetos compartidos son \fI/lib64\fP y \fI/usr/lib64\fP. Si el binario fue enlazado con la opción \fB\-z nodefaultlib\fP, se omite este paso. .SS "Token de cadena dinámica" En varios lugares, el enlazador expandirá los tokens de cadena dinámica: .IP \[bu] 3 En las variables de entorno \fBLD_LIBRARY_PATH\fP, \fBLD_PRELOAD\fP y \fBLD_AUDIT\fP, .IP \[bu] en los valores de las etiquetas de sección dinámica \fBDT_NEEDED\fP, \fBDT_RPATH\fP, \fBDT_RUNPATH\fP, \fBDT_AUDIT\fP y \fBDT_DEPAUDIT\fP, también binarios ELF, .IP \[bu] en varios argumentos de la orden \fBld.so\fP: \fB\-\-audit\fP, \fB\-\-library\-path\fP y \fB\-\-preload\fP, por último .IP \[bu] en el argumento del nombre de archivo de las funciones \fBdlopen\fP(3) y \fBdlmopen\fP(3). .P Los tokens sustituidos con como sigue: .TP \fI$ORIGIN\fP (o el equivalente \fI${ORIGIN}\fP) Esto se expandirá con el directorio que contiene el programa o los objetos compartidos. Por lo tanto, una aplicación que se encuentre en \fI/dir/app\fP se podría compilar con .IP .in +4n .EX gcc \-Wl,\-rpath,\[aq]$ORIGIN/../lib\[aq] .EE .in .IP para que encuentre el objeto compartido en \fIdir/lib\fP pudiendo el directorio \fI/dir\fP estar localizado en cualquier punto del árbol de directorios. Esto evita que las aplicaciones deban instalarse en un directorios concreto sino que podrán acceder a sus objetos compartidos desde cualquier directorio. .TP \fI$LIB\fP (o su equivalente \fI${LIB}\fP) Esto se interpretaría como \fIlib\fP o \fIlib64\fP según la arquitectura (lógicamente si es x86\-64 lo hará a \fIlib64\fP y si es x86\-32 lo hará a \fIlib\fP). .TP \fI$PLATFORM\fP (o su equivalente \fI${PLATFORM}\fP) .\" To get an idea of the places that $PLATFORM would match, .\" look at the output of the following: .\" .\" mkdir /tmp/d .\" LD_LIBRARY_PATH=/tmp/d strace -e open /bin/date 2>&1 | grep /tmp/d .\" .\" ld.so lets names be abbreviated, so $O will work for $ORIGIN; .\" Don't do this!! Esto se expandirá en una cadena de texto correspondiente al tipo de procesador del sistema (por ejemplo, "x86_64"). En algunas arquitecturas, el núcleo de Linux no proporciona una cadena de plataforma al enlazador dinámico. El valor de esta cadena se extrae de \fBAT_PLATFORM\fP en el vector auxiliar (consulte \fBgetauxval\fP (3)). .P Observe que los tokens de cadena dinámicas tienen que entrecomillarse correctamente cuando se definen a través de una shell para evitar que se interpreten como variables de entorno o de la propia shell. .SH OPCIONES .TP \fB\-\-preload\fP \fIlist\fP (a partir de glibc 2.33) Define el valor \fIstring\fP para \fIargv[0]\fP antes de ejecutar la aplicación. .TP \fB\-\-audit\fP\fI lista\fP Utilice los objetos nombrados en \fIlista\fP como auditores. Los objetos en \fIlista\fP ese delimitan entre si por dos puntos. .TP \fB\-\-glibc\-hwcaps\-mask\fP\fI lista\fP sólo busca en los subdirectorios definidos si están en \fIlista\fP. .TP \fB\-\-glibc\-hwcaps\-prepend\fP\fI lista\fP Busca los subdirectorios glibc\-hwcaps de la \fIlista\fP .TP \fB\-\-inhibit\-cache\fP No emplee \fI/etc/ld.so.cache\fP. .TP \fB\-\-library\-path\fP\fI ruta\fP Emplee \fIpath\fP en lugar de la configuración de la variable de entorno \fBLD_LIBRARY_PATH\fP (vea más adelante). Los nombres \fIORIGIN\fP, \fILIB\fP y \fIPLATFORM\fP se entienden dirigidos a la variable \fBLD_LIBRARY_PATH\fP. .TP \fB\-\-inhibit\-rpath\fP\fI lista\fP Ignora la información de RPATH y RUNPATH en los nombres de objeto en \fIlist\fP. Esta opción se ignora si la ejecución se realiza en modo seguro (vea más adelante). Los objetos de la lista se separan mediante espacio o con dos puntos. .TP \fB\-\-list\fP Lista todas las dependencias y cómo se resuelven. .TP \fB\-\-list\-diagnostics\fP (a partir de glibc 2.33) Muestra información de diagnóstico del sistema en formato no legible por humanos: por ejemplo algunas variables internas del cargador, el vector auxiliar (véase \fBgetauxval\fP(3)) y las variables de entorno. En algunas arquitecturas, la orden puede mostrar información adicional (como las características de la cpu usadas en la selección indirecta de funciones GNU en x86). \fB\-\-list\-tunables\fP (desde glibc 2.33) muestra los nombres y valores de todas las variables, junto con los valores mínimo y máximo permitidos. .TP \fB\-\-preload\fP \fIlist\fP (a partir de glibc 2.30) Carga previamente los objetos especificados en \fIlist\fP, separados entre si por dos puntos o por espacios. Estos objetos se cargarán previamente tal como se explica más adelante en la descripción de la variable \fBLD_PRELOAD\fP. .IP Contrariamente al use de \fBLD_PRELOAD\fP, la opción \fB\-\-preload\fP permite realizar una carga previa para un solo ejecutable sin afectar a las cargas de otras procesos hijos de éste que ejecuten un nuevo programa. .TP \fB\-\-verify\fP Comprueba que el programa está enlazado dinámicamente y que el enlazador dinámico puede tratarlo. .SH ENTORNO .\" Diversas variables de entorno influyen en el funcionamiento del enlazador. .SS "Modo de ejecución seguro" Por razones de seguridad, si el enlazador dinámico determina que un binario debe ejecutarse en modo de ejecución segura, se anularán los efectos de algunas variables de entorno, además esas variables se eliminan del entorno, de forma que el programa ni siquiera las ve. Algunas de estas variables de entorno afectan al funcionamiento del propio enlazador dinámico, y se describen a continuación. Otras variables de entorno tratadas de esta manera incluyen \fBGCONV_PATH\fP, \fBGETCONF_DIR\fP, \fBHOSTALIASES\fP, \fBLOCALDOMAIN\fP, \fBLD_AUDIT\fP, \fBLD_DEBUG\fP, \fBLD_DEBUG_OUTPUT\fP, \fBLD_DYNAMIC_WEAK\fP, \fBLD_HWCAP_MASK\fP, \fBLD_LIBRARY_PATH\fP, \fBLD_ORIGIN_PATH\fP, \fBLD_PRELOAD\fP, \fBLD_PROFILE\fP, \fBLD_SHOW_AUXV\fP, \fBLOCALDOMAIN\fP, \fBLOCPATH\fP, \fBMALLOC_TRACE\fP, \fBNIS_PATH\fP, \fBNLSPATH\fP, \fBRESOLV_HOST_CONF\fP, \fBRES_OPTIONS\fP, \fBTMPDIR\fP, y \fBTZDIR\fP. .P Un binario se ejecuta en modo seguro si la entrada \fBAT_SECURE\fP en el vector auxiliar (consulte \fBgetauxval\fP (3)) tiene un valor distinto de cero. Esta entrada puede tener un valor distinto de cero por varias razones: .IP \[bu] 3 Si difieren las ID de usuario reales y efectivas del proceso o las ID de grupo reales y efectivas. Esto suele ocurrir como resultado de la ejecución de una apliación con los bits activados de set\-user\-ID or set\-group\-ID. .IP \[bu] Un proceso ejecutado por un usuario distinto al administrador ejecuta un binario que confiere alguna capacidad al mismo. .IP \[bu] .\" Es posible que un módulo de seguridad de Linux haya definido un valor distinto de cero. .SS "Variables de entorno" Las variables de entorno más relevantes son las siguientes: .TP \fBLD_ASSUME_KERNEL\fP (desde glibc 2.2.3 hasta glibc 2.36) Cada objeto compartido puede indicarle al enlazador dinámico la versión mínima de ABI del núcleo que requiere. Este requisito está codificado en una sección de notas ELF que se puede ver mediante \fIreadelf\ \-n\fP en una sección etiquetada como \fBNT_GNU_ABI_TAG\fP. Al ejecutarse, el enlazador dinámico determina la versión de ABI del núcleo en ejecución y rechazará la carga de objetos compartidos que especifiquen versiones mínimas de ABI mayores que esa versión de ABI. .IP \fBLD_ASSUME_KERNEL\fP puede usarse para hacer que el enlazador dinámico asuma que se está ejecutando en un sistema con una versión de ABI de núcleo diferente. Por ejemplo, la siguiente orden hace que el enlazador dinámico asuma que se está ejecutando en Linux 2.2.5 al cargar los objetos compartidos requeridos por \fImyprog\fP: .IP .in +4n .EX $ \fBLD_ASSUME_KERNEL=2.2.5 ./myprog\fP .EE .in .IP En sistemas que proporcionan múltiples versiones de un objeto compartido (en diferentes directorios en la ruta de búsqueda) que tienen diferentes requisitos mínimos de versión de ABI del kernel, se puede usar \fBLD_ASSUME_KERNEL\fP para seleccionar la versión del objeto que se usa (dependiendo del orden de búsqueda del directorio). .IP Históricamente, el uso más común de la función \fBLD_ASSUME_KERNEL\fP era seleccionar manualmente los antiguos subprocesos POSIX de LinuxThreads en sistemas que proporcionaban tanto LinuxThreads como NPTL (que normalmente era el predeterminado); consulte \fBpthreads\fP (7). .TP \fBLD_BIND_NOW\fP (desde glibc 2.1.1) Si su valor es distinto de cero, hará que el enlazador dinámico resuelva todos los símbolos al iniciarse el programa en lugar de hacerlo la primera vez que se hace referencia a ellos. Esto es especialmente útil cuando estamos usando un depurador. .TP \fBLD_LIBRARY_PATH\fP Lista de directorios donde encontrar librerías ELF durante la ejecución. Los componentes de la lista estarán separados entre si o bien por punto y coma o bien por dos puntos no siendo posible usar una secuencia de escape para ninguno de ellos. Si la longitud del nombre del directorio es cero, se entenderá el directorio actual. .IP Esta variable se ignora en el modo de ejecución seguro. .IP Dentro de los nombres de ruta especificados en \fBLD_LIBRARY_PATH\fP, el enlazador dinámico expande los tokens \fI$ ORIGIN\fP, \fI$ LIB\fP e \fI$ PLATFORM\fP (o las versiones que usan llaves alrededor de los nombres) como se ha descrito anteriormente en \fITokens de cadena dinámica\fP. Por ejemplo, para buscar una biblioteca en el subdirectorio \fIlib\fP o \fIlib64\fP dentro del directorio que contiene el programa a ejecutar: .IP .in +4n .EX $ \fBLD_LIBRARY_PATH=\[aq]$ORIGIN/$LIB\[aq] prog\fP .EE .in .IP (Observe el uso de comillas simples para evitar que la shell interprete \fI$ORIGIN\fP y \fI$LIB\fP como variables) .TP \fBLD_PRELOAD\fP Una lista con una serie adicional, especificados por el usuario, de objetos compartidos ELF para ser cargados antes que todos los demás. Esto puede usarse para anular en casos concretos algunas funciones en otros objetos compartidos. .IP Los componentes de esta lista puede separarse entre si mediante dos puntos o mediante punto y coma. No existe una secuencia de escape para estos dos caracteres. Se buscan los objetos empleando la regla definida en DESCRIPTION, se van añadiendo al mapa de enlaces de izquierda a derecha según se especifica en la lista. .IP En el modo de ejecución seguro, se ignoran los nombres de ruta de precarga si contienen barras. Además, los objetos compartidos se precargan solo desde los directorios de búsqueda estándar y solo si tienen habilitado el bit set\-user\-ID (lo cual no es habitual). .IP .\" Tested with the following: .\" .\" LD_PRELOAD='$LIB/libmod.so' LD_LIBRARY_PATH=. ./prog .\" .\" which will preload the libmod.so in 'lib' or 'lib64', using it .\" in preference to the version in '.'. Dentro de los nombres especificados en la lista \fBLD_PRELOAD\fP, el enlazador dinámico interpreta los tokens \fI$ ORIGIN\fP, \fI$ LIB\fP e \fI$ PLATFORM\fP (o los equivalente con llaves alrededor de los nombres) como se ha descrito anteriormente en \fItokens de cadena dinámica\fP. (Véase también la explicación sobre el entrecomillado en el apartado \fBLD_LIBRARY_PATH\fP.) .IP Existen varias formas de indicar las bibliotecas que se deben precargar, siguiendo este orden: .RS .IP (1) 5 La variable de entorno \fBLD_PRELOAD\fP. .IP (2) Indicar en la línea de órdenes la opción \fB\-\-preload\fP cuando se ejecute directamente el enlazador dinámico. .IP (3) Desde el archivo \fI/etc/ld.so.preload\fP (explicado más adelante). .RE .TP \fBLD_TRACE_LOADED_OBJECTS\fP Si está definido (cualquiera que sea su valor) hará que el programa liste sus dependencias como si fuese ejecutado por \fBldd\fP(1) en lugar de directamente. .P Hay muchas más variables más o menos crípticas, muchas de ellas anticuadas o para uso interno. .TP \fBLD_AUDIT\fP (desde glibc 2.4) Una lista de objetos compartidos ELF especificados por el usuario que se cargarán antes que todos los demás en un espacio de nombres de enlazador separado (es decir, uno que no interfiera en el enlazado de símbolos del proceso) Estos objetos se pueden usar para auditar la operación del enlazador dinámico. Los elementos de la lista están separados entre si por dos puntos y no existe ninguna secuencia de escape para este separador. .IP Se ignora \fBLD_AUDIT\fP en el modo de ejecución seguro. .IP El enlazador dinámico notificará a los objetos compartidos de auditoría en los llamados puntos de control de auditoría, por ejemplo, cargando un nuevo objeto compartido, resolviendo un símbolo o llamando a un símbolo de otro objeto compartido (llamando a una función apropiada dentro del objeto compartido de auditoría). Para obtener más información, consulte \fBrtld\-audit\fP (7) La interfaz de auditoría es en gran medida compatible con la proporcionada en Solaris, como se describe en su \fILinker and Libraries Guide\fP, en el capítulo \fIRuntime Linker Auditing Interface\fP. .IP Dentro de los nombres especificados en la lista \fBLD_AUDIT\fP, el enlazador dinámico interpreta los tokens \fI$ ORIGIN\fP, \fI$ LIB\fP e \fI$ PLATFORM\fP (o los equivalentes con llaves alrededor de los nombres) como se ha descrito anteriormente en \fItokens de cadena dinámica\fP. (Véase también la explicación del entrecomillado en el apartado \fBLD_LIBRARY_PATH\fP.) .IP .\" commit 8e9f92e9d5d7737afdacf79b76d98c4c42980508 A partir de la versión 2.13 de glibc, en el modo de ejecución segura, los nombres de la lista de auditoría que contienen barras se ignoran y solo se cargan los objetos compartidos en los directorios de búsqueda estándar que tienen habilitado el bit set\-user\-ID. .TP \fBLD_BIND_NOT\fP (a partir de glibc 2.1.95) Si esta variable de entorno se establece en una cadena no vacía, no actualiza GOT (tabla de compensación global) y PLT (tabla de vinculación de procedimientos) después de resolver un símbolo de función. Si con el uso de esta variable, añadimos \fBLD_DEBUG\fP (con las categorías \fIbindings\fP y \fIsymbols\fP), se pueden observar todos los enlaces de funciones en tiempo de ejecución. .TP \fBLD_DEBUG\fP (desde glibc 2.1) Muestra información detallada de depuración sobre el funcionamiento del enlazador dinámico. El contenido de esta variable es una o más de las siguientes categorías, separadas por dos puntos, comas o (si se entrecomilla el valor) espacios: .RS .TP 12 \fIhelp\fP Si asignamos el valor \fIhelp\fP a esta variable, no se ejecutará el programa y se mostrará un mensaje de ayuda informando acerca de las categorías que se pueden definir en esta variable de entorno. .TP \fIall\fP Imprime información para la depuración (salvo \fIstatistics\fP ni \fIunused\fP; vea a continuación. .TP \fIbindings\fP Muestra información sobre la definición a la que está vinculado cada símbolo. .TP \fIfiles\fP Muestra el progreso del archivo de entrada. .TP \fIlibs\fP Muestra las rutas de búsqueda de las librerias. .TP \fIreloc\fP Muestra el procesamiento de reubicación. .TP \fIscopes\fP Muestra información del alcance. .TP \fIstatistics\fP Muestra estadísticas de reubicación. .TP \fIsymbols\fP Muestra las rutas de búsqueda para cada búsqueda de símbolo. .TP \fIunused\fP Determina los DSO's sin usar. .TP \fIversions\fP Muestra las dependencias de esa versión. .RE .IP Desde glibc 2.3.4, \fBLD_DEBUG\fP se ignora en el modo de ejecución segura, salvo que exista el archivo \fI/etc/suid\-debug\fP (el contenido del archivo es irrelevante). .TP \fBLD_DEBUG_OUTPUT\fP (desde glibc 2.1) Por defecto, la salida \fBLD_DEBUG\fP se escribe a error estándar. Si se define \fBLD_DEBUG_OUTPUT\fP, la salida se escribe en el nombre de ruta especificado por su valor, con el sufijo "." (punto) seguido del ID de proceso adjunto al nombre de la ruta. .IP \fBLD_DEBUG_OUTPUT\fP se ignora en el modo de ejecución seguro. .TP \fBLD_DYNAMIC_WEAK\fP (desde glibc 2.1.91) Por defecto, cuando el enlazador busque una biblioteca compartida para encontrar algún símbolo, tomará la primera definición que encuentre. .IP Las versiones de glibc anteriores a 2.2, lo hacían de otro modo: si el enlazador encontraba un símbolo débil, seguiría buscando hasta encontrar uno más fuerte en el resto de bibliotecas compartidas. Si encontrase uno más fuerte, lo usaría.En caso de no encontrar otro más fuerte, usaría la definición del débil. Si no se encontrasen más simbolos, el enlazador dinámico usuará el símbolo débil encontrado al inicio .IP .\" More precisely 2.1.92 .\" See weak handling .\" https://www.sourceware.org/ml/libc-hacker/2000-06/msg00029.html .\" To: GNU libc hacker .\" Subject: weak handling .\" From: Ulrich Drepper .\" Date: 07 Jun 2000 20:08:12 -0700 .\" Reply-To: drepper at cygnus dot com (Ulrich Drepper) El antiguo comportamiento de glibc no era el estándar. (La práctica estandarizada es que la distinción entre símbolos débiles y fuertes debería tener efecto solo durante del enlazado estático). En glibc 2.2, el enlazador dinámico se modificó para tener el comportamiento actual, que era el comportamiento que ya proporcionaban la mayoría de las otras implementaciones. .IP Si se define la variable de entorno \fBLD_DYNAMIC_WEAK\fP (con cualquier valor) se tendrá el antiguo comportamiento glibc (no estándar), mediante el cual un símbolo débil en una biblioteca compartida puede ser anulado por un símbolo fuerte posteriormente descubierto en otra biblioteca compartida. (Observe que incluso cuando se establece esta variable, un símbolo fuerte en una biblioteca compartida no anulará una definición débil del mismo símbolo en el programa principal). .IP A partir de glibc 2.3.4, \fBLD_DYNAMIC_WEAK\fP se ignora en el modo de ejecución seguro. .TP \fBLD_HWCAP_MASK\fP (desde glibc 2.1 hasta glibc 2.38) Máscara para capacidades de hardware. A partir de la versión 2.26 de glibc, la opción puede ser ignorada si glibc no incluye soporte para tunables. .TP \fBLD_ORIGIN_PATH\fP (desde glibc 2.1) .\" Used only if $ORIGIN can't be determined by normal means .\" (from the origin path saved at load time, or from /proc/self/exe)? Ruta donde se encuentra el binario. .IP A partir de glibc 2.4, \fBLD_ORIGIN_PATH\fP se ignora en el modo de ejecución seguro. .TP \fBLD_POINTER_GUARD\fP (glibc desde la versión 2.4 hasta la 2.22) .\" commit a014cecd82b71b70a6a843e250e06b541ad524f7 Definir a 0 para deshabilitar la protección del puntero. Cualquier otro valor habilita la protección del puntero (lo hará por defecto). La protección de punteros es un mecanismo de seguridad mediante el cual se alteran de forma semi\-aleatoria el código almacenado en la memoria del programa grabable (devuelven direcciones guardads por \fBsetjmp\fP(3) o punteros de función utilizados por varios componentes internos de glibc) para dificultar que un atacante puede usarlos si se produce un desbordamiento de búfer o un ataque a la pila. Desde la versión 2.23 de glibc, \fBLD_POINTER_GUARD\fP ya no se puede deshabilitar la protección de punteros. .TP \fBLD_PROFILE\fP (a partir de glibc 2.1) El nombre de un objeto compartido (único) que se va a perfilar, especificado como nombre de ruta o como soname. La salida del perfilado se agrega al archivo cuyo nombre es: \%LD_PROFILE_OUTPUT\fI/\:\fP$ LD_PROFILE\fI.profile\fP . .IP Desde glibc 2.2.5, \fBLD_PROFILE\fP utiliza una ruta predeterminada diferente en el modo de ejecución segura. .TP \fBLD_PROFILE_OUTPUT\fP (desde glibc 2.1) Directorio donde se debe escribir la salida de \fBLD_PROFILE\fP. Si esta variable no está definida, o está definida como una cadena vacía, se toma por defecto \fI/var/tmp\fP. .IP \fBLD_PROFILE_OUTPUT\fP se ignora en modo de ejecución segura; en su lugar se utiliza siempre \fI/var/profile\fP. .TP \fBLD_SHOW_AUXV\fP (desde glibc 2.1) Si esta variable de entorno está definida (con cualquier valor), muestra la matriz auxiliar enviada desde el núcleo (vea también \fBgetauxval\fP (3)). .IP A partir de glibc 2.3.4, \fBLD_SHOW_AUXV\fP se ignora en el modo de ejecución seguro. .TP \fBLD_TRACE_PRELINKING\fP (desde glibc 2.4 hasta glibc 2.35) .\" (This is what seems to happen, from experimenting) Si se define esta variable de entorno, se hará un seguimiento de la vinculación previa del objeto cuyo nombre está asignado a esta variable de entorno. (Utilice \fBldd\fP (1) para ver los objetos que se pueden rastrear.) Si no se reconoce el nombre del objeto, se rastrea toda la actividad de preenlace. .TP \fBLD_USE_LOAD_BIAS\fP (desde glibc 2.3.3 hasta glibc 2.35) .\" http://sources.redhat.com/ml/libc-hacker/2003-11/msg00127.html .\" Subject: [PATCH] Support LD_USE_LOAD_BIAS .\" Jakub Jelinek De forma predeterminada (es decir, si esta variable no está definida), los ejecutables y los objetos compartidos preenlazados respetarán las direcciones base de sus objetos compartidos dependientes, pero los ejecutables independientes de la posición (PIE) (no vinculados previamente) y otros objetos compartidos no los respetarán. Si \fBLD_USE_LOAD_BIAS\fP se define con el valor 1, tanto los ejecutables como los PIE respetarán las direcciones base. Si \fBLD_USE_LOAD_BIAS\fP se define con el valor 0, ni los ejecutables ni los PIE respetarán las direcciones base. .IP A partir de glibc 2.3.3 se ignora esta variable en el modo de ejecución seguro. .TP \fBLD_VERBOSE\fP (a partir de glibc 2.1) Si se le asigna un valor de una cadena no vacía y si se ha establecido la variable de entorno \fBLD_TRACE_LOADED_OBJECTS\fP, se generará información sobre la versión del símbolo sobre el programa. .TP \fBLD_WARN\fP (desde glibc 2.1.3) Si se le asigna como valor una cadena no nula, avisará si detecta símbolos no resueltos. .TP \fBLD_PREFER_MAP_32BIT_EXEC\fP (solo en x86\-64 y desde glibc 2.23) Según la guía de optimización del software Intel Silvermont, para las aplicaciones de 64 bits, el rendimiento de la predicción de ramas puede verse afectado negativamente cuando el objetivo de una rama está a más de 4 GB de distancia de ella. Si esta variable de entorno está configurada (con cualquier valor), el enlazador dinámico primero intentará mapear páginas ejecutables usando \fBmmap\fP (2) \fBMAP_32BIT\fP y volverá a mapear si ese intento falla. NB: MAP_32BIT se asignará a los 2 GB (no 4 GB) del espacio de direcciones. .IP Debido a que \fBMAP_32BIT\fP reduce el rango de direcciones disponible para que el diseño del espacio de direcciones sea aleatorio (ASLR), \fBLD_PREFER_MAP_32BIT_EXEC\fP siempre está deshabilitado en el modo de ejecución segura. .SH ARCHIVOS .TP \fI/lib/ld.so\fP enlazador/cargador dinmico .TP \fI/lib/ld\-linux.so.\fP{\fI1\fP,\fI2\fP} Enlazador/cargador dinámico ELF .TP \fI/etc/ld.so.cache\fP Archivo que contiene una lista de directorios donde encontrar objetos compartidos y una lista ordenada de los candidatos. Consulte \fBldconfig\fP(8). .TP \fI/etc/ld.so.preload\fP Archivo que contiene una lista de objetos compartidos ELF separados entre si por espacios en blanco que se cargarán antes del programa. Vea el apartado anterior \fBLD_PRELOAD\fP. Si se emplean tanto \fBLD_PRELOAD\fP como \fI/etc/ld.so.preload\fP, las bibliotecas especificadas por \fBLD_PRELOAD\fP se precargan primero. \fI/etc/ld.so.preload\fP tiene efecto en todo el sistema, lo que hace que las bibliotecas especificadas se carguen previamente para todos los programas que se ejecutan en el sistema. (En general, no suele ser una opción ideal y por lo tanto, solo se emplea como una solución de emergencia, por ejemplo, como una solución temporal para un problema de configuración incorrecta de la biblioteca). .TP \fIlib*.so*\fP objetos compartidos .SH NOTAS .SS "Capacidades hardware anticuadas (a partir de glibc 2.5 hasta 2.37)" .\" Presumably, this info comes from sysdeps/i386/dl-procinfo.c and .\" similar files Algunos objetos compartidos se compilan utilizando instrucciones específicas de hardware que no existen en todas las CPU. Estos objetos deben instalarse en directorios cuyos nombres definan las capacidades de hardware necesarias, como \fI/usr /lib/sse2/\fP. El enlazador dinámico compara estos directorios con el hardware de la máquina y selecciona la versión más adecuada de un objeto compartido dado. Los directorios de capacidad de hardware se pueden conectar en cascada para combinar funciones de CPU. La lista de nombres de capacidad de hardware admitidos depende de la CPU. Actualmente se reconocen los siguientes: .TP \fBAlpha\fP ev4, ev5, ev56, ev6, ev67 .TP \fBMIPS\fP loongson2e, loongson2f, octeon, octeon2 .TP \fBPowerPC\fP 4xxmac, altivec, arch_2_05, arch_2_06, booke, cellbe, dfp, efpdouble, efpsingle, fpu, ic_snoop, mmu, notb, pa6t, power4, power5, power5+, power6x, ppc32, ppc601, ppc64, smt, spe, ucache, vsx .TP \fBSPARC\fP flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2 .TP \fBs390\fP dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa, stfle, z900, z990, z9\-109, z10, zarch .TP \fBx86 (solo 32\-bit)\fP acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586, i686, mca, mmx, mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse, sse2, tm .P La compatibilidad con las capacidades de hardware antiguas tiene el inconveniente de que cada nueva función añadida hace crecer exponencialmente la ruta de búsqueda, porque hay que añadirla a cada combinación de las demás funciones existentes. .P .\" Por ejemplo, en x86 de 32 bits, si el hardware admite \fBi686\fP y \fBsse2\fP, la ruta de búsqueda resultante será \fBi686/sse2:i686:sse2:.\fP. Una nueva capacidad \fBnewcap\fP establecería la ruta de búsqueda en \fBnewcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2:\fP. .SS "Capacidad de hardware de glibc (a partir de glibc 2.33)" .TP .\" The initial discussion on various pitfalls of the old scheme is .\" .\" and the patchset that proposes the glibc-hwcap support is .\" glibc 2.33 añadió un nuevo esquema de capcidades de hardware donde bajo cada arquitectura de CPU, se pueden definir ciertos niveles, agrupando el soporte para ciertas características o instrucciones especiales. Cada nivel de arquitectura tiene un conjunto fijo de rutas que añade a la lista de búsqueda del enlazador dinámico, en función del hardware del equipo. Dado que cada nuevo nivel de arquitectura no se combina con otros ya existentes, el nuevo esquema ya no tiene el inconveniente de hacer crecer de forma incontrolada la lista de búsqueda del enlazador dinámico. .P .\" The x86_64 architectures levels are defined the official ABI: .\" .\" The PowerPC and s390x are glibc defined ones based on chip .\" support (which maps to ISA levels). Por ejemplo, en x86 de 64 bits, si el hardware admite \fBx86_64\-v3\fP (por ejemplo, Intel Haswell o AMD Excavator), la ruta de búsqueda resultante será \fBglibc\-hwcaps/x86\-64\-v3:glibc\-hwcaps/x86\-64\-v2:.\fP Actualmente se admiten las siguientes rutas, por orden de prioridad: .TP \fBPowerPC (64\-bit sólo little\-endian)\fP power10, power9 .TP \fBs390 (sólo 64\-bit)\fP z16, z15, z14, z13 .TP \fBx86 (sólo 64\-bit)\fP x86\-64\-v4, x86\-64\-v3, x86\-64\-v2 .P .\" glibc 2.37 eliminó el soporte para las capacidades de hardware antiguas. .SH "VÉASE TAMBIÉN" \fBld\fP(1), \fBldd\fP(1), \fBpldd\fP(1), \fBsprof\fP(1), \fBdlopen\fP(3), \fBgetauxval\fP(3), \fBelf\fP(5), \fBcapabilities\fP(7), \fBrtld\-audit\fP(7), \fBldconfig\fP(8), \fBsln\fP(8) .\" .SH AUTHORS .\" ld.so: David Engel, Eric Youngdale, Peter MacDonald, Hongjiu Lu, Linus .\" Torvalds, Lars Wirzenius and Mitch D'Souza .\" ld\-linux.so: Roland McGrath, Ulrich Drepper and others. .\" .\" In the above, (libc5) stands for David Engel's ld.so/ld\-linux.so. .PP .SH TRADUCCIÓN La traducción al español de esta página del manual fue creada por Juan Piernas y Marcos Fouces . .PP Esta traducción es documentación libre; lea la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE o posterior con respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD. .PP Si encuentra algún error en la traducción de esta página del manual, envíe un correo electrónico a .MT debian-l10n-spanish@lists.debian.org .ME .