Posté le 05/12/2020 23:57
), je me suis retrouvé plusieurs fois à patcher l'OS et à le reflasher sur ma calculatrice pour valider des théories sur le fonctionnement de celui-ci. Ce processus est plutôt dangereux pour des tas de raisons ( coupure de courant durant le flash, usure excessive de la flash, modifier un bout de code qu'il ne fallait pas qui mène à la corruption du bootloader, etc. ) or comme je ne me vois pas avec un fer à souder pour réparer tout ça, je me suis lancé dans le développement de cet outil.
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 32 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 28/08/2022 17:07 | #
Donc, si je cherche à comprendre un peu plus profondément, pour créer ces fameuses cibles "debug"
Il faudrait que je fasse :
1/ dans fxsdk.sh ( ~/.local/share/giteapc/Lephenixnoir/fxsdk/fxsdk ) :
je dois commencer par créer une cible supplémentaire : par exemple transformer les lignes 130 à 150 pour la partie fxsdk_build()
[[ ! -e build-fx && ! -e build-cg && ! -e build-cg-dbg ]]
none_exists=$?
if [[ -e build-fx || $none_exists == 0 ]]; then
echo "$TAG Making into build-fx"
fxsdk_build_fx "$@"
fi
if [[ -e build-cg || $none_exists == 0 ]]; then
echo "$TAG Making into build-cg"
fxsdk_build_cg "$@"
fi
if [[ -e build-cg-dbg || $none_exists == 0 ]]; then
echo "$TAG Making into build-cg With Debug Information"
fxsdk_build_cg_debug "$@"
fi
}
fxsdk_build_fx() {
fxsdk_build_in "fx" "FX9860G" "$@"
}
fxsdk_build_cg() {
fxsdk_build_in "cg" "FXCG50" "$@"
}
fxsdk_build_cg_debug() {
fxsdk_build_in "cgdbg" "FXCG50DEBUG" "$@"
}
2/ dans le depot gint je dois mettre la jour les cibles de manière parallèles:
je dois ajouter dans CMakeLists.txt au niveau de la ligne 257 (juste après la cible fxCG50) une nouvelle cible
add_compile_definitions(FXCG50)
# je pense qu'il faut que je mette mon -g ici en supplément pour avoir les infos de debug qui se génèrent
add_compile_options(-g)
add_library(gint-cg-debug STATIC ${SOURCES_COMMON} ${SOURCES_CG} ${ASSETS_CG})
set(NAME "gint-cg-debug")
set(LINKER_SCRIPT "fxcg50debug.ld")
endif()
avec bien entendu le script fxcg50debug.ld où je retire du DISCARD toute la partie d'info de debug
du coup le je pense avoir un gint-cg-debug.a qui me servira pour la génération de ma cible de projet
et 3/ dans un projet que je veux debugger, je rajoute la cible DEBUG dans le CMakeLists.txt :
add_executable(myaddin ${SOURCES} ${ASSETS} ${ASSETS_${FXSDK_PLATFORM}})
target_compile_options(myaddin PRIVATE -Wall -Wextra -Os)
target_link_libraries(myaddin Gint::Gint)
if("${FXSDK_PLATFORM_LONG}" STREQUAL fx9860G)
generate_g1a(TARGET myaddin OUTPUT "MyAddin.g1a"
NAME "MyAddin" ICON assets-fx/icon.png)
elseif("${FXSDK_PLATFORM_LONG}" STREQUAL fxCG50)
generate_g3a(TARGET myaddin OUTPUT "MyAddin.g3a"
NAME "MyAddin" ICONS assets-cg/icon-uns.png assets-cg/icon-sel.png)
elseif("${FXSDK_PLATFORM_LONG}" STREQUAL fxCG50DEBUG)
generate_g3a(TARGET myaddin OUTPUT "MyAdDBG.g3a"
NAME "MyAddin" ICONS assets-cg/icon-uns.png assets-cg/icon-sel.png)
endif()
C'est ça ou j'ai rien pané à comment fonctionne cmake et tous les depots du fxsdk/gint entre eux ?
Citer : Posté le 28/08/2022 17:56 | #
C'est... une option, mais clairement pas la meilleure.
CMake a déjà un système intégré pour les build de debug, avec tout un concept de "configurations" où tu peux instancier le même système de compilation avec différents paramètres (le mode debug étant le plus canonique de tous).
Donc ici, la commande fxsdk build-cg-debug est raisonnable, mais y'a pas besoin de dupliquer la toolchain :
fxsdk_build_in "cg-debug" "FXCG50" "$@"
# Ajouter un paramètre pour passer "-DCMAKE_BUILD_TYPE=Debug" à cmake
}
CMake ajoutera -g tout seul du fait de CMAKE_BUILD_TYPE=Debug. Ensuite t'as juste envie d'aller dans gint pour changer le linker script de :
à un truc comme
sachant que du coup faudrait compiler gint en mode debug aussi (mais ça on peut le faire pour tout le monde tout le temps y'a pas besoin de paramètre) et tu peux choisir le nom de ton g3a en testant la config.
Reste que le linker script est dupliqué, ce qui est pas trop. Faudrait sans doute générer les deux à partir d'un seul fichier source de gint, au moment de l'installation.
Citer : Posté le 28/08/2022 20:02 | #
Je comprend l'idée, mais ne vois pas comment tu ajoutes le paramètre de ta ligne
# Ajouter un paramètre pour passer "-DCMAKE_BUILD_TYPE=Debug" à cmake
tu lui mets un set( CONFIG "Debug" ) ?
qui sera repris dans la ligne set(INTF_LINK "-T;$<IF:$<CONFIG:Debug>,fxcg50-debug.ld,fxcg50.ld>") ?
Citer : Posté le 28/08/2022 21:14 | #
Il faut ajouter un paramètre à fxsdk_build_in pour que quand elle appelle cmake elle ajoute, sur demande, -DCMAKE_BUILD_TYPE=Debug.
Cela aura pour conséquence que le test $<CONFIG:Debug> sera vrai. C'est tout des variables internes de CMake, c'est connecté à CMAKE_BUILD_TYPE.
Citer : Posté le 29/08/2022 19:58 | #
Deuxième point, je ne sais pas si Bernard a aussi expérimenté cette déconvenue, le "make" sort sur une erreur dans le fichier 'sh3eb-gdb/sim/sh/targ-map.c' pour le signal "SIGSTKSZ" (ligne 433 du dit fichier). Malheureusement je n'ai pas trouvé de meilleure méthode pour contourner l'erreur que de commenter ce bloc.
Je suis surpris que tu rencontres autant de difficultés à compiler GDB, je suppose que le code provient d'une archive d'une release stable, il ne devrait pas y avoir d'erreurs de compilation même sur les architectures les plus obscures car celles-ci sont compilées régulièrement par les distros.
En effet ce que j'ai l'habitude de faire et que je recommande pour plus de simplicité c'est d'utiliser un gdb-multiarch. Il s'agit d'une config de GDB qui contient toutes les architectures et elle est disponible sur beaucoup de distro "mainstream" : e.g. Ubuntu Debian Arch (AUR). Si jamais elle n'est pas disponible, il est plutôt simple de la compiler soi-même en suivant le PKGBUILD de l'AUR.
Comme ça, plus besoin de trop réfléchir, on a un GDB qui fonctionne pour toutes les archis de binutils.
Pour l'utiliser en revanche il faut penser à bien régler l'architecture et l'endianness de la machine. Si on charge un ELF qui comporte ces informations il ne devrait pas y avoir de problèmes mais j'ai pris l'habitude de toujours la régler car il m'arrive souvent de l'utiliser sans fichier attaché :
(gdb) set architecture sh4a-nofpu
The target architecture is set to "sh4a-nofpu".
(gdb) set endian big
The target is set to big endian.
(gdb) file file.elf
Reading symbols from file.elf...
(gdb) target remote localhost:31188
Remote debugging using localhost:31188
Pour rendre la chose plus automatisée on peut écrire ces commandes dans un fichier et utiliser l'option -x pour interpréter son contenu au démarrage.
Citer : Posté le 30/08/2022 14:50 | #
Merci pour les détails Redoste, très utile comme d'habitude. J'ai toujours dans un coin de la tête le debugging direct par USB avec Yatis...
Citer : Posté le 30/08/2022 22:57 | #
@Slyvtt : je n'ai pas eu le probleme que tu signales pour compiler le cross debugger gdb (j'ai du le refaire il y a quelques jours sur une debian 11)
Ensuite je n'ai pas deux versions pour l'addin, mais une seule. C'est le elf qui sert a debugguer, l'addin est de toute facons "strippe" de toutes les infos de debug. Mon mode d'emploi est ici https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/khicasio.html#sec46 et s'adapte pour l'addin en 2 parties (cf le Makefile de l'archive de https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/giacbfalpha.tgz)
Ceci etant dit, l'utilisation du cross debugger avec l'emulateur de Casio reste assez instable par rapport à celui que j'utilise pour les ti nspire cx avec firebird-emu, mais ca permet parfois de debloquer.
Citer : Posté le 10/05/2023 00:08 | # |
Fichier joint
Hey !
J'ai juste fait une petite update mais elle pourrait aider les quelques personnes qui utilisent cet outil. Après plus d'un an sans toucher à ce code j'ai essayé d'enfin trouver le gros problème qui ralentit de fou le débugueur et qui, à la longue, le rend assez fastidieux à utiliser.
Après avoir eux un peu honte de certaine décisions prisent par la redoste de 2020 (hé, ça veut dire que j’évolue, c'est cool ig), j'ai décidé d'arrêter de me battre avec les outils de Microsoft pour faire du profiling, j'ai fini par utiliser la méthode brute et j'ai pu, à ma grande surprise, identifier que la plupart du temps été passé dans les fonctions de Winsock.
Je pense que mes recv et send de 1 octet font probablement un peu partie du problème mais même en faisant des tests intensifs je n'ai vraiment pas réussi à avoir les mêmes performances entre Winsock dans Wine et les sockets de Linux. C'est probablement moi qui suis absolument ignorante sur le fonctionnement de la stack réseau de Windows mais je n'ai pas réussi à trouver une raison exacte à mon problème.
J'ai donc décidé de proposer des alternatives au socket TCP et d'ajouter 2 autres manières de se connecter au débugueur. Tout est expliqué dans le README mais en gros vous pouvez maintenant ajouter l'argument /gdb:[nom de l'interface]:[options] dans la commande de fx-CG_Manager_PLUS_Subscription_for_fx-CG50series.exe pour spécifier comment GDB se connectera. Les 3 interfaces suivantes sont disponibles :
* tcp qui prend en option le port d'écoute : le bon vieux socket TCP de Winsock bien lent
* com qui prend en option le port COM utilisé : le port série de la machine, ce qui est utile quand on fait tourner l'émulateur dans une VM
* wine qui prend en option un chemin de socket unix : cette méthode n'a aucun respect pour la philosophie de Wine et va appeler directement les syscalls de Linux depuis l'application Windows dans le but de créer un socket unix
Ces trois options devraient donc couvrir la majorité des utilisateurs (Wine et VM) tout en proposant un gain de performance ahurissant "gratuitement".
Vous pouvez télécharger la nouvelle version de la DLL dans les releases GitHub.
Et pour le principe voici la comparaison entre le socket TCP (à droite) et le socket unix (à gauche) avec l'émulateur dans Wine :
(Je suis désolée pour la qualité de la vidéo digne d'un DivX mal encodé trouvé sur eD2k : petit fail sur les paramètres d'encodage d'OBS. Mais bon ça reste lisible.)
Citer : Posté le 10/05/2023 00:10 | # |
Fichier joint
Et voici la comparaison entre le socket TCP (à droite) et le port série d'une VM (à gauche) :
Citer : Posté le 10/05/2023 00:32 | #
Oh, une update ! Merci pour ça je m'étais jamais posé la question de l'IPC dans cette affaire...
Au fait, on a de l'USB bidirectionnel maintenant... si jamais ça pouvait être utile
Citer : Posté le 10/05/2023 07:38 | #
Il y a deux dll en téléchargement:
CPU73050-5ccc67d5ea2a7cea549b0c8b28664a0b56b2b686.dll
CPU73050-5ccc67d5ea2a7cea549b0c8b28664a0b56b2b686-msvc.dll
Faut-il les deux? Comment doit-on les renommer?
Citer : Posté le 10/05/2023 12:46 | #
Il y a deux dll en téléchargement:
Faut-il les deux? Comment doit-on les renommer?
Les 2 DLLs sont fonctionnellement identiques, l'une est build avec mingw et l'autre avec MSVC, donc tu peux choisir celle qui t'arrange ou essayer l'autre si t'as des problèmes avec l'une. Dans tous les cas tu peux les renommer comme d'habitude CPU73050.dll avec la DLL de l’émulateur d'origine CPU73050.real.dll. (Je suis désolée, je pensais l'avoir précisé quand j'ai expliqué avoir mis en place GitHub Actions pour les builds en CI :/).
Au fait, on a de l'USB bidirectionnel maintenant... si jamais ça pouvait être utile
Yep j'ai vu ça, j'ai suivi vite fait l'évolution de gint du coin de l'oeil et j'avoue ne pas vraiment avoir eux le temps de me pencher dessus. J'aimerais bien essayer de faire un PoC mais ça va être chaud pour le moment car c'est ma période d'exam actuellement.
Par contre j'ai un peu regardé hier soir pour voir comment ça pourrait s'organiser et je me posais quelques questions.
On est bien d'accord que pour le moment la manière la plus simple d'utiliser l'USB c'est d'utiliser la classe 0xff bulk avec fxlink sur le PC ? Je me disais que ça serait plus pratique si on pouvait exposer un truc qui ressemble à un terminal série de manière à ne pas nécessiter de logiciel tierce sur le PC mais bon je pense pas que ce soit une priorité actuellement (et de ce que j'ai vu les specs de l'USB sont pas vraiment faciles à comprendre, donc je vais me focaliser sur ce qui marche actuellement).
Je me suis remémoré comment fonctionnaient les exceptions sur SuperH (qui se déclencheront lors d'un breakpoint notamment) et je me pose une question hyper conne donc je pense que je rate un truc. Quand il y a une exception PC saute à VBR+0x100 et de ce que j'ai compris il y a seulement PC, SR et R15 qui sont sauvegardés (et de même pour la restauration par rte), donc ce serait à l'exception handler de sauver les GPR qui pourraient être utilisés or dans gint, tu sembles pousser sur la stack que PR, GBR, MAC*, R8 et R9. Y a un mécanisme que je rate complètement qui va sauvegarder R0..R7+R10..14 ?
Cette histoire de sauvegarde sur la stack m'a fait penser à un autre truc du coup. Ce serait pas un peu plus pratique d'allouer une stack spécifiquement utilisée par le débugueur ? Je ne pense pas que ça pose problème car contrairement à d'autres archi (comme x86) il ne me semble pas que ça arrive d'avoir besoin d'écrire au delà de R15 mais je pense que ça rendrait la chose moins perturbante d'un point de vu utilisateur de ne pas voir toute la partie supérieure de ta stack changer à chaque single-stepping.
Je suis bien consciente que je fais partie de la minorité qui voit d’abord GDB comme un outil de reverse engineering et pas un simple outil de debug, donc je suis probablement pas mal biaisée là-dessus mais ça me semble quand même être quelque chose d'important.
Une dernière chose que je me demandais c'est au niveau des breakpoints. La manière la plus flexible d'en poser c'est de laisser GDB écrire son trapa mais vu que sur le vrai matériel on aura les pages de l'addin qui sont mappées en RX et que de ce que j'ai compris toucher la TLB c'est le danger sous CASIOWIN (même si ça a l'air très fun sur le principe), on se limiterait à ce qui est possible avec le User Break Controller ?
Je suis désolée d'un peu hijack mon propre thread pour des questions qui quittent le sujet de base mais bon je ne pense pas que ça aurait été utile d'en ouvrir un nouveau.
D'ailleurs est-ce qu'il y aurait moyen d'avoir un compte sur le gitea histoire que je puisse fork gint et ouvrir une PR avec mon PoC (c'est loin d'être urgent du coup, je ne pense pas vraiment pouvoir m'y pencher d'ici 2 semaines) ?
Citer : Posté le 11/05/2023 21:46 | #
On est bien d'accord que pour le moment la manière la plus simple d'utiliser l'USB c'est d'utiliser la classe 0xff bulk avec fxlink sur le PC ? Je me disais que ça serait plus pratique si on pouvait exposer un truc qui ressemble à un terminal série de manière à ne pas nécessiter de logiciel tierce sur le PC mais bon je pense pas que ce soit une priorité actuellement (et de ce que j'ai vu les specs de l'USB sont pas vraiment faciles à comprendre, donc je vais me focaliser sur ce qui marche actuellement).
Oui j'ai passé une heure ou deux à commencer à implémenter la classe CDC/ACM pour avoir un terminal standard (/dev/ttyACM*) mais ce sera pas tout à fait immédiat. Un pont serait sans doute plus rapide à coder. Je compte bien supporter CDC/ACM à un moment, mais je me dis que c'est pas nécessaire pour prototyper.
r0...r7 ne sont pas en conflit ; il y a deux versions de chaque. En mode d'exception on change de banque et donc on n'affecte pas les originaux. À tout instant on peut accéder à la banque inactive avec ldc/stc sous le nom rX_bank. r8...r14 sont caller-saved donc de toute façon l'exception handler ne les écrase pas.
Je vois pas trop ce qu'on gagne ? Yatis le fait dans Vhex (le désassembleur) je crois.
A priori oui. On pourrait écrire le trapa dans le cache mais ça paraît bancal.
Avec ton email Planète Casio ? Si non envoie-moi l'email concerné par MP.
Citer : Posté le 12/05/2023 00:15 | # |
Fichier joint
D'ailleurs, je viens de pousser un fix parce que la dernière fois que j'avais touché au projet, on n'avait même pas de libc. C'est pour dire.
Si tu veux, tu peux utiliser mon PoC de débogueur traceur (qui est extrêmement pratique), notamment la partie "exception handler" de l'UBC (https://gitea.planet-casio.com/Yatis/gintrace/src/branch/dev/src/ubc/kernel.S#L7).
Pour la faire simple, par chance, on est sur des SH4 et il y a un registre DBR, qui peut etre setup (https://gitea.planet-casio.com/Yatis/gintrace/src/branch/dev/src/ubc/ubc.c#L18) pour dire à l'UBC "yo au lieux d'utiliser la VBR pour brancher l'exception, utilise la DBR plutôt", ce qui me permet de me mettre "dans une librairie à part", sans toucher au source de gint.
Le projet est très vieux (le dernier commit date d'il y a 2ans), mais je serais chaud pour le reprendre si jamais l'envie se fait ressentir. Pourquoi pas discuter pour ajouter le driver de l'UBC dans gint directement (mais il faudra revoir le driver, parce qu'il y a beaucoup de chose extrêmement puissante a faire avec l'UBC et pas juste mettre des breakpoints). Sinon on a pas beaucoup de taff pour repartir sur une base saine:
<> basculer en CMake
<> basculer sur JustUI
<> mettre en place une norme + mettre à la norme
<> définir clairement ce qu'on vise (certainement de l'USB. CDC/ACM serait beaucoup trop pratique pour pouvoir interagir avec la calto via le clavier du laptop)
<> polir la maigre base avant de commencer (revoir le désassembleur + revoir la gestion des dictionnaires (syscall, notes, instructions, ...) + pouvoir sync les info avec la bible ?)
<> ...
Je te joint un addin compilé (bon, il trace un syscall obscure de Fugue, j'étais dessus récemment). Les contrôles sont pas trop complexe:
<> [EXE] instruction suivante
<> [F1]-[F3] changer de menu
<> [X2] affichage commande (jmp <hexa[00000000]>, syscall <ID>)
<> [EXIT] quitter la commande
<> [(-)] centrer le curseur de sélection au milieux de l'écran
<> [+],[-] bouger le curseur de sélection
<> [OPTN] skip toute les instructions jusqu’à la sélection (pratique pour bypass les routines qui bloque les interruptions)
Bref, dans tous les cas, le projet reste pratique et si tu as des questions, je reste à ta disposition.
Citer : Posté le 12/05/2023 11:14 | #
Un driver UCB dans gint serait bien à mon avis - comme ça ce serait stable/maintenu sur un plus long terme.
Citer : Posté le 21/05/2023 18:26 | #
r0...r7 ne sont pas en conflit ; il y a deux versions de chaque. En mode d'exception on change de banque et donc on n'affecte pas les originaux.
Merci pour la précision, j'avais relu la doc à 1h du matin sans vraiment faire attention. Je ne sais pas comment j'ai fait pour passer à côté de ça. Je suis désolée pour les questions stupides -_-'
C'est plus par principe de bien séparer le débugueur du programme débuggé. Pour un programme classique compilé avec GCC ça ne devrait pas poser problème, mais je pense que un programme écrit en assembleur qui fait des optimisations customs (dans le style de la red zone par exemple) devrait être supporté.
Ce n'est bien entendu pas une priorité et si c'est implémenté ça peut être optionnel mais ça fait partie des features que en tant qu'utilisatrice je m'attendrai à trouver.
Tu peux utiliser redoste[40]redoste[2e]xyz.
Pendant la panne j'ai justement commencé à faire 2/3 trucs : j'ai codé le bridge côté PC qui expose un socket unix sur lequel on peut connecter GDB et un début d'implem dans gint. Je commencerai à m'attaquer au driver UBC quand j'aurais le temps.
Si tu veux, tu peux utiliser mon PoC de débogueur traceur (qui est extrêmement pratique), notamment la partie "exception handler" de l'UBC
Merci beaucoup pour l'exemple, il m'a permis de mieux comprendre comment fonctionne l'UBC et certaines subtilités des exceptions SuperH.
Je ne sais pas si ginttrace sera encore très utile si l’implémentation GDB est complète et fonctionnelle mais ça peut rester un bon outil de debug on-calc ou peut être utile pour les personnes ne sachant pas se servir de GDB j'imagine.