Allocation de gaspillage en mémoire pour les variables locales

Le compilateur tente de maintenir un alignement de 16 octets sur la stack. Cela s’applique également au code 32 bits de nos jours (pas seulement 64 bits). L’idée est que, au moment précédant l’exécution d’une instruction CALL , la stack doit être alignée sur une limite de 16 octets.

Parce que vous avez compilé sans optimisations, il existe des instructions superflues.

 0x0804835a : sub esp,0x18 ; Allocate local stack space 0x0804835d : and esp,0xfffffff0 ; Ensure `main` has a 16 byte aligned stack 0x08048360 : mov eax,0x0 ; Extraneous, not needed 0x08048365 : sub esp,eax ; Extraneous, not needed 

ESP est maintenant aligné sur 16 octets après la dernière instruction ci-dessus. Nous déplaçons les parameters de l’appel en commençant par le haut de la stack à ESP . C’est fait avec:

 0x08048367 : mov DWORD PTR [esp+12],0x4 0x0804836f : mov DWORD PTR [esp+8],0x3 0x08048377 : mov DWORD PTR [esp+4],0x2 0x0804837f : mov DWORD PTR [esp],0x1 

L’ appel appelle ensuite une adresse de retour de 4 octets sur la stack. Nous atteignons ensuite ces instructions après l’appel:

 0x08048344 : push ebp ; 4 bytes pushed on stack 0x08048345 : mov ebp,esp ; Setup stackframe 

Cela pousse encore 4 octets sur la stack. Avec les 4 octets de l’adresse de retour, nous sums maintenant mal alignés de 8 octets. Pour atteindre à nouveau un alignement de 16 octets, nous devrons perdre 8 octets supplémentaires sur la stack. C’est pourquoi dans cette déclaration, 8 octets supplémentaires sont alloués:

 0x08048347 : sub esp,0x28 

• 0x08 octets déjà sur la stack en raison de l’adresse de retour (4 octets) et d’ EBP (4 octets)
• 0x08 octets de remplissage nécessaires pour aligner la stack sur un alignement de 16 octets
• 0x20 octets nécessaires pour l’allocation de variables locales = 32 octets. 32/16 est divisible par 16 alors l’alignement est maintenu

Les deuxième et troisième nombres ajoutés ci-dessus sont la valeur 0x28 calculée par le compilateur et utilisée dans le sub esp,0x28 .

 0x0804834a : mov DWORD PTR [ebp-12],0x7a69 

Alors pourquoi [ebp-12] dans cette instruction? Les 8 premiers octets [ebp-8] à [ebp-1] sont les octets d’alignement utilisés pour aligner la stack sur 16 octets. Les données locales apparaîtront ensuite sur la stack après cela. Dans ce cas, [ebp-12] à [ebp-9] sont les 4 octets de l’ flag nombre entier sur 32 bits.

Ensuite, nous avons ceci pour mettre à jour le buffer[0] avec le caractère ‘A’:

 0x08048351 : mov BYTE PTR [ebp-40],0x41 

La bizarrerie serait alors pourquoi un tableau de 10 octets de caractères apparaîtrait de [ebp+40] (début du tableau) à [ebp+13] qui est de 28 octets. La meilleure hypothèse que je puisse faire est que le compilateur a estimé qu’il pouvait traiter le tableau de caractères de 10 octets comme un vecteur de 128 bits (16 octets). Cela obligerait le compilateur à aligner le tampon sur une limite de 16 octets et à étendre le tableau à 16 octets (128 bits). Du sharepoint vue du compilateur, votre code semble agir un peu comme il a été défini comme suit:

 #include  void test_function(int a, int b, int c, int d){ int flag; union { char buffer[10]; __m128 m128buffer; ; 16-byte variable that needs to be 16-bytes aligned } bufu; flag = 31337; bufu.buffer[0] = 'A'; } 

La sortie sur GodBolt pour GCC 4.9.0 générant du code 32 bits avec SSE2 activé apparaît comme suit:

 test_function: push ebp # mov ebp, esp #, sub esp, 40 #,same as: sub esp,0x28 mov DWORD PTR [ebp-12], 31337 # flag, mov BYTE PTR [ebp-40], 65 # bufu.buffer, leave ret 

Cela ressemble beaucoup à votre désassemblage dans GDB .

Si vous avez compilé avec des optimisations (telles que -O1 , -O2 , -O3 ), l’optimiseur aurait pu simplifier la fonction test_function car il s’agit d’une fonction feuille de votre exemple. Une fonction feuille est une fonction qui n’appelle pas une autre fonction. Certains raccourcis auraient pu être appliqués par le compilateur.

Pourquoi le tableau de caractères semble-t-il être aligné sur une limite de 16 octets et complété de 16 octets? On ne pourra probablement pas répondre à cette question avec certitude jusqu’à ce que nous sachions quel compilateur GCC vous utilisez ( gcc --version vous le dira). Il serait également utile de connaître votre système d’exploitation et sa version. Encore mieux serait d’append le résultat de cette commande à votre question gcc -Q -v -g my_program.c

À moins que vous n’essayiez d’améliorer le code de gcc lui-même, comprendre pourquoi un code non optimisé est aussi mauvais qu’il le sera sera surtout une perte de temps. Regardez la sortie de -O3 si vous voulez voir ce qu’un compilateur fait avec votre code, ou de -Og si vous voulez voir une traduction plus littérale de votre source en asm. Écrivez des fonctions qui prennent des entrées dans les arguments et produisent des sorties en globales ou qui renvoient des valeurs, de sorte que l’asm optimisé ne soit pas simplement ret .

Vous ne devriez rien attendre d’efficace de la part de gcc -O0 . C’est la traduction littérale la plus braise de votre source.

Je ne peux pas reproduire cette sortie asm avec aucune version de gcc ou clang sur http://gcc.godbolt.org/ . (GCC 4.4.7 à GCC 5.3.0, Clang 3.0 à 3.7.1). (Notez que godbolt utilise g++ , mais vous pouvez utiliser -xc pour traiter l’entrée en C, au lieu de la comstackr en C ++. Cela peut parfois modifier la sortie asm, même si vous n’utilisez aucune des fonctionnalités de C99 / C11, mais C ++. ne le fait pas (par exemple, les tableaux de longueur variable C99).

Certaines versions de gcc émettent par défaut du code supplémentaire, sauf si j’utilise -fno-stack-protector .

J’ai d’abord pensé que l’espace supplémentaire réservé par test_function consistait à copier ses arguments dans son cadre de stack, mais au moins le gcc moderne ne le fait pas. ( Gcc 64 bits stocke ses arguments en mémoire lorsqu’ils arrivent dans des registres , mais c’est différent. Gcc 32 bits incrémente un argument en place sur la stack, sans le copier .)

L’ABI autorise la fonction appelée à graver ses arguments sur la stack. Par conséquent, un appelant qui souhaite effectuer des appels de fonction répétés avec les mêmes arguments doit continuer à les stocker entre les appels.

clang 3.7.1 avec -O0 copie ses -O0 dans des sections locales , mais cela ne réserve que 32 octets ( 0x20 ).

C’est à peu près la meilleure réponse que vous obtiendrez à moins de nous dire quelle version de gcc vous utilisez …