9
votes

L'assemblage généré g ++ a l'air laid

Je suis assez familier avec GCC Assembly ... Récemment, j'ai été obligé d'utiliser g ++ pour un nettoyage de code. Permettez-moi de mentionner que je connais très bien l'assemblée, donc de la curiosité, je jetez souvent un coup d'oeil à la qualité de l'ASM généré par le compilateur.

Mais les conventions de nommage avec g ++ sont juste bizarre. Je me demandais s'il y a des lignes directrices sur la manière de lire sa sortie ASM?

Merci beaucoup.


5 Réponses :


13
votes

Si vous envisagez la convention de dénomination pour les symboles externes, cela suivra la convention Nom Mangling de la plate-forme que vous utilisez. Il peut être inversé avec le programme C ++ Filt qui vous donnera la version lisible humaine des noms de fonction C ++, bien qu'ils (dans toutes les probabilités) ne soient plus des symboles de liaison valides.

Si vous regardez simplement des étiquettes de fonction locales, vous n'avez pas de chance. g ++ Sure de l'assembleur est destiné à parler à l'assembleur et non conçu pour faciliter la compréhension humaine. Il va générer un ensemble d'étiquettes relativement dénuées de sens.


0 commentaires

19
votes

de man g ++ :

-fverbose-asm
Mettre des informations de commentaire supplémentaires dans le code de montage généré pour le rendre plus lisible. Cette option n'est généralement qu'avec uniquement à ceux qui ont besoin de lire la code d'assemblage généré (peut-être tout en débogage du compilateur lui-même).


3 commentaires

Disllamer: Pas comme "Verbose" comme vous le pensez.


Liranuna a raison. Cela ne le rend pas plus lisible, pour moi au moins. Il ne démange pas les étiquettes pour vous, ce qui est ce que l'OP semble vouloir vouloir.


Non, c'est joli. Vous êtes libéré de deviner où la variable, ce que vous recherchez, se trouve dans la pile - Nom des variables sont superposés du côté gauche. Beaucoup plus simple



27
votes

Je ne trouve pas l'ASM de G ++ 'Laid' ou difficile à comprendre, bien que je travaille avec GCC depuis plus de 8 ans maintenant.

sur Linux, les étiquettes de fonction vont généralement par _ZN, le préfixe "_zn" étant un jeton qui désigne le nom de nom C ++ (par opposition à c), suivi de l'espace de noms de noms que la fonction appartient, puis les noms de fonction et les types d'arguments, puis Le cas échéant.

exemple: xxx


2 commentaires

Basé sur votre exemple, je suis d'accord avec Sam, c'est laid! Ils appellent le nom "Mangling" pour une raison! Bien que vous ayez fourni la meilleure réponse jusqu'à présent.


Je pense que "ID" dans votre exemple est la longueur de l'argument suivant. _ZN, 5 "tests", 4 "Vec4", 12 "Teséquure", E, v.



5
votes

Si le code a des informations de débogage, objdump peut fournir un démontage plus utile: xxx


0 commentaires

0
votes

Pour les personnes qui travaillent sur la démanglation de ces noms à l'intérieur du programme (comme moi), espérons-le ce fil aide. < Pré> xxx


2 commentaires

Est-ce que cette fonction est utilisée dans le GDB ou quelque chose? Gdb / objdump a déjà une option pour démangeaisons lors de la désassemblage: objdump -c . J'utilise habituellement objdump -drwc -mintel . Mais de toute façon, si vous avez G ++ - généré ASM, je pense que vous pouvez simplement le faire passer par C ++ FIGT .


@Petercordes La fonction est écrite dans Python car, dans mon cas, j'écris un analyseur qui doit comprendre les noms de fonctions de C ++.