0
Lors du débogage d'un problème avec un programme plantant sur un pointeur tronqué en cours de déréférencement, j'ai exécuté lldb et effectué un démontage de la fonction de blocage. En parcourant le code désassemblé, j'ai remarqué ce choix bizarre d'instructions:Pourquoi la sortie de l'assembleur de Clang saute conditionnellement à un saut inconditionnel?
0x100002b06 <+86>: cmpl $0x0, %eax 0x100002b09 <+89>: je 0x100002b14 0x100002b0f <+95>: jmp 0x10000330e 0x100002b14 <+100>: jmp 0x100002c1d
j'attendre le code pour ressembler à ceci:
0x100002b06 <+86>: cmpl $0x0, %eax 0x100002b09 <+89>: je 0x100002c1d 0x100002b0f <+95>: jmp 0x10000330e
I Je suis curieux de savoir pourquoi Clang a fait ce choix. Est-ce une sorte d'optimisation de la prédiction de branche, puisqu'il s'agit d'une vérification de pointeur NULL qui est très peu probable?
modifier:This is the originating C code, spécifiquement la ligne avec la vérification du pointeur NULL.
traverse = travdone_head;
while (1) {
if (traverse == NULL) nullptr("grokdir() traverse");
/* Don't re-traverse directories we've already seen */
if (inode == traverse->inode && device == traverse->device) {
Votre code a-t-il été compilé en mode débogage? Si c'est le cas, cela pourrait expliquer pourquoi le code d'assemblage a été écrit de cette manière. –
Il a été compilé avec '-O0 -g3'. Il semble encore un peu étrange que cela produise un saut à un saut, mais cela expliquerait probablement cela. –
Depuis que vous avez ajouté la balise C: quelles sont les lignes source qui ont abouti à ce code? – usr2564301