DB92 en _nostub - Page 2

ya pas un fichier ou on parle des traps paske le vieux papier de doors os jai limpression que ya po tout ....

À part celui de DoorsOS, il n'y a pas grand chose.

Au fait, j'ai rajouté (mais ça ne sera publié que demain, probablement avec d'autres corrections) un PortRestore en quittant pour éviter le pire avec TI-Chess (au moins si on le termine avec [F2], puis quitte, on verra quelque chose sur l'écran HOME). Mais ça ne me dit toujours pas:
- pourquoi il y a une Illegal Instruction (interceptée par DB92) quand j'interromps TI-Chess avec [ON]+[ESC], puis continue avec [r]
- pourquoi tout plante quand j'interromps TI-Chess avec [ON]+[ESC], puis essaye d'afficher l'écran avec [F5]
Ça doit être parce que TI-Chess utilise intensivement les auto-interruptions pour lire les touches. Mais il faudrait trouver un moyen de contourner ces problèmes.

Nouvelle alpha (0.22) à l'adresse habituelle.
Nouveautés:
* appelle maintenant PortRestore en sortant
* correction d'un bogue avec les programmes de plus de 32 KO
* possibilité de déboguer des programmes pour kernel, mais seulement avec un kernel qui supporte les fonctions reloc2 et unreloc2 (pour l'instant DoorsOS et TeOS), pas avec Universal OS
* correction de l'écran about

Et évidemment je ne garantis rien sur la stabilité du débogage des programmes pour kernel - je peux juste dire qu'avec Thunder (la version que HerveRV m'avait passée pour tester A68k) sous VTI-89 avec AMS 1.05 et TeOS 1.02, ça n'a pas planté.
[edit]Edité par Kevin Kofler le 27-12-2001 à 04:20:45[/edit]

PpHd, si tu m'entend... voila une paire de fonction à rajouter à PreOS...

Elles n'y sont pas encore? Ce n'est pas bien... Espérons au moins qu'il utilise une architecture qui lui permette de les mettre (pas comme celle de Universal OS).

Quant à Universal OS, je ne pense pas que JM ait le temps de s'en occuper, mais il devrait absolument exporter (c'est-à-dire mettre l'adresse dans la table des vecteurs) une API qui me permet de lancer un programme pour kernel sans activer l'anticrash des kernels et tout ce qui va avec (DB92 a son propre anticrash et a besoin d'autres traps détournés). À la limite, peut-être en sautant à une adresse de style *(void **)(0x34)+xyz... Mais je n'ai pas vraiment envie de passer Universal OS au débogueur de VTI pour faire ça.
[edit]Edité par Kevin Kofler le 27-12-2001 à 12:36:26[/edit]

y'a encore un truc qui déconne (et qui plantait dejà dans les versions précédentes) c'est le debugage de l'instruction 'rte' qui donne une illegal instruction.

dans la 0.46 en tout cas, elles n'y sont pas encore

>ExtendeD: y'a encore un truc qui déconne (et qui plantait dejà dans les versions précédentes) c'est le debugage de l'instruction 'rte' qui donne une illegal instruction.

Voilà (vraisemblablement) ce qui ne va pas avec TI-Chess (message 32). Mais je fais comment pour que ça marche?
[edit]Edité par Kevin Kofler le 27-12-2001 à 12:55:22[/edit]

Et peux-tu me dire ce que tu veux que je mette pour "protéger" le trap 11?
[edit]Edité par Kevin Kofler le 27-12-2001 à 15:25:08[/edit]

J'attends encore d'avoir d'autres corrections avant de sortir une nouvelle alpha, mais DB92 quitte maintenant (dans la prochaine alpha, pas encore sortie) proprement si on essaye de déboguer un programme pour kernel sans kernel ou avec Universal OS (il affiche un message "Incompatible/no kernel").

Argh, je suis en train de "combattre" avec Phoenix pour lui empêcher de détourner l'interruption Trace et faire planter DB92. C'est vraiment idiot les programmes qui mettent n'importe quoi dans Trace en guise d'"anti-crash"!

Je n'arrive pas à faire une protection en même temps efficace et de taille et surtout vitesse raisonnable du vecteur Trace.
[edit]Edité par Kevin Kofler le 27-12-2001 à 19:29:02[/edit]

J'ai réussi à mettre la protection sur le débugage du trap #11 : si on appuie sur F7 pour demander un traçage, un 'jump over' du trap #11 sera fait à la place.
Mais je me suis rendu compte que les trap n'étaient pas gérés comme des branchements, donc les 'jump over' au-dessus des trap ne fonctionnent pas, et c'est assez gênant (seul un 'jump over' sur le trap #11 fonctionne avec ma correction). Je vais essayer de corriger ça, et je te mail les bouts de sources corrigés.

Sinon y'a aussi un autre problème avec le trap #11, qui viendrait d'un bug de l'AMS (enfin pas vraiment, mais je pense que si quand même) : si on lui donne un mauvais argument (cad un d3.l supérieur à 13), ou si la valeur de a7 n'est pas dans la zone des valeurs autorisées, le trap #11 file tout de suite à la routine de reprotection de la flash, remet tous les vecteurs d'interruptions et quitte. Et c'est ça le problème, qu'il remette les vecteurs d'interruptions : cet imbécile ne les a pas sauvé : la sauvegarde des vecteurs ce fait après avoir fait les tests de d3 et a7. Donc ça fait qu'après l'execution du trap #11, tous les vecteurs d'origine de l'AMS sont remis. Donc il n'y a plus (entre autre) le nouveau vecteur du trap #13, utilisé pour les breakpoints par db92, et ça fait tout planter.
Je vais corriger ça en mettant une sauvegarde et une restauration des registres avant et après l'appel du trap #11. Je te mail tout dès que c'est prêt.

OK, merci beaucoup! Mais n'oublie pas que DB92 passe aussi en mode Trace quand on met un point d'arrêt n'importe où en ROM! Ni que enter_ghost_space appelle directement le trap 11 par un jmp (an).
Et pour rte et pour le code qui veut écrire dans Trace ($24) - comme Phoenix -, as-tu des idées (le rte doit être beaucoup plus facile)?
[edit]Edité par Kevin Kofler le 27-12-2001 à 19:42:04[/edit]
[edit]Edité par Kevin Kofler le 27-12-2001 à 19:43:54[/edit]

Ah oui, j'avais oublié que c'était un jmp que enter_ghost_space utilisait. Dans ce cas ca devient vraiment infaisable: un breakpoint à l'instruction d'après ne fonctionne plus, il faudrait lire ce qu'il y a sur la pile, etc... Ou peut-être en redirigeant le trap #11 dès le debugage du programme...

Les trap sont finalement bien reconnus comme des sauts, et un F8 devrait marcher, mais apparement ça déconne avec les trap #11 et 12, c'est bizarre.
Sinon pour éviter qu'un trap #11 sans argument fasse tout planter, il suffit d'executer un trap #11 juste avant avec comme argument 0 dans d3 et 0 dans a3, pour que le trap #11 crée la table de sauvegarde des vecteurs d'interruption, mais quitte en voyant que l'on veut écrire en flash à l'adresse zero. Comme ça à l'appel du trap #11 suivant, la table des vecteurs existe et est correcte.

Pour le rte je ne voit pas, ca vient du fait que db92 veut tourner en superviseur, mais faire tourner le programme en utilisateur... Peut-être que ça fait mélanger piles utilisateur et superviseur, ou quelque chose comme ça. Ca n'est pas si facile à corriger. Ca me fait penser que c'est peut-être a cause de ça que le débugage de tib-receiver a fait planter ma calc.

Pour phoenix: ou se trouve le bout de code qui touche au trace? Je ne le trouve pas dans les sources.

>Ah oui, j'avais oublié que c'était un jmp que enter_ghost_space utilisait. Dans ce cas ca devient vraiment infaisable: un breakpoint à l'instruction d'après ne fonctionne plus, il faudrait lire ce qu'il y a sur la pile, etc... Ou peut-être en redirigeant le trap #11 dès le debugage du programme...

Je sais ce qu'il faut mettre pour que enter_ghost_space ne fasse absolument rien (ne touche pas au trap 11 de la ROM). Et vu qu'on est déjà dans l'espace fantôme, ça ne fera pas de mal.
Mais il doit aussi être possible de lire l'adresse de retour sur la pile.

>Pour phoenix: ou se trouve le bout de code qui touche au trace? Je ne le trouve pas dans les sources.

Dans init.asm:

        lea     crash_handler(pc),a0    ; Install crash handler
        moveq   #9,d0
        lea     ($8).w,a1
loop_install:
        move.l  (a1),-(sp)              ; Push old handler on stack
        move.l  a0,(a1)+                ; Install new one
        addq.l  #6,a0
        dbra    d0,loop_install

et:

        lea     ($30).w,a1              ; Uninstall crash handler
        moveq   #9,d0
loop_uninstall:
        move.l  (sp)+,-(a1)
        dbra    d0,loop_uninstall

[edit]Edité par Kevin Kofler le 27-12-2001 à 22:36:55[/edit]
[edit]Edité par Kevin Kofler le 27-12-2001 à 22:38:25[/edit]

Nouvelle alpha (0.23). Pas beaucoup de nouveautés. La seule chose est que ça quitte proprement quand on essaye de déboguer un programme pour kernel sans kernel ou avec Universal OS.

PS: Je serai chez mes grands-parents les 2 jours qui viennent, donc ne vous attendez pas à de nouvelles alphas avant dimanche soir. (C'est aussi la raison pour laquelle j'ai choisi de sortir la 0.23 tout de suite.)
[edit]Edité par Kevin Kofler le 28-12-2001 à 00:35:31[/edit]

Pour le problème du rte, il me semble qu'il suffit de lire. En effet:
Le programme débogué tourne en mode utilisateur, mais il est toujours possible de redéfinir les priorités d'interruption ('privilege violation' est redirigé pour permettre cela). Comme le débogueur doit utiliser l'auto-int 6 (pour tester la touche ON), il n'est pas possible d'affecter une valeur supérieure à 5 aux bits de priorité d'interruption, donc ne soyez pas surpris si après l'éxécution d'un "move #$2700,sr" vous voyez $0500 dans sr.
Et:
;Pour pouvoir règler le niveau d'interruptions
;On simule l'execution de l'instruction pour pouvoir connaitre
;la valeur des nouveaux bits
New_Privilege:

En d'autres mots, je pense qu'il faut changer New_Privilege pour que rte ne soit pas exécuté directement, mais émulé manuellement. (Je vais m'en occuper.)

Je précise aussi une chose qui me vient à l'esprit maintenant: Il n'est pas possible de déboguer des programmes pour kernel compressés (quel que soit le compresseur - ExePack pour programmes kernel ou RUNC) avec DB92 _nostub (du moins pas pour maintenant - peut-être si je détourne $34..., mais d'autres corrections ont une priorité bien plus importante pour l'instant).

J'ai aussi commencé de porter AutoSymb de DB92 on-calc, mais ce n'est pas encore tout à fait au point. Mais de toute façon, tant que as (de Nitro) ne comprend pas les macros, ça n'a pas beaucoup de sens. (Le but serait de permettre d'utiliser les informations symboliques de db92 avec as.)
[edit]Edité par Kevin Kofler le 28-12-2001 à 04:44:05[/edit]

Je peux modifier AS pour produire les info symboliques si on me donne le format

c'est une bonne nouvelle ...

bon. Il y a beaucoup de bugs. Que dois-je corriger dans la version kernel ?
uniquement le problème de relocation ??
C'est bizarre, il me semble que je l'avais déja testé sur des progs nostub archivés

1. Dans db92.asm, rajouter:
RelocSPSave dc.l 0,0,0 ;pour TI-Chess
devant SavedRegs, rajouter:

;compatibilité avec TI-Chess
		move.l (a7),RelocSPSave
		move.l 4(a7),RelocSPSave+4
		move.l 8(a7),RelocSPSave+8

entre move.l a1,RegA7 et move.l a7,RelocSP et rajouter:

;compatibilité avec TI-Chess
	move.l RelocSPSave(PC),(a7)
	move.l RelocSPSave+4(PC),4(a7)
	move.l RelocSPSave+8(PC),8(a7)

devant movem.l RegsV,d0-d7/a0-a6, tout ça pour corriger le plantage avec TI-Chess.
2. Dans db92.asm, supprimer:

		move.w	(a0),d0
		lea	1(a0,d0.w),a1
		cmp.b	#$F3,(a1)
		bne	PC_NotFound

	    ; Reloc the	TIOS table
	       rloop:
		moveq	#0,d0
		move.w	-(a1),d0
		beq	endr

		moveq	#0,d1
		move.w	-(a1),d1
		add.l	a0,d1
		addq.l	#2,d1
		move.l	d1,2(a0,d0.l)

		bra	rloop
	       endr:

et rajouter:

		moveq #0,d0 ;programmes >32 KO
		move.w	(a0),d0
		lea	1(a0,d0.l),a1 ;.l pour les programmes >32 KO

		cmp.b	#$F3,(a1)
		bne	PC_NotFound
	    ; Reloc the	TIOS table
	       rloop:
		moveq	#0,d0
		move.w	-(a1),d0
		beq	endr

		moveq	#0,d1
		move.w	-(a1),d1
		add.l	a0,d1
		addq.l	#2,d1
		move.l	d1,2(a0,d0.l)

		bra	rloop
	       endr:

		;infos symboliques _nostub
		cmp.w #$4e71,2(a0) ;compare avec nop
		bne NoNostubSymbols ;si pas nop, pas d'infos symboliques
		cmp.l #'DB92',8(a0) ;compare avec 'DB92'
		bne NoNostubSymbols ;si pas 'DB92', pas d'infos symboliques
		move.l 12(a0),d0
		adda.l d0,a0
		add.l d0,(a7)
NoNostubSymbols:

juste après PasArchive. Ça corrige en fait 3 choses:
- le déplacement des routines corrige le problème du relogement des fichiers _nostub archivés
- le changement du début corrige 1 des 2 problèmes avec les programmes >32 KO
- le rajout de la fin permet l'ajout d'informations symboliques aux programmes _nostub
3. Dans db92.asm, remplacer:

		move.w	$e(a0),d0
		lea	2(a0,d0.w),a0

par:

		moveq #0,d0 ;programmes >32 KO
		move.w	$e(a0),d0
		lea	2(a0,d0.l),a0 ;.l pour les programmes >32 KO

pour corriger l'autre problème avec les programmes >32 KO
4. Dans compat92.h, dans l'écran About sur TI-92+, le nombre devant la ligne sur [ON]+[ESC] devrait être 14, pas 28.

Et j'ai déjà reporté le fait que TI-Chess détruit la fin de la pile superviseur sur le forum de la TICT.

J'ai corrigé le bug du rte et des bugs de débugage de trap, je t'ai envoyé les sources corrigées.

Je verrai ça demain. (Je ne suis rentré chez moi que ce soir, et j'avais un bogue de TIGCC - dans obj2ti: les programmes kernel qui utilisaient des librairies dynamiques en C ne marchaient plus - à corriger - ils me soulent ces kernels avec leur format hyper-difficile à linker .)

Et Nitro, pour le format des informations symboliques, tout ce que je peux te dire pour l'instant, c'est:

nop: NOP
 bra.w endsymb
 dc.l 'DB92',endsymb-nop
 include PROGNAME.sdb
endsymb:

au début d'un programme _nostub, ou:
include PROGNAME.sdb
juste avant le _main d'un programme kernel.
Pour le format du sdb, regarde le répertoire autosymb de mon ZIP, je ne sais pas plus sur le format que toi.
Je peux aussi te mailer le portage C on-calc (à partir de C++ on-PC) non fini de autosymb si tu le veux.
Sinon, je pensais faire l'expansion des macros de autosymb directement dans autosymb on-calc, ça t'éviterait de modifier as.
[edit]Edité par Kevin Kofler le 30-12-2001 à 04:00:32[/edit]

Ok, j'ai compris tout le format... et c'est faisable automatiquement dans AS directement sans trop d'overhead, donc je vais m'en occuper.

Pour le format des kernels hyper-difficile à linker je te comprends, j'ai beaucoup de mal aussi

Oublie le format kernel. Vraiment. Ceux qui le veulent n'ont qu'à programmer on-PC avec le paquet TIGCC (ou avec les paquets du millénaire passé qui accompagnent certains vieux kernels du dernier millénaire).

erf

Je crois que le break par ON+esc sur 89 ne marchait pas. Je l'ai corrigé.
J'ai aussi rajouté une combinaison pour reseter lorsque le programme crashe complétement (ce qui évite d'avoir à retirer une pile, c'est très gênant quand ça arrive souvent). J'ai aussi ajouté une combinaison pour faire un shutdown dans le débuggeur.