opcode source, destination
, ça reste quelque-chose de complètement non-naturel. Quand on s'est habitué à écrire du code assembleur avec opcode destination, source
, on y reste. Pareil pour les 42(%eax,%ebx,4)
vs. [eax + ebx*4 + 42]
.Et voilà qu'à travers le wiki du projet "gdb-dashboard", je découvre qu'il est possible de passer gdb en mode 'intel' d'une simple commande.
set disassembly-flavor intel
là. c'est tout.
Et si on veut la même chose en sortie d'objdump, ce sera
objdump -M intel -mes-autres-options
[ sauvegarder et continuer ]
Attention: gdb-dashboard et ddd sont mutuellement exclusifs.
A tout hasard, un appel x86_64, ça donne call(rdi, rsi, rdx, rcx, r8, r9, stack...)
Et si jamais le débuggeur insiste sur le fait que "No function contains program counter for selected frame", on peut toujours forcer disas address, +size
ou utiliser set disassemble-next-line on
edit: pour montrer/cacher un panneau, on utilise juste dashboard nom_du_panneau
Juste, pour éviter les pointeurs en bleu-foncé illisible, on peut ajouter les commandes gdb classiques à la fin du fichier .gdbinit (avant `python Dashboard.start()`):
set style address background none
set style address foreground cyan
set style address intensity dim
Et pour les noms de registres (en noir sur mon Pc de bureau T_T), il faut aller éditer le style "low" ... j'en profite pour tester ces codes ANSI 256-couleurs:
'style_low': {
'default' : '38;5;103' # 32-16 = 36*red + 6*green + blue
}
donc, 48;5;$value permet de choisir librement la couleur de fond alors que 38;5;$value choisit librement la couleur du texte. les valeurs de $value entre 16 et 231 sont interprétées comme des codes RGB avec 6 valeurs par composantes. 103 est donc red = 2/6, green = 2/6, blue = 3/6
ReplyDelete