SuperH disassembler
Posté le 11/07/2013 02:53
Pour mes besoin personnel, j'ai réalisé ce désassembleur qui est basé sur la documentation SH3, mais normalement compatible avec nos SH4. Je me doute que ça ne servira pas à grand monde, surtout que le SDK est tout à fait capable de faire de même (enfin, le sdk nous oblige à ce que le fichier binaire soit un addin). Cependant, ça pourra éventuellement servir pour d'autre, et autant partager ce qui est chiant à faire (en l'occurrence, le plus chiant est le switch de plus de 300 lignes qui permet de différencier les instructions
).
Utilisation
Pour l'utiliser, prenez votre fichier binaire et glissez le sur l'exécutable, normalement il devrait vous sortir un fichier output.txt qui contient 3 colonnes :
- La première est l'offset en hexadécimal (numéro de l'octet si vous préférez)
- La seconde est le contenu en hexadécimal (ce contenu fait toujours deux octets)
- La troisième contient la "traduction" en assembleur si elle existe. Notez qu'une traduction peut très bien être disponible alors que les deux octets ne sont que des données. (Il est impossible de différencier une simple donnée d'une instruction, car la seule différence qui les sépare est que l'une va être interprétée par l'ordinateur et pas l'autre car il ne passera jamais dessus)
Un autre moyen d'ouvrir le logiciel est de passer par une ligne de commande :
SHdisassembler.exe "adresse du fichier que vous ouvrez.bin" "adresse du ficher de sortie.txt"
Sachant qu'une instruction fait 2 octets, si vous décalez le fichier en entier d'un seul octet, vous n'obtiendrez pas du tout le même résultat. Pensez-y, ça pourrait être une source d'erreur
Quelques infos pour les curieux et/ou non-initiés :P
- un désassembleur est un logiciel qui va prendre le code d'un fichier binaire (ici, nos g1a), et qui le "transformer" en langage assembleur (qui est un langage pas très compréhensible, mais toujours plus compréhensible que du binaire
).
- Si vous ouvrez un g1a avec, il faudra commencer à lire à partir de la ligne 0x200, car c'est à cet offset que commence la partie binaire d'un g1a, ce qui est avant n'est que l'entête.
- En assembleur sh3, chaque instruction fait 2 octets, voilà pourquoi l'offset compte de 2 en 2, car j'indique le numéro de l'octet.
Je mets les sources avec, mais elles ne sont pas très belles, car j'ai baladé le code plusieurs fois entre le "standard" et la librairie Qt (ce code me sert sur un autre projet : un début d'émulateur que je ne finirais sans doute jamais).
Changelog
v1.00 (11/07/2013) :Version originale
v1.01 (03/08/2013) :
- Correction de nombeux bugs mineurs, oublis d'instructions
- Suppression de toutes les instructions non compatible avec nos calculatrices
- Ajout de l’adresse de destination en commentaire sur le coté droit c'est possible (par exemple pour mov.l @(h'4,pc),r1 , j'affiche l'adresse qui correspond à @(h'4,pc)
- Affichage de certaines valeurs sous forme negative lorsque c'est plus pratique
Fichier joint
Citer : Posté le 11/07/2013 11:35 | #
intéressant, je jetterais un œil.
-en C:
-Un pong.
-Un projet en pause. Je compte le reprendre de temps en temps: Summer Cursed
-mon tuto sur les Str
Mes calto: G25+, G75
Mon minecraft en dévelopement
-Portal2D de JavierXD
-CalCraft de Wime
-GeekBros du groupe GeekBrothers (Eiyeron,Siapran,KevKevVTT,Adbook,LIMachi)
Citer : Posté le 11/07/2013 19:21 | #
Génial
Est ce que l'on peut recompiler après,cela ouvrirait de nouveaux horizon
Citer : Posté le 11/07/2013 19:24 | #
Avec cet outil, non, mais après si la modification n'est pas trop grande tu peux recompiler manuelement (tu vas sur la doc du sh3, tu regarde ce que fait ta modif en hexadecimal et tu modifie le fichier manuelement)
Sinon ça doit être possible de recompiler en faisant un fichier .src dans le sdk, mais ce n'est pas sûr j'ai pas testé.
Citer : Posté le 11/07/2013 20:16 | #
C'est déjà exceptionnel
Citer : Posté le 03/08/2013 13:28 | #
V1.01 : voir changelog.
Note à moi-même : Pour récupérer le code assembleur des syscall à partir d'un backup de fxremote, il suffit d'aller à l’adresse 0x10070 et de suivre les instructions.
Citer : Posté le 12/04/2014 13:53 | #
Le fichier "output.txt" est censé ressortir dans le même dossier que le désassembleur ?
Car je n'ai rien
Citer : Posté le 12/04/2014 13:56 | #
Pareil pour moi, je n'ai jamais réussi à avoir un fichier en sortie...
Citer : Posté le 13/04/2014 03:37 | #
Euh je sais plus exactement où est généré le fichier, c'est peut être à l'endroit où est l'executable.. Sinon essayez d'indiquer en second argument la sortie (normalement ça fonctionne car output.txt est le second argument par défault)
Quelle idée de me demander ça quand je viens de passer le dernier de mes pc sous linux :P (et la flème de compiler le bouzain pour tester)
Citer : Posté le 13/04/2014 10:52 | #
Heu, quand tu drag & drop un fichier sur un exécutable, tu le rentre comment le deuxième argument ?
Citer : Posté le 13/04/2014 13:36 | #
Tu peux pas dans ce cas, faut soit le faire en console, soit le faire dans executer
Citer : Posté le 13/04/2014 17:39 | #
Ça marche bien en console pour moi finalement
Citer : Posté le 14/06/2014 10:22 | #
Je sais que je déterre, mais pour l'info lorsque vous glissez, le fichier output.txt est généré dans C:\Documents and Settings\username.
Citer : Posté le 18/06/2014 17:25 | #
De toute façon, je bosse sur l'emulateur qui intègre un disassembleur (plus à jour que celui là), et qui permettra d'exporter le fichier désassemblé dans un ou plusieurs fichier textes. (même si l'interface permet d'ajouter des commentaires sur chaque ligne et entre les lignes, et donc on a pas forcément besoin d'un fichier texte (en plus y'a la colorisation syntaxique que tu n'auras pas dans le fichier texte).
Citer : Posté le 18/06/2014 17:52 | #
Il avance ton émulateur ? T'as réussi a gérer les entrées clavier ?
Citer : Posté le 18/06/2014 20:13 | #
J'ai pas avancé sur ça. Là, je rebosse fortement l'interface, pour faire quelquechose de propre, et pas un simple test bourrin et mal codé comme c'était au début. Il est assez lent, et avant de sortir une version publique open source, il faut que je recode le core (le truc qui interprète les instructions), pour l'optimiser, et pour des raisons de licenses, parce que pour l'instant, la moitié des instructions, c'est des copié-collé de la doc (qui n'est pas optimisé vu que c'est un exemple pour comprendre ce que fait l'instruction).
Donc y'a encore du boulot, mais je vais m'y remettre pendant les vacs.
Ajouté le 18/06/2014 à 20:14 :
Le soucis avec le clavier, c'est qu'il faut que je trouve comment sont géré les interruptions, et où est ce qu'elles se passent dans l'OS en plus de savoir à quelle adresse le clavier est connecté et comment il est connecté.
Citer : Posté le 18/06/2014 23:41 | #
Je n'avais pas réagi au début, mais j'en profite pour faire une remarque : pour désassembler j'ai l'habitude de passer par objdump, des binutils/gcc (option -D, et éventuellement précisions sur l'architecture si c'est pas un fichier ELF).
Il a l'avantage d'utiliser la syntaxe GCC (forcément), et quand c'est pas sur du binaire pur mais sur du ELF, ça permet d'avoir les symboles et pas mal de petites infos pratiques.
Pour l'émulateur, j'avoue m'y être penché brièvement plusieurs fois, mais c'est vrai que c'est un vaste sujet (et très dur de trouver le bon équilibre entre abstractions et performances).
En gros, le processeur lui-même (sans prendre en compte le pipeline des instructions) c'est pas trop dur, mais dès qu'on commence à tapper dans la gestion des "modules" du CPU ça devient énorme, même pour le minimum utilisé par l'OS de Casio.
Si tu te remet dessus, je serrais ravi de pouvoir apporter un coup de main, Ziqumu.
Pour le clavier, quelques infos qui trainent :
L'OS de Casio utilise, à priori, 3 types d'interruptions pour la gestion du clavier (les deux qui sont les interruptions du port A ou B et un timer, sûrement le casio-specific qui n'est pas documenté d'ailleurs).
Le timer permet de gérer la répétition lors du maintient de la touche.
(pas besoin de trop savoir où elles passent dans l'OS, si t'as la gestion des interruptions au niveau du CPU, et ces trois sources correctement gérées, ça devrait passer non?)
Pour la façon dont il est connecté, je sais qu'il y a un schéma pas mal qui traine quelque part, mais en gros c'est une grille qui utilise des ports pour les lignes et pour les colonnes (ports A, B et M). C'est un peu bourrin après, ça consiste à activer certaines lignes (en sortie) et à surveiller les colonnes (en entrée), mais ça devrait pas être trop compliqué à émuler.
Sur FiXos y'a quelques trucs qui peuvent t'aider à comprendre comment c'est géré (bien sûr ce n'est pas l'implémentation de l'OS Casio, mais ça devrait être assez similaire) : keymatrix.c
Pour finir, je n'ai pas trop étudié la question, mais est ce qu'il semble envisageable de permettre d'utiliser l'émulateur comme cible pour un gdb en remote?
Ce serait vraiment LE truc qu'il manque aux toolchains GCC pour Casio, et sûrement le dernier obstacle à l'abandon du SDK officiel
Citer : Posté le 19/06/2014 00:01 | #
Merci pour ces infos, je relirais ça quand je me pencherais dessus
J'ai jamais utilisé gdb, donc je sais pas si y'a des specs speciales que tu veux, mais si l’émulateur arrive à fonctionner a une vitesse raisonnable (ce qui n'était pas le cas aux derniers essais), il restera un obstacle pour émuler un g1a : L'OS. Actuellement je charge un OS casio, mais je n'aurais pas le droit de le fournir avec l’émulateur. On peut envisager de créer un OS open source qui reprend les syscall pour émuler les bons trucs, mais c'est un autre projet ^^. Mais en effet, c'est un des buts de l’émulateur. Dans tous les cas, avant d’émuler un g1a, faut déjà réussir à bien émuler l'OS.
Bref, dans tous les cas je vous donnerais des infos dès que possible
Ajouté le 19/06/2014 à 00:31 :
Le truc aussi c'est pour avoir un emulateur un peu plus rapide, il va sans doute falloir que je passe à un truc un peu plus bas niveau que Qt pour la partie émulateur, mais j’aimerais bien garder l'interface sous qt quand même. Du coup, ça va demander un certain travail de réécriture.
Ajouté le 19/06/2014 à 02:31 :
Après réflexion (et observation), y'a qemu qui gère le SH4, y'a peut-être moyen de faire un fork et de l'intégrer au projet. Sinon l'autre idée c'est de faire une lib en C qui gère l'émulateur et qui est appelé par une classe Qt (mais faut que je fasse bien attention à la construction, parce que derrière j'ai deux thread donc c'est pas simple de faire communiquer l'interface avec le core.)
Citer : Posté le 19/06/2014 06:55 | #
Si tu veux faire l'écran de l'émulateur, le plus sûr pour l'afficher est à mon goût la SDL, sans aucun doute.
Sinon, voici la keymatrix dont Kristaba parlait.
Citer : Posté le 19/06/2014 07:28 | #
Actuellement l'interface fait un peu plus qu'afficher un écran, donc j'utilise qt et une classe de qt permet de dessiner en 2d. C'est pas le plus compliqué de toute façon.
Citer : Posté le 19/06/2014 08:09 | #
Moi de même j'veux bien te filer un coup de main, je serais intéressé par développer un émulateur.