Un análisis técnico demuestra que la opción -mcmodel=large de GCC y Clang, pensada para compilar binarios enormes sorteando los límites de direccionamiento de 32 bits, falla de forma sistemática con variables thread-local (__thread) y, por extensión, con la inmensa mayoría del software C/C++ real de gran tamaño.
El autor parte de un trabajo previo en el que logró vincular binarios de más de 2 GiB con el modelo de código grande, pero al repetir el experimento con variables __thread, que aterrizan en las secciones .tdata y .tbss, el enlazador vuelve a abortar con errores del tipo "relocation truncated to fit: R_X86_64_TPOFF32". El motivo es estructural: las cuatro variantes de acceso a TLS en x86-64 (Local-Exec, Initial-Exec, General-Dynamic y Local-Dynamic) codifican los offsets como campos de 32 bits dentro de la propia instrucción. El modelo de código grande solo puede sustituir las relocalizaciones de datos ordinarios por secuencias de 64 bits, pero no toca las instrucciones que acceden al thread pointer, de modo que un .tbss que supere los 2 GiB rompe cualquier binario.
El problema se reproduce tanto con la cadena GNU (gcc + ld) como con LLVM (clang + lld), que llega a reportar el desplazamiento exacto fuera de la ventana de 32 bits. El autor subraya que este caso es sintético en tamaño pero completamente realista en patrón: cualquier programa con estado thread-local extenso — servidores, runtimes, motores de bases de datos — choca con la misma pared. La consecuencia práctica es clara: el modelo de código grande, tal y como existe hoy, no sirve para construir binarios grandes complejos, y los autores de compiladores y la propia especificación de la ABI x86-64 deberán coordinarse para ampliar los modos de acceso TLS si quieren mantener esa promesa.