Lionel Debroux (./177) :
et que l'AUTO_INT_5 est implémentée autrement, je ne sais pas comment. Mais après tout, peut-être n'est-ce pas fait comme ça, je n'en sais rien...

Pour ceux qui veulent voir comment est géré les auto-ints harware sur TiEmu, ils peuvent regarder la fonction hw_update() sur http://svn.tilp.info/cgi-bin/viewcvs.cgi/tiemu/trunk/src/core/ti_hw/hw.c?rev=2744&root=tiemu&view=auto.
C'est commenté à gogo donc n'importe qui peut comprendre.

C'est TRES vilain d'occuper 100% d'un coeur de processeur quand on ne fait rien embarrassed


A priori, je suis d'accord mais une TI peut être réveillée sur n'importe quelle interruption; TiEmu n'a pas cette capacité: je suis bien obligé de scruter des évènements (ie hw_update()) pour le réveil. Je vais quand même voir ce que je peux faire à ce niveau...
Pour faciliter le debug, quelqu'un peut me dire où je peux réduire la valeur de l'APD ?
Ben c'est bizare, moi c'est systématique et sur plusieurs systèmes. grin
Qu'est ce qui pourrait jouer?
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
> 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 sad
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
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 ?).
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
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 mourn



Nan, faut pas avoir peur, c'est de ma faute grin
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 grin
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
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.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Tu peux m'envoyer par mail le programme que tu as voulu envoyer (main/lib) ?
Envoyé.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Il y a un souci :

Quand on ouvre le débogueur, si on supprime toutes les pages de RAM affichées, la page de code s'agrandit vers le bas pour reprendre la place libérée par la RAM.
Si on rajoute à nouveau une page de RAM, elle agrandit le dock vers le bas pour loger, car la taille du code visible ne diminue pas.
Si on supprime une seconde fois la page de RAM affichée, la page de code s'agrandit, jusqu'à prendre maintenant toute la hauteur de l'écran. Il devient donc impossible d'afficher des pages de RAM, elles sont "sous" l'écran.

Workaround du moment : ne pas effacer la dernière page de RAM affichée.

Résolution possible :
- interdire à la page de code de s'agrandir, et afficher un espace vide si l'on a viré la dernière page de RAM
ou
- diminuer la quantité de code affichée lorsqu'on recrée une page de RAM alors qu'aucune n'était affichée.
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
Il y a un autre souci :
Dans mon code, il y a un jsr (%an) vers une fonction qui traine quelques dizaines d'octets plus haut. Lors du saut, la fenêtre du source n'est pas scrollée vers le haut.

Par contre :
- les touches f7/f8 marchent encore, ça continue l'exécution du code normallement
- si on se déplace jusqu'au code (en regardant le contenu de an), on voit bien la flèche verte devant la bonne instruction.

C'est donc juste un problème graphique.

!call roms
--- Call : roms appelé(e) sur ce topic ...
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
Autre problème :

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 grin

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. grin

Euh sinon.... Romain, t'es toujours parmi nous? grin
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
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 grin

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. grin

"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.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Kevin Kofler (./191) :
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.

Oui, j'en ai un (~/.tiemu/tiemu.ini). D'ailleurs, ça marche bien tant qu'il n'y a pas eu de reset. Idem, ça ne marche plus si on a changé de ROM (mais là ça peut se comprendre).
Kevin Kofler (./191) :
donc il faut faire un reset d'abord, ensuite tu peux faire un revert.

Et ne faire qu'une opération ne serait pas plus simple ?
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
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).
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Ah ok. Alors depuis que j'ai recompilé PedroM, j'ai perdu le .sav que j'aavis avant, ça vient donc de là, désolé et merci. smile

Sinon pour le reste, tu ne sais pas ce que deviens Romain ?
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
Bah non, désolé.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
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!
ah oui, ./188 et ./189 top

Je pensais pas te revoir grin
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
Bug ./188 fixé (toujours au moins une page de RAM).
Je pensais pas te revoir grin


Ah bon, pourquoi ?
C'est simplement que j'ai un peu arrêté pour me consacrer à l'agrégation de physique appliquée.
Merci !!
roms (./198) :
Ah bon, pourquoi ? C'est simplement que j'ai un peu arrêté pour me consacrer à l'agrégation de physique appliquée.

J'ignorais grin Bon courage et merde alors !
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
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 smile

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 grin
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 ?
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Lionel Debroux (./200) :
C'est partiellement ma faute, parce que j'ai essayé de transférer un programme qui n'a pas d'infos de debug

Tu devrais avoir la même réponse que moi avec un peu de chance : dans ta gueule, à toi de pas le faire. Comme si c'était le bout du monde de faire un test et d'afficher un message.
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
+1, malheureusement...
J'ai mis la remarque en spoiler dans ./200 (que tu as citée partiellement en clair, vilain tongue) 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é grin).

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.

avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
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 smile

Raaah, il release TiEmu 3.03 sans me prévenir? mad 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. hehe
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 grin), 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 grin

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. roll
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. wink) 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. tongue
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
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) wink
* 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 grin ), 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...
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

Raaah, il release TiEmu 3.03 sans me prévenir? mad 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. hehe

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 grin
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...
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Pareil, ça serait génial une version sans GDB sur Fedora. Mais je crois que je peux rêver...
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
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?
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Au passage:
- TiLP fêtera ses 10 ans ( fou ) au mois de juillet (de l'année prochaine, hehe picol),
- 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à. sad
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité