TiEmu: fiture ricouaistes - Page 7

> Pour faciliter le debug, quelqu'un peut me dire où je peux réduire la valeur de l'APD ?
Par programme ou en trifouillant la mémoire ?

Par programme, c'est le timer numéro 2 (1 dans la table interne):
OSFreeTimer (APD_TIMER);
OSRegisterTimer (APD_TIMER, 100*20);

En trifouillant la mémoire, désassemble OSRegisterTimer pour trouver l'adresse de la table où sont stockés les timers. C'est 5B9A sur 89 AMS 2.05. Chaque élément de la table fait 8 octets (lsl.w #3), et le champ qui t'intéresse est à l'offset 0 par rapport au début de l'élément de la table.


> A priori, je suis d'accord mais une TI peut être réveillée sur n'importe quelle interruption;
N'importe quelle interruption _non désactivée_, mais il en reste plusieurs...


J'ai essayé de profiler tiemu avec valgrind 3.2.x, mais ça fait tout de suite un SIGSEGV

Est-ce que quelqu'un d'autre peut tester les Program Entry Breakpoints ? Je ne suis pas 100% sûr que la fenêtre, et l'implémentation, se comportent comme ils devraient (on ne peut définir qu'un program entry breakpoint ?).

J'ai essayé de transférer un programme tout à l'heure, et ça m'a fait un dialog d'erreur, en écrivant dans la console:

[...]
ticalcs-INFO: Vérification du status:
ticalcs-INFO: PC->TI: RDY?
ticalcs-INFO: TI->PC: ACK
ret = 0
ticalcs-INFO: Envoi de variable(s):
ticalcs-INFO: PC->TI: RTS (size=0x0000072B=1835, id=21, name=main\lib)
ticalcs-INFO: TI->PC: ACK
ticalcs-INFO: TI->PC: SKP (00 c9 0f 00 2b)

(tiemu:7167): ticalcs-WARNING **: D-BUS error code not found in list. Please report it at <tilp-devel@lists.sf.net>.
Duration: 0,0 seconds.

(tiemu:7167): tiemu-WARNING **: Msg: hand-held returned an error.
Cause: hand-held returned an uncaught error. Please report log.


Le bug est 100% reproductible, en plus



Nan, faut pas avoir peur, c'est de ma faute
Je tournais PedroM v0.81 20051101 4:04 (ROM par défaut, ça suffit pour le test que je voulais faire), sur une version de TIEmu qui n'est toujours pas la dernière.

Ce qui s'est passé, c'est que j'ai tourné un programme qui écrit a priori très au-delà des bornes de l'écran. PedroM a indiqué Address Error et m'a ramené à sa ligne de commande.
J'ai alors essayé de transférer le programme une deuxième fois, c'est là que TIEmu a râlé que D-BUS rendait n'importe quoi.
Un reset de la calculette, et le transfert fonctionne de nouveau correctement.

J'ai sauvegardé le source et le binaire, si ça vous intéresse de reproduire le problème

Euh... En réfléchissant à ce qui s'est passé, c'est plutôt un problème de PedroM (Address Error intervient parce que j'écris réellement à une adresse impaire, mais pas parce que j'ai écrasé les variables du système), même s'il y a peut-être une gestion des cas d'erreur à améliorer dans TIEmu / les libs de linking.

Tu peux m'envoyer par mail le programme que tu as voulu envoyer (main/lib) ?

Envoyé.

Martial Demolins (./190) :
Quand l'OS a fait un reset (ce que PedroM fait automatiquement en cas de crash), le "Reset to saved state" n'a aucun effet, ou ne semble en avoir aucun. Ce qui fait qu'à chaque bogue rencontré, il faut redémarrer l'ému. C'est un peu dommage pour un ému quand même

As-tu bien un état sauvegardé auquel revenir? "Revert to saved state" ne marche que s'il y a un saved state. S'il n'y en a pas, il faut utiliser "Reset calculator" pour redémarrer la calculatrice.

Autre truc chiant : le débogueur s'ouvre tout seul sur certaines erreurs (le illegal instruction est mis par défaut par exemple). Mais quand il est ouvert, on a accès qu'à une partie du menu, et des options comme "Revert to saved state" justement sont grisées. Le problème est que souvent, ces erreurs se produisent en cascade, empêchant d'accéder à un menu pour revenir à un état stable.
Donc là encore, il faut fermer l'ému, voire parfois le killer. Toujours aussi chiant comme comportement pour un débogueur.

"Reset calculator" fonctionne dans tous les cas (j'ai rajouté ça pour pouvoir sortir d'une telle boucle, justement), donc il faut faire un reset d'abord, ensuite tu peux faire un revert.

Un état sauvegardé, c'est un .sav, pas un .ini, et c'est par ROM (on ne peut pas utiliser une sauvegarde pour une ROM avec une autre, c'est la faute de TI ça, pas la nôtre).

Bah non, désolé.

Je suis toujours là et je continue bien de recevoir des mails. Simplement, je suis un peu débordé en ce moment.

Je vois que des bugs nouveaux sont arrivés sur TiEmu. Je vais essayer de m'en occupper ASAP...

Je viens de recevoir une NSpire CAS. Quelqu'un sait où est passé le site hackspire? Il n'y est plus!

Bug ./188 fixé (toujours au moins une page de RAM).

Je pensais pas te revoir

Ah bon, pourquoi ?
C'est simplement que j'ai un peu arrêté pour me consacrer à l'agrégation de physique appliquée.

Il y a eu un update aux packages Debian TIEmu et TILP aujourd'hui, et l'update à TIEmu apporte GDB au package tiemu-gdb. Merci Romain

Dommage que le désassembleur utilise la syntaxe GNU as:
* écriture en minuscules;
* des "%" partout;
* affichage des move to SR en valeurs décimales;
* (semble-t-il) affichage des instructions inconnues (provenant par exemple du désassemblage de strings) en octal (??!)
(pour ne citer que ce que j'ai vu en deux minutes, j'imagine qu'en utilisant plus longtemps ce désassembleur, je trouverai d'autres sujets de mécontentement)


Ah, aussi, je peux faire crasher TIEmu de façon reproductible avec:
1) transfert d'un programme avec "Debug File with TIEmu";
2) ouverture du debugger (F11) et création d'un Program Entry breakpoint sur un programme transféré;
3) lancement du programme.

C'est partiellement ma faute, parce que j'ai essayé de transférer un programme qui n'a pas d'infos de debug
Mais comme on peut faire cette erreur en utilisation courante, ça serait peut-être bien de corriger ça pour éviter des bug reports stupides et du "TIEmu c'est du caca", hmm ?

+1, malheureusement...
J'ai mis la remarque en spoiler dans ./200 (que tu as citée partiellement en clair, vilain ) parce que Kevin m'a déjà fait exactement cette réflexion à propos d'un crash de ld-tigcc, rencontré lorsque je testais une ancienne version de mon patch pour le support des timestamps (là, Kevin ne peut pas râler que mon patch n'est pas testé, mais je peux râler que son programme n'est pas testé ).

Au passage, Kevin: la nouvelle version, qui n'utilise plus gettimeofday, a été envoyée le 25 mai. Aucune réaction de ta part.
Il faut dire que quelques heures après, j'ai envoyé un morceau de patch pour permettre la génération par tigcc-dasm d'un code assembleur plus lisible (sans les '%'). Patch dont tu as su me dire si gentiment que tu refusais de le regarder:

Not a bug, won't fix. Ce switch ne sert strictement à rien.

Lionel Debroux (./200) :
Il y a eu un update aux packages Debian TIEmu et TILP aujourd'hui, et l'update à TIEmu apporte GDB au package tiemu-gdb. Merci Romain

Raaah, il release TiEmu 3.03 sans me prévenir? Apparemment il n'a pas bien pris le fait que TiLP 2 1.11 a été disponible dans le dépôt Fedora avant son dépôt Debian.

Dommage que le désassembleur utilise la syntaxe GNU as

C'est fait exprès, et je suis toujours de l'avis que la version sans GDB devrait faire de même.

* affichage des move to SR en valeurs décimales;

Ça, je pourrais le changer (mais avec du 0x pour l'hexa, pas cette horreur de signe dollar qui n'a sa place que dans le nom d'une certaine entreprise de Redmond ), le problème, c'est que c'est dur de savoir dans quel contexte il vaut mieux afficher de l'hexa et dans quel autre du décimal. Mais c'est clair que pour le move to SR, le hexa est plus pratique!

* (semble-t-il) affichage des instructions inconnues (provenant par exemple du désassemblage de strings) en octal (??!)

Oui, l'octal correspond de manière naturelle à la structure des instructions 68k.

C'est partiellement ma faute, parce que j'ai essayé de transférer un programme qui n'a pas d'infos de debug

On ne peut pas utiliser Debug File with TiEmu avec un programme sans informations de débogage, et effectivement la gestion d'erreurs pourrait être meilleure là (oui, ça plante TiEmu et ça ne devrait pas), mais c'est quand-même plutôt simple d'éviter de rencontrer ce plantage.

Lionel Debroux (./202) :
Au passage, Kevin: la nouvelle version, qui n'utilise plus gettimeofday, a été envoyée le 25 mai. Aucune réaction de ta part.

Ma réaction: J'ai reçu le patch et je le regarderai aussitôt que possible. (Désolé, mais j'ai autre chose à faire aussi. Et puis il y a la coupe d'Europe de football. ) Et oui, ça va évidemment plus vite de dire non à un patch qui est une mauvaise idée depuis le départ que de relire un patch qu'on compte accepter. Prends le fait que je n'ai pas encore répondu non comme un bon signe.

Dommage que le désassembleur utilise la syntaxe GNU as

C'est fait exprès, et je suis toujours de l'avis que la version sans GDB devrait faire de même.

Ton avis n'est pas partagé, et tu le sais. En tant que mainteneur très à l'écoute de tes utilisateurs, tu pourrais proposer le choix (ou si quelqu'un le fait pour toi, intégrer les patches)

* affichage des move to SR en valeurs décimales;

Ça, je pourrais le changer (mais avec du 0x pour l'hexa, pas cette horreur de signe dollar qui n'a sa place que dans le nom d'une certaine entreprise de Redmond ), le problème, c'est que c'est dur de savoir dans quel contexte il vaut mieux afficher de l'hexa et dans quel autre du décimal. Mais c'est clair que pour le move to SR, le hexa est plus pratique !

Le '$' aussi, au lieu de 0x, ferait partie de choix qui pourraient être proposés à l'utilisateur.

* (semble-t-il) affichage des instructions inconnues (provenant par exemple du désassemblage de strings) en octal (??!)

Oui, l'octal correspond de manière naturelle à la structure des instructions 68k.

C'est pas vraiment faux, mais à peu près personne n'utilise l'octal dans le monde réel - et en particulier, ni VTI ni TIEmu sans GDB...

Raaah, il release TiEmu 3.03 sans me prévenir? Apparemment il n'a pas bien pris le fait que TiLP 2 1.11 a été disponible dans le dépôt Fedora avant son dépôt Debian.

LOL.

Mes excuses, j'ai oublié de te prévenir.

Par contre, il ne s'agit pas d'une vrai 3.03 officielle car même si j'ai mis une version GDB, elle boucle sans arrêt au démarrage. Je t'ai mailé à ce sujet car j'avais déjà eu le problème mais je me souviens plus de l'origine (rapport avec Insight je crois). Mais j'ai l'impression que le package marche pour Lionel. Tu peux confirmer ?

Je l'ai très peu utilisé, en fait
Mais non, je n'ai pas noté de problème de bouclage au démarrage, avec plusieurs ROMs différentes.

Tant que je ne debugge pas du code C, je vais peut-être repasser à tiemu-nogdb dont le désassembleur est lisible, lui...

roms (./205) :
Par contre, il ne s'agit pas d'une vrai 3.03 officielle car même si j'ai mis une version GDB, elle boucle sans arrêt au démarrage.

C'est un problème avec Tcl/Tk, peut-être le même que celui qui a été remarqué sous OS X (cf. ce topic)? Pourtant, chez Lionel, le paquetage a l'air de marcher?

Au passage:
- TiLP fêtera ses 10 ans ( ) au mois de juillet (de l'année prochaine, hehe ),
- TiEMu a fêté ses 8 ans d'existence au mois de mai dernier.

Et TIGCC ?

9 années environ, mais c'est un peu mort actuellement faute de temps. 0.96 Beta 9 est en attente depuis une éternité déjà.