Définitivement, il y a quelque chose que je ne comprends pas avec la réservation de 32+8 octets (minute 26 de la video) : le problème de décalage de pile de 8 octets ne vient pas du fait qu'on veut réserver 32 octets, mais du fait que le call équivaut à un push de 8 octets (donc n'aligne pas la pile sur 16 octets). C'est donc le call qui crée le décalage de 8 octets. Ca veut donc dire qu'il faudrait TOUJOURS rattraper le décalage de 8 octets avant de faire un nouveau call. Or ce n'est pas le cas. Dit autrement : pourquoi faudrait-il recaler la pile quand on veut réserver 32 octets, et pas quand on ne veut rien réserver ?
L'appel à main (ou _start sur GNU/Linux) pousse l'adresse de retour sur la pile (8 octets). Conséquence, il faut l'aligner sur 16 octets (comme le veulent les conventions Windows x64 ou SystemV AMD64), avec par exemple un sub rsp, 8. On a alors poussé au total 16 octets sur la pile, qui est bien alignée. Vient s'ajouter à cela, pour la convention Windows x64, le fait de devoir réserver 32 octets d'espace pour les 4 arguments. Mais en ajoutant 32 octets aux 16 octets de départ, on arrive à 48, et la pile reste alignée. En conclusion, on va généralement retrouver une soustraction à RSP de 8 octets SystemV AMD64 (pour corriger l'alignement) et une soustraction à RSP de 40 sur Windows x64 (pour corriger l'alignement + réserver l'espace d'ombre). "pourquoi faudrait-il recaler la pile quand on veut réserver 32 octets, et pas quand on ne veut rien réserver ?" Non, il n'y a pas de choix à faire : la pile doit TOUJOURS être alignée sur 16 octets AVANT tout appel à une fonction.
Tu peux donc pousser les valeurs que tu veux sur la pile, il faudra toujours veiller ensuite qu'elle soit bien alignée sur 16 octets avant l'appel à une fonction, puisque la convention d'appel garantit à la fonction appelée que cet alignement est bien respecté 👍
@@formation-video Enfin compris ! Je ne comprenais pas que le sub rsp, 8 sert à "compléter" la pile suite à l'appel juste AVANT. Merci ! Et merci pour ces excellents cours vidéo (qui me permettent de me remettre à niveau depuis l'assembleur ... Z80 et 68000 - oui je suis pas tout jeune ^^)
@29:48 Au fait, tu sais que si tu veux utiliser le lieur ld avec l'IPA Windows, il suffit de mettre le chemin complet de Kernel32 : ld C:\Windows\System32\kernel32.dll main.o -o debug.exe
@@formation-video Oui mais tous les executables créés par GoLink me génèrent des alertes de sécurité de Microsoft Defender. Tu n'as jamais eu ce problème ? Je n'arrive pas à éviter cela et du coup Windows met en quarantaine les .exe créés par Golink :(
Une instruction de dépilement (POP) agit forcément sur le registre de pile, donc sur RSP en 64 bits, qui doit à ce moment-là être revenu à l'endroit où se trouve l'adresse de retour, car c'est celle qui permet de revenir à la fonction appelante 👍
@@formation-video ah enfaite, je me suis trompé, tu as raison, ret depile rsp sur rip. Enfaite j'avais en tête l'image de la stack frame avec le rbp et les variables locals dans la pile. On doit d'abord depiler toute les variables locals puis le rbp et enfin on utilise ret.
Merci pour le poulet ! On en apprend tellement, je suis trop content
Bonne continuation
Ça faisait un moment que j'avais regardé une de tes vidéos récentes et je dois dire que la musique au début m'a fais un peu bizzare
Bonjour a vous et merci je vous et un peu un peu je me lance dans la programmation informatique
Bon courage 👍
Définitivement, il y a quelque chose que je ne comprends pas avec la réservation de 32+8 octets (minute 26 de la video) : le problème de décalage de pile de 8 octets ne vient pas du fait qu'on veut réserver 32 octets, mais du fait que le call équivaut à un push de 8 octets (donc n'aligne pas la pile sur 16 octets). C'est donc le call qui crée le décalage de 8 octets. Ca veut donc dire qu'il faudrait TOUJOURS rattraper le décalage de 8 octets avant de faire un nouveau call. Or ce n'est pas le cas. Dit autrement : pourquoi faudrait-il recaler la pile quand on veut réserver 32 octets, et pas quand on ne veut rien réserver ?
L'appel à main (ou _start sur GNU/Linux) pousse l'adresse de retour sur la pile (8 octets).
Conséquence, il faut l'aligner sur 16 octets (comme le veulent les conventions Windows x64 ou SystemV AMD64), avec par exemple un sub rsp, 8.
On a alors poussé au total 16 octets sur la pile, qui est bien alignée. Vient s'ajouter à cela, pour la convention Windows x64, le fait de devoir réserver 32 octets d'espace pour les 4 arguments. Mais en ajoutant 32 octets aux 16 octets de départ, on arrive à 48, et la pile reste alignée.
En conclusion, on va généralement retrouver une soustraction à RSP de 8 octets SystemV AMD64 (pour corriger l'alignement) et une soustraction à RSP de 40 sur Windows x64 (pour corriger l'alignement + réserver l'espace d'ombre).
"pourquoi faudrait-il recaler la pile quand on veut réserver 32 octets, et pas quand on ne veut rien réserver ?"
Non, il n'y a pas de choix à faire : la pile doit TOUJOURS être alignée sur 16 octets AVANT tout appel à une fonction.
Tu peux donc pousser les valeurs que tu veux sur la pile, il faudra toujours veiller ensuite qu'elle soit bien alignée sur 16 octets avant l'appel à une fonction, puisque la convention d'appel garantit à la fonction appelée que cet alignement est bien respecté 👍
@@formation-video Enfin compris ! Je ne comprenais pas que le sub rsp, 8 sert à "compléter" la pile suite à l'appel juste AVANT. Merci ! Et merci pour ces excellents cours vidéo (qui me permettent de me remettre à niveau depuis l'assembleur ... Z80 et 68000 - oui je suis pas tout jeune ^^)
Tu auras donc bien fait de laisser un commentaire, bonne continuation (la seconde partie arrive samedi)
ah, finally !
👍
@29:48
Au fait, tu sais que si tu veux utiliser le lieur ld avec l'IPA Windows, il suffit de mettre le chemin complet de Kernel32 :
ld C:\Windows\System32\kernel32.dll main.o -o debug.exe
Oui, mais j'ai habitué les gens à utiliser GoLink sur Windows pour varier les différents outils 👍
@@formation-video Oui mais tous les executables créés par GoLink me génèrent des alertes de sécurité de Microsoft Defender. Tu n'as jamais eu ce problème ? Je n'arrive pas à éviter cela et du coup Windows met en quarantaine les .exe créés par Golink :(
@formation-video Up please
Non, tu vois bien dans les vidéos que je n'ai pas ce souci.
De toute manière, tu peux utiliser le lieur que tu veux, ça ne posera aucun problème.
Mais ducoup, ret ne depile pas rsp pour le mettre dans rip, mais rbp + 8 qui contient l'adresse de retour nan ?
À quel moment de la vidéo exactement fais-tu référence ?
@@formation-video quand tu expliques ce que fait call et ret en commentaire, c'était vers la première partie de la video
Une instruction de dépilement (POP) agit forcément sur le registre de pile, donc sur RSP en 64 bits, qui doit à ce moment-là être revenu à l'endroit où se trouve l'adresse de retour, car c'est celle qui permet de revenir à la fonction appelante 👍
@@formation-video ah enfaite, je me suis trompé, tu as raison, ret depile rsp sur rip. Enfaite j'avais en tête l'image de la stack frame avec le rbp et les variables locals dans la pile. On doit d'abord depiler toute les variables locals puis le rbp et enfin on utilise ret.
Voilà