8
Esempio:Cosa significa ".hidden" nell'output dell'output objdump -t?
$ objdump Logger.cpp.o -t
00000000 g F .text 00000000 .hidden __sti___10_Logger_cpp_0b2ae32b
A
risposta
1
Vuol dire che la visibilità del simbolo è nascosto: https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html
ragioni per cambiare la visibilità dei simboli comprendono:
- Minor rischio di collisione simbolo.
- Binari più piccoli.
- Tempo di avvio ridotto perché il linker dinamico non ha bisogno di elaborare tanti simboli.
- Opportunità per un codice più efficiente perché il compilatore sa che un simbolo non può essere sovrascritto tramite un sistema di tipo LD_PRELOAD.
- Prevenzione del software di terze parti che chiama in API non documentate.
Vedere http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html per ulteriori informazioni.
1
Un collegamento che spiega visibility support (per gcc)
Dal link:
Migliora in modo sostanziale i tempi di caricamento del vostro DSO (Dynamic Shared Object). Ad esempio, un'enorme libreria basata su template C++ che è stata testata (la libreria di binding TnFOX Boost.Python) ora viene caricata in otto secondi anziché in sei minuti!
Consente all'ottimizzatore di produrre codice migliore. Le rinvii PLT (quando una chiamata di funzione o un accesso variabile devono essere cercati tramite la tabella di offset globale come nel codice PIC) possono essere completamente evitate, evitando sostanzialmente stallo di pipeline su processori moderni e quindi codice molto più veloce. Inoltre, quando la maggior parte dei simboli è legata localmente, possono essere tranquillamente eliminati (rimossi) completamente attraverso l'intero DSO. Ciò conferisce maggiore latitudine soprattutto all'Inliner che non ha più bisogno di mantenere un punto di ingresso intorno "nel caso in cui".
Riduce le dimensioni del tuo DSO del 5-20%. Il formato della tabella dei simboli esportato dell'ELF è piuttosto uno space hog, che fornisce il nome completo del simbolo storpiato che, con un uso intenso del template, può raggiungere una media di circa 1000 byte. I modelli C++ rilasciano una grande quantità di simboli e una tipica libreria C++ può facilmente superare i 30.000 simboli che si aggirano sui 5-6Mb! Quindi se tagli il 60-80% dei simboli non necessari, il tuo DSO può essere più piccolo di megabyte!
Molto più bassa possibilità di collisione di simboli. Il vecchio guaio di due librerie che usano internamente lo stesso simbolo per cose diverse è finalmente alle nostre spalle con questa patch. Hallelujah!
Anche se la libreria sopra citato è un caso estremo, il nuovo supporto visibilità ridotta la tabella dei simboli esportati da> 200.000 simboli per meno di 18.000. Alcuni 21Mb sono stati eliminati anche dalle dimensioni binarie!
Un usage sample and also potential pitfall quando si usa l'attributo visibilità
sto usando le librerie di collegare in modo statico il mio eseguibile. Il problema è che ho il simbolo sopra definito in due diverse librerie, entrambe nascoste. Il collegamento fallisce a causa di simboli duplicati. Quando ti capisco correttamente, non dovrebbe succedere, dovrebbe? – MBober
@MBober: No, è corretto che il linker produca un errore in quello scenario. Tieni presente che una libreria statica è fondamentalmente un archivio di file oggetto che diventano tutti input al linker quando la libreria statica è collegata. La visibilità dei simboli influisce sull'output del linker (eseguibile o libreria dinamica), ma avrai ancora il linker problemi se due o più file oggetto definiscono lo stesso simbolo. –