2010-03-12 7 views
15

Après la compilation de C++ fichier (avec un objet statique global) je reçois dans nm sortie cette fonction:g ++ __static_initialization_and_destruction_0 (int, int) - quel est-il

00000000 t _Z41__static_initialization_and_destruction_0ii 

__static_initialization_and_destruction_0(int, int) /* after c++filt */ 

Qu'est-ce? Il appellera __cxa_atexit()

Puis-je désactiver la génération de cette fonction (et appeler un __cxa_atexit()) et de mettre tous les appels de constructeur et destructor aux articles .ctors et .dtors?

+2

g ++ possède une option de ligne de commande '-fno-use-cxa-atexit' mais je ne pense pas que cela puisse vous aider. On dirait que ça fait seulement que 'atexit()' est utilisé à la place de 'cxa_atexit()'. Peut-être la meilleure question à se poser est pourquoi g ++ génère '__static_initialization_and_destruction_0()' pour commencer au lieu de placer les appels constructor et destructor dans les sections ELF '.ctors' et' .dtors'. On peut supposer qu'il y a une bonne raison à cela. – Void

Répondre

14

Ce fichier doc semble te dire tout ce que vous voulez savoir sur les avais ces fonctions: http://www.nsnam.org/docs/linker-problems.doc

D'après ce que je peux grok, gcc crée un __static_initialization_and_destruction_0 pour chaque unité de traduction qui a besoin de constructeurs statiques à appeler. Ensuite, il place __do_global_ctors_aux dans la section .ctors, qui appelle ensuite __static_initialization_and_destruction_0 sur chaque unité de traduction.

Le problème semble être beaucoup plus complexe que cela; gcc doit traiter des fichiers objets individuels dans une archive, et je pense que c'est ainsi qu'ils empêchent l'éditeur de liens d'optimiser ces appels.

Questions connexes