Que fait la cltq en assemblée?
0x0000000000400553 <main+59>: mov -0x4(%rbp),%eax
0x0000000000400556 <main+62>: cltq
0x0000000000400558 <main+64>: shl x3,%rax
0x000000000040055c <main+68>: mov %rax,%rdx
En fait, mon programme est très simple :
5 int main(int argc, char *argv[]) {
6 int i = 0;
7 while(environ[i]) {
8 printf("%sn", environ[i++]);
9 }
10 return 0;
mais la sortie d'assemblage est assez longue:
Dump of assembler code for function main:
0x0000000000400518 <main+0>: push %rbp
0x0000000000400519 <main+1>: mov %rsp,%rbp
0x000000000040051c <main+4>: sub x20,%rsp
0x0000000000400520 <main+8>: mov %edi,-0x14(%rbp)
0x0000000000400523 <main+11>: mov %rsi,-0x20(%rbp)
0x0000000000400527 <main+15>: movl x0,-0x4(%rbp)
0x000000000040052e <main+22>: jmp 0x400553 <main+59>
0x0000000000400530 <main+24>: mov -0x4(%rbp),%eax
0x0000000000400533 <main+27>: cltq
0x0000000000400535 <main+29>: shl x3,%rax
0x0000000000400539 <main+33>: mov %rax,%rdx
0x000000000040053c <main+36>: mov 0x2003e5(%rip),%rax # 0x600928 <environ@@GLIBC_2.2.5>
0x0000000000400543 <main+43>: lea (%rdx,%rax,1),%rax
0x0000000000400547 <main+47>: mov (%rax),%rdi
0x000000000040054a <main+50>: addl x1,-0x4(%rbp)
0x000000000040054e <main+54>: callq 0x400418 <puts@plt>
0x0000000000400553 <main+59>: mov -0x4(%rbp),%eax
0x0000000000400556 <main+62>: cltq
0x0000000000400558 <main+64>: shl x3,%rax
0x000000000040055c <main+68>: mov %rax,%rdx
0x000000000040055f <main+71>: mov 0x2003c2(%rip),%rax # 0x600928 <environ@@GLIBC_2.2.5>
0x0000000000400566 <main+78>: lea (%rdx,%rax,1),%rax
0x000000000040056a <main+82>: mov (%rax),%rax
0x000000000040056d <main+85>: test %rax,%rax
0x0000000000400570 <main+88>: jne 0x400530 <main+24>
0x0000000000400572 <main+90>: mov x0,%eax
0x0000000000400577 <main+95>: leaveq
0x0000000000400578 <main+96>: retq
End of assembler dump.
Ce que je ne comprends pas, c'est ce bloc:
0x000000000040052e <main+22>: jmp 0x400553 <main+59>
0x0000000000400530 <main+24>: mov -0x4(%rbp),%eax
0x0000000000400533 <main+27>: cltq
0x0000000000400535 <main+29>: shl x3,%rax
0x0000000000400539 <main+33>: mov %rax,%rdx
0x000000000040053c <main+36>: mov 0x2003e5(%rip),%rax # 0x600928 <environ@@GLIBC_2.2.5>
0x0000000000400543 <main+43>: lea (%rdx,%rax,1),%rax
0x0000000000400547 <main+47>: mov (%rax),%rdi
0x000000000040054a <main+50>: addl x1,-0x4(%rbp)
0x000000000040054e <main+54>: callq 0x400418 <puts@plt>
0x0000000000400553 <main+59>: mov -0x4(%rbp),%eax
0x0000000000400556 <main+62>: cltq
0x0000000000400558 <main+64>: shl x3,%rax
0x000000000040055c <main+68>: mov %rax,%rdx
0x000000000040055f <main+71>: mov 0x2003c2(%rip),%rax # 0x600928 <environ@@GLIBC_2.2.5>
0x0000000000400566 <main+78>: lea (%rdx,%rax,1),%rax
0x000000000040056a <main+82>: mov (%rax),%rax
0x000000000040056d <main+85>: test %rax,%rax
0x0000000000400570 <main+88>: jne 0x400530 <main+24>
4 réponses
cltq promeut un int à un int64. shl 3, %rax fait un offset à un pointeur 64 bits (multiplie ce qui est dans rax par 8). ce que le code fait est de faire une boucle à travers une liste de pointeurs vers les variables d'environnement. quand il trouve une valeur de zéro, c'est la fin, et il tombe hors de la boucle.
voici un visuel sur la façon dont Linux stocke les variables d'environnement en RAM, au-dessus de la pile. Vous verrez les pointeurs à partir de 0xbffff75c; qui pointent vers 0xbffff893, "TERM=rxvt".
jcomeau@intrepid:/tmp$ gdb test
GNU gdb (GDB) 7.2-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/test...(no debugging symbols found)...done.
(gdb) break main
Breakpoint 1 at 0x80483e7
(gdb) run
Starting program: /tmp/test
Breakpoint 1, 0x080483e7 in main ()
(gdb) info reg
eax 0xbffff754 -1073744044
ecx 0xe88ed1c 243854620
edx 0x1 1
ebx 0xb7fc5ff4 -1208197132
esp 0xbffff6a8 0xbffff6a8
ebp 0xbffff6a8 0xbffff6a8
esi 0x0 0
edi 0x0 0
eip 0x80483e7 0x80483e7 <main+3>
eflags 0x200246 [ PF ZF IF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) x/160x 0xbffff6a8
0xbffff6a8: 0xbffff728 0xb7e86e46 0x00000001 0xbffff754
0xbffff6b8: 0xbffff75c 0xb7fe2940 0xb7ff7351 0xffffffff
0xbffff6c8: 0xb7ffeff4 0x08048254 0x00000001 0xbffff710
0xbffff6d8: 0xb7ff0976 0xb7fffac0 0xb7fe2c38 0xb7fc5ff4
0xbffff6e8: 0x00000000 0x00000000 0xbffff728 0x21b99b0c
0xbffff6f8: 0x0e88ed1c 0x00000000 0x00000000 0x00000000
0xbffff708: 0x00000001 0x08048330 0x00000000 0xb7ff64f0
0xbffff718: 0xb7e86d6b 0xb7ffeff4 0x00000001 0x08048330
0xbffff728: 0x00000000 0x08048351 0x080483e4 0x00000001
0xbffff738: 0xbffff754 0x08048440 0x08048430 0xb7ff12f0
0xbffff748: 0xbffff74c 0xb7fff908 0x00000001 0xbffff889
0xbffff758: 0x00000000 0xbffff893 0xbffff89d 0xbffff8ad
0xbffff768: 0xbffff8fd 0xbffff90c 0xbffff91c 0xbffff92d
0xbffff778: 0xbffff93a 0xbffff94d 0xbffff97a 0xbffffe6a
0xbffff788: 0xbffffe75 0xbffffef7 0xbfffff0e 0xbfffff1d
0xbffff798: 0xbfffff26 0xbfffff30 0xbfffff41 0xbfffff6a
0xbffff7a8: 0xbfffff73 0xbfffff8a 0xbfffff9d 0xbfffffa5
0xbffff7b8: 0xbfffffbc 0xbfffffcc 0xbfffffdf 0x00000000
0xbffff7c8: 0x00000020 0xffffe420 0x00000021 0xffffe000
0xbffff7d8: 0x00000010 0x078bfbff 0x00000006 0x00001000
0xbffff7e8: 0x00000011 0x00000064 0x00000003 0x08048034
0xbffff7f8: 0x00000004 0x00000020 0x00000005 0x00000008
0xbffff808: 0x00000007 0xb7fe3000 0x00000008 0x00000000
---Type <return> to continue, or q <return> to quit---
0xbffff818: 0x00000009 0x08048330 0x0000000b 0x000003e8
0xbffff828: 0x0000000c 0x000003e8 0x0000000d 0x000003e8
0xbffff838: 0x0000000e 0x000003e8 0x00000017 0x00000000
0xbffff848: 0x00000019 0xbffff86b 0x0000001f 0xbffffff2
0xbffff858: 0x0000000f 0xbffff87b 0x00000000 0x00000000
0xbffff868: 0x50000000 0x7d410985 0x1539ef2a 0x7a3f5e9a
0xbffff878: 0x6964fe17 0x00363836 0x00000000 0x00000000
0xbffff888: 0x6d742f00 0x65742f70 0x54007473 0x3d4d5245
0xbffff898: 0x74767872 0x45485300 0x2f3d4c4c 0x2f6e6962
0xbffff8a8: 0x68736162 0x47445800 0x5345535f 0x4e4f4953
0xbffff8b8: 0x4f4f435f 0x3d45494b 0x37303534 0x66656135
0xbffff8c8: 0x32353131 0x63346334 0x30393436 0x35386331
0xbffff8d8: 0x39346134 0x37316135 0x3033312d 0x31383339
0xbffff8e8: 0x2e303736 0x31303832 0x382d3033 0x33323731
0xbffff8f8: 0x39373936 0x53494800 0x5a495354 0x30313d45
0xbffff908: 0x00303030 0x48535548 0x49474f4c 0x41463d4e
0xbffff918: 0x0045534c 0x444e4957 0x4449574f 0x3833383d
(gdb) x/20s 0xbffff888
0xbffff888: ""
0xbffff889: "/tmp/test"
0xbffff893: "TERM=rxvt"
0xbffff89d: "SHELL=/bin/bash"
0xbffff8ad: "XDG_SESSION_COOKIE=45075aef11524c4c64901c854a495a17-1309381670.280130-817236979"
0xbffff8fd: "HISTSIZE=10000"
0xbffff90c: "HUSHLOGIN=FALSE"
0xbffff91c: "WINDOWID=8388614"
0xbffff92d: "USER=jcomeau"
0xbffff93a: "HISTFILESIZE=10000"
0xbffff94d: "LD_LIBRARY_PATH=/usr/src/jet/lib/x86/shared:"
0xbffff97a: "LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31"...
0xbffffa42: ":*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.d"...
0xbffffb0a: "eb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35"...
0xbffffbd2: ":*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=---Type <return> to continue, or q <return> to quit---
01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4"...
0xbffffc9a: "v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*."...
0xbffffd62: "yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;3"...
0xbffffe2a: "6:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:"
0xbffffe6a: "COLUMNS=80"
0xbffffe75: "PATH=/usr/src/jet/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/jcomeau:/home/jcomeau/bin:/home/jcomeau/src:/sbin:/usr/sbin:."
(gdb) quit
A debugging session is active.
Inferior 1 [process 10880] will be killed.
Quit anyway? (y or n) y
votre compilateur est apparemment assez intelligent pour optimiser leprintf
puts
. la fetching de la chaîne d'environnement, et le post incrément de i, sont juste là dans le code. Si tu ne te débrouilles pas tout seul, tu ne comprendras jamais. Juste "être" de l'ordinateur, et pas à travers la boucle, en utilisant les données que j'ai dumpé pour vous avec gdb, et tout devrait devenir clair pour vous.
mnémotechnique
cltq
est le gas
mnémonique pour Intel cdqe
tel que documenté à: https://sourceware.org/binutils/docs/as/i386_002dMnemonics.html
Les mnémoniques sont:
- Convertir Long En Quad (
cltq
): AT&T-style - convertir Double en Quad étendre (
cdqe
): Intel
Terminologie:
- quad (alias quad-word) == 8 octets
- à (AT&T) == double-mot (Intel) == 4 octets
C'est l'une des rares instructions dont le nom de gaz est très différent de la version Intel. as
accepte soit mnémotechnique, mais les assembleurs de syntaxe Intel comme NASM ne peuvent accepter que les noms Intel.
Effet
Il signe s'étend sur 4 octets 8 octets, ce qui en complément de 2 signifie que:
- nombres négatifs, les bits de les 4 octets supérieurs doivent être définis à 1
- nombres positifs, ils doivent être mis à 0
En C, qui représente généralement une fonte d'une signature int
long
.
Exemple:
mov 23456700000001, %rax # eax=1, high bytes of rax=garbage
cltq
# %rax == 00 0000 0000 0001
mov $-1, %eax # %rax = 0000 0000 FFFF FFFF
cltq
# %rax == $FFFF FFFF FFFF FFFF == qword $-1
cette instruction n'est disponible que sur 64 bits.
considérez aussi les instructions suivantes:
CWDE
(AT & TCWTL
),CBW
(AT & TCBTW
): versions plus petites deCDQE
, également présent dans 32-bitCQO
famille, qui signe s'étend jusqu'RAX
enRDX:RAX
MOVSX
famille, qui signent tous les deux s'étend et se déplace: que fait l'instruction movsbl?
un Minimum praticable exemples sur GitHub avec des assertions:
C exemple
GCC 4.9.3 l'émet:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
int i = strtol(argv[1], (char **)NULL, 16);;
long int l = i;
printf("%lx\n", l);
}
Compiler et de le démonter:
gcc -ggdb3 -std=c99 -O0 a.c
objdump -S a.out
contient:
int main(int argc, char **argv) {
...
long int l2 = i;
400545: 8b 45 fc mov -0x4(%rbp),%eax
400548: 48 98 cltq
40054a: 48 89 45 f0 mov %rax,-0x10(%rbp)
le problème:
$ ./a.out 0x80000000
ffffffff80000000
$ ./a.out 0x40000000
40000000
si votre OS est 64bit, si vous ne déclarez pas une fonction résident dans un autre fichier, mais vous voulez l'utiliser dans ce fichier. GCC va par défaut penser que cette fonction est 32bit. Ainsi, cltq n'utilisera que 32 bits de RAX(valeur de retour) , le 32 bits le plus élevé sera rempli en 1 ou 0. espérons que ce site vous aidera à http://www.mystone7.com/2012/05/23/cltq/
cltq
le signal s'étend de L'EAX au RAX. C'est un court-forme movslq %eax, %rax
, sauvegarde des octets de code. Il existe en raison de la façon dont x86-64 évolué de 8086 à 386 à AMD64.
il copie le morceau de signe D'EAX à tous les bits supérieurs du registre plus large, parce que c'est ainsi que le complément de 2 fonctionne. Le mnémonique est court pour convertir Long à Quad.
syntaxe AT&T (utilisée par GNU as
/objdump
) utilise une mnémonique différente de celle D'Intel pour certaines instructions (voir la documents officiels). Vous pouvez utiliser objdump -drwC -Mintel
ou gcc -masm=intel -S
pour obtenir la syntaxe Intel en utilisant la mnémonique que Intel et AMD documentent dans leurs manuels de référence d'instructions (voir liens dans le x86 balise wiki. (Fait amusant: en entrée, le gaz accepte mnémonique dans les deux modes).
machine mnemonics: MOVSX equivalent
code AT&T Intel AT&T Intel
66 98 cbtw cbw movsbw %al,%ax movsx ax,al
98 cwtl cwde movswl %ax,%eax movsx eax,ax
48 98 cltq cdqe movslq %eax,%rax movsxd rax,eax
Intel insn ref entrée de manuel pour ces 3 insns.
cltq
/cdqe
n'est évidemment disponible qu'en mode 64 bits, mais l'autre les deux sont disponibles dans tous les modes. movsx
et movzx
n'ont été introduits qu'avec 386, ce qui rend facile / efficace de signer/zéro étendre les registres autres que al
/ax
, ou de signer/zero étendre à la volée pendant le chargement.
pensez à cltq
/cdqe
comme un encodage plus court de movslq %eax,%rax
. Il fonctionne tout aussi rapide. Mais le seul avantage est de sauver quelques octets de code, donc il ne vaut pas la peine de sacrifier quoi que ce soit d'autre pour l'utiliser au lieu de movsxd
/ movzx
.
Un groupe d'instructions copie le sign-bit de [e/r]ax dans tous les bits de [e/R]DX. Signe-l'extension eax
en edx:eax
est utile avant idiv
, ou simplement avant de retourner un entier large dans une paire de registres.
AT&T / Intel mnemonic effect
66 99 cwtd cwd word->doubleword dx = signbit(ax)
99 cltd cdq doubleword->quadword edx = signbit(eax)
48 99 cqto cqo quadword->octword rdx = signbit(rax)
ceux-ci n'ont pas d'équivalent d'instruction simple, mais vous pouvez les faire en deux instructions: par exemple mov %eax, %edx
/ sar , %edx
.
se Souvenir de la mnémoniques
Intel mnémoniques pour l'Extension à l'intérieur de rax
fin e
, à l'exception de l'original du 8086 cbw
. Vous pouvez vous souvenir de ce cas parce que même 8086 manipulait des entiers de 16 bits dans un seul registre, donc il n'y aurait pas besoin de définir dl
pour le bit de signe de al
. div r8
et idiv r8
lire le dividende de ax
, pas dl:al
. Donc cbw
le signal s'étend al
en ax
.
les mnémotechniques AT&T n'ont pas d'indice évident pour vous aider à vous rappeler lequel est lequel. Certains de ceux qui écrivent *dx
d
(pour dx?) au lieu de l'habituel l
long
. cqto
brise Ce modèle, mais un mot octogone est 128b et doit donc être la concaténation de rdx:rax
.
IMO les mnémoniques Intel sont plus faciles à mémoriser, et la syntaxe Intel est plus facile à lire en général. (J'ai appris la syntaxe AT&T tout d'abord, mais je me suis habitué à Intel parce que la lecture de manuels Intel/AMD est utile!)
Notez que pour le zéro-extension, mov %edi,%edi
zéro s'étend %edi
en %rdi
, parce que tout écrire sur un 32 bits registre des zéros à la partie supérieure 32 bits. (Mais dans la pratique, essayez de mov
vers un registre différent (par exemple mov %eax, %ecx
) parce que même,même défait mov-elimination dans les processeurs Intel. Vous verrez souvent compilateur-généré asm pour les fonctions avec des args non signés 32 bits utilisent un mov
zéro étendre, et, malheureusement, souvent avec le même registre que la src et de destination.
pour 8 ou 16 sur 32 (ou implicitement 64),and xff, %eax
fonctionne aussi bien que movzbl %al, %eax
. (Ou mieux, movzbl %al, %ecx
donc mov-elimination peut rendre la latence zéro sur les CPU où movzx
).