Trouver pile la taille d'image

Le cadre de la pile d'un appel de fonction peut être facilement obtenue par __builtin_frame_address(1), mais quid de la pile de la taille d'image?

Est-il une fonction qui me permettra de savoir quelle est la taille de la frame de pile de l'appelant la fonction?

  • (char *)__builtin_frame_address(1) - (char *)__builtin_frame_address(0)?
  • Laissez-moi essayer, mais je ne suis pas sûr de savoir comment les EIP (x86, RIP pour x64) seront traités.
  • c'est une bonne question et je ne suis pas un faible niveau de sorte de gourou, alors ne prenez pas mon mot pour cela 🙂
  • Nope, ne pas faire beaucoup de sens: pastebin.com/GUaSrY7c
  • Ce n'est pas logique dans tout cela?
  • il y a 7 ints. Sur ma machine, sizeof(int) retourne 4. Donc je suppose que le frame de pile doit être de 4*7=28. Peut-être que je me trompe, dans l'affirmative, veuillez expliquer pourquoi?
  • Encore plus loin, je viens de objdump-ed le binaire, et je vois 48 83 ec 20 sub rsp,0x20 dans la main, ce qui signifie que GCC réservés 32 octets au lieu de le 28, j'attends (je suppose à cause des optimisations?). Mais de toute façon, ce n'est pas 48
  • "Donc je suppose que le frame de pile doit être de 4*7=28" - non, ce n'est pas la façon dont il fonctionne. La pile doit souvent être alignés (tout comme la taille d'une structure n'est pas la somme de la taille de ses membres, un cadre de pile est souvent plus grand qu'il serait "semble" nécessaire). Aussi, puisque les variables ne sont plus utilisés, ils peuvent très bien être optimisé à l'écart. Aussi, n'existe-il pas plus d'opérations impliquant des "sp", par le chemin? (gardez à l'esprit que l'adresse de retour doit être stocké quelque part aussi, donc peut-être qui s'ajoute à la 32 octets? etc.)
  • c'est le vidage de la main (exclusing l'appel à la fonction de test): pastebin.com/4ZDPd7LL Il y a une poussée de 8 octets (rbp), donc si ça fait de la pile plus que 28 + 8 = 36 octets de la pile, ce qui n'est toujours pas 48. Je suppose que l'alignement de la pile ne semble raisonnable, mais peut-être pas dans ce code exact (comme la décharge montre clairement le contraire)
  • Bien, en voyant le cliché, cela fait vraiment sens: 0x20 est de 32, pas 28. 32 + 8 est de 40. Si vous ajoutez de l'espace nécessaire pour l'adresse de retour, vous obtenez 48. (Je ne suis pas sûr que ce doit en effet être fait, mais quelque chose me dit que cette façon de l'obtention de la taille de l'image ne fait sens.)
  • Selon cette image 1.bp.blogspot.com/_n5BzA0M85tM/SdbJduaGHKI/AAAAAAAAARM/... (ou toute autre représentation visuelle d'une pile), l'adresse de retour ne fait pas partie du cadre de pile, de sorte que l'ajout d' + 8 + 8 ne semble pas être la solution propre.
  • Oh, non, je suis désolé, il ne s'en fait.
  • À mon humble avis il y a quelque chose de buggy avec cette solution. pastebin.com/2ERgnXsf GCC réserves de 32 octets de la pile, j'ai 8 entiers de 4 octets chacun. Il n'existe pas de "l'espace vide" dans la pile en raison de l'alignement. Je m'attend à mon code pour afficher les valeurs de chaque variable, mais ils semblent être déplacée par un. Si je reste 4 à tmp, il est résolu, mais je ne peux pas vraiment savoir pourquoi? Je suis sur une machine x64, donc l'adresse de retour est de 8 octets.
  • laissez-nous continuer cette discussion dans le chat

InformationsquelleAutor alexandernst | 2014-02-01