¿Por qué shl_load () fallará para las bibliotecas con Thread Local Storage?

Question

Los subprocesos en Perl toman por defecto su propio almacenamiento local para todas las variables, para minimizar el impacto de los subprocesos en el código existente que no reconoce subprocesos. En Perl, se puede crear una variable de hilo compartido usando un atributo:

use threads;
use threads::shared;

my $localvar;
my $sharedvar :shared; 

El cargador en tiempo de ejecución HP-UX no admite la carga dinámica de bibliotecas compartidas que contienen almacenamiento local de hebras (TLS).
Como resultado, al intentar importar módulos que contienen TLS, se informa el siguiente error:

"/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage"

Entonces sé por qué recibo un error. No tengo claro por qué sería difícil cargar una biblioteca con TLS.

Answer 1

La forma en que se configura el almacenamiento TLS depende del acceso TLS modelo .

En el más simple " TLS ejecutable / estático inicial " modelo, el cargador configura el segmento TLS antes de que se ejecute la primera instrucción del ejecutable principal. Calcula el tamaño de ese segmento sumando los requisitos de TLS del ejecutable principal y todas las bibliotecas compartidas de las que depende directamente.

Una vez que este segmento TLS se asigna y configura, la aplicación comienza a ejecutarse y puede almacenar punteros en el segmento TLS. Por lo tanto, es imposible realloc () almacenamiento para el segmento: el cargador no tendría idea de qué punteros en la aplicación deben actualizarse.

Dado que no puede reasignar el segmento, y dado que no hay espacio para variables adicionales; ¿Cómo puede el cargador manejar bibliotecas cargadas dinámicamente que requieren almacenamiento TLS propio?

El cargador glibc en realidad asigna algo de espacio extra en el TLS inicial, por lo que puede cargar dinámicamente bibliotecas con TLS, siempre que no utilicen demasiado espacio. Una vez que esta reserva se agote, el cargador glibc también se negará a cargar bibliotecas adicionales con requisitos de TLS.

En Solaris y Linux es posible cargar dinámicamente bibliotecas con requisitos arbitrarios de TLS, utilizando el " General Dynamic TLS modelo " ;.

Parece que HP-UX v1.6 también admite ese modelo, y de hecho lo convierte en el predeterminado. Pero probablemente esté ejecutando una versión anterior del sistema operativo, donde este modelo no es el predeterminado y es posible que no sea compatible en absoluto. Compruebe si su versión del compilador admite la opción + tls = dynamic y, si es así, si la construcción con ella ayuda.