2012-07-04 9 views

Respuesta

1

Esto significa que la visibilidad del símbolo se oculta: https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html

razones para cambiar la visibilidad de los símbolos incluyen:

  • Menor riesgo de símbolo colisión.
  • Binarios más pequeños.
  • Reducción del tiempo de inicio porque el enlazador dinámico no necesita procesar tantos símbolos.
  • Oportunidades para un código más eficiente porque el compilador sabe que un símbolo no se puede anular mediante un sistema de tipo LD_PRELOAD.
  • Prevención de llamadas de software de terceros a API indocumentadas.

Consulte http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html para obtener más información.

+0

estoy usando bibliotecas para enlazar estáticamente mi ejecutable. El problema es que tengo el símbolo anterior definido en dos libs diferentes, ambas ocultas. La vinculación falla debido a símbolos duplicados. Cuando te entiendo correctamente, eso no debería suceder, ¿o sí? – MBober

+3

@MBober: No, es correcto que el enlazador produzca un error en ese escenario. Tenga en cuenta que una biblioteca estática es básicamente un archivo de archivos de objetos que se convierten en entradas para el enlazador cuando se vincula la biblioteca estática. La visibilidad del símbolo afecta la salida del enlazador (biblioteca ejecutable o dinámica), pero aún tendrá enlazador problemas si dos o más archivos de objetos definen el mismo símbolo. –

1

Un enlace que explica visibility support (gcc)

Desde el enlace:

  • Se mejora muy considerablemente los tiempos de carga de su (Dynamic Shared Object) DSO. Por ejemplo, una enorme biblioteca basada en plantillas C++ que se probó (la biblioteca de enlaces TnFOX Boost.Python) ahora se carga en ocho segundos en lugar de en seis minutos.

  • Permite que el optimizador produzca un mejor código. Los indirectos PLT (cuando se debe buscar una llamada de función o acceso variable a través de la tabla de compensación global, como en el código PIC) pueden evitarse por completo, evitando sustancialmente las paradas de tuberías en los procesadores modernos y, por lo tanto, un código mucho más rápido. Además, cuando la mayoría de los símbolos están vinculados localmente, se pueden elidir (eliminar) de forma segura a través de todo el DSO. Esto le da una mayor latitud, especialmente a la línea interna, que ya no necesita mantener un punto de entrada alrededor "por las dudas".

  • Reduce el tamaño de su DSO en un 5-20%. El formato de tabla de símbolos exportado de ELF es bastante un cerdo espacial, dando el nombre del símbolo destrozado completo que con el uso de una plantilla pesada puede promediar alrededor de 1000 bytes. Las plantillas de C++ arrojan una gran cantidad de símbolos y una biblioteca típica de C++ puede superar fácilmente los 30,000 símbolos, ¡que es de alrededor de 5-6Mb! Por lo tanto, si corta el 60-80% de los símbolos innecesarios, ¡su DSO puede ser megabytes más pequeño!

  • Mucha menos posibilidad de colisión del símbolo. El viejo ay de dos bibliotecas internamente usando el mismo símbolo para diferentes cosas finalmente ha quedado atrás con este parche. ¡Aleluya!

Aunque la biblioteca citado anteriormente es un caso extremo, el nuevo soporte de visibilidad reducida, la tabla de símbolos exportados de> 200.000 símbolos a menos de 18.000. ¡Algunos 21Mb también fueron eliminados del tamaño binario!

Un usage sample and also potential pitfall cuando se utiliza el atributo visibilidad