beta de db92 compatible HW2 et AMS2 - Page 2

Au fait, pourrais-tu le convertir en _nostub? Vu qu'aucune librairie n'est utilisée, ce ne devrait pas être trop difficile. Il y a juste une dizaine en tout entre ROM_CALLs et RAM_CALLs à convertir.
La seule chose à laquelle il faudrait faire attention est la protection des HW2 AMS 2. Il faudra:
1. appeler enter_ghost_space ou une fonction équivalente au début: pour cela, il suffira de compresser db92 avec ExePack.
2. ajouter $40000 à l'adresse du programme à déboguer (avant d'effectuer le relogement)
3. ne pas permettre l'installation résidente de db92 ou alors savoir exactement ce que l'on fait dans le programme d'installation (vérifier la présence de h220xTSR ou HW2Patch ou alors inclure h220xTSR, ajouter $40000 à toutes les adresses de routines résidentes, ...)

Autre conseil: récupère le nom du programme à déboguer en argument sur la pile d'expressions plutôt que dans un fichier texte comme dans la version originale.

Ce sont les seules 2 choses que je peux reprocher à db92 (en dehors de l'incompatibilité avec les HW2 sur laquelle tu travailles déjà) après y avoir jeté un petit coup d'oeil sur VTI et lu rapidement sa documentation, donc si tu nous fais ces 2 améliorations, il ne resterait pratiquement plus de défauts à db92.

Si tu ne veux pas t'en occuper, je te prie de respecter la GPL qui te demande de publier tes sources pour la version modifiée, de manière à ce que moi ou quelqu'un d'autre puisse s'occuper de ces 2 choses.
[edit]Edité par Kevin Kofler le 01-09-2001 à 19:14:18[/edit]

A mon tour

Pourrais-tu le modifier pour qu'il utilise ma librairie RClib ?

En fait, à cause de l'architecture d'Universal OS, le passer en nostub empêcherait de déboguer des programmes en mode kernel.

De toute façon, ça demanderait pas mal de boulot pour RIEN DU TOUT.

>En fait, à cause de l'architecture d'Universal OS, le passer en nostub empêcherait de déboguer des programmes en mode kernel.

Pourquoi exactement? Puisque Universal OS modifie les interruptions?

Le passage en mode superviseur d'unios doit se faire avant celui de db92.

Il doit y avoir un moyen de s'en sortir. Peut-être une version "hybride" de db92. (On met la signature kernel et le stub, mais on laisse le stub vide (aucun relogement non-AMS) et on continue l'exécution même s'il n'y a pas de kernel.)

Parceque n'aime que le _nostub.

Kevin Kofler > récupérer le nom du prog à déboguer sur la pile d'expressions : c'est déja fait, même pour la version qui est faite à partir du désassemblage. un version _nostub ? peut-être, mais après avoir corriger le plus gros bug :
DB92 plante en quittant si on débogue un prog kernel archivé. Seulement je ne sais pas trop pourquoi, le plantage se produit dans le code d'UNIOS.
JM, pourrais tu m'aider ? Je pense que ça vient d'infos qui seraient stockées par UNIOS lors du lancement du prog débogué, et qui seraient récupérées à la place de celles concernant DB92.

La copie faite par db92 est libérée à la ligne 598 de db92.asm, ce qui est bien trop tôt. Cette copie doit être supprimée une fois que l'instruction à la ligne 535 est terminée.

j'ai sorti une nouvelle version.
Les bugs sont corrigés, j'attends vos réactions.

PS : si quelqu'un pouvait le mettre dans les news officielles, ce serait bien

euh, tu n'a pas mis de lien vers cette nouvele version ;( meme pas sur ton site

c'est le même fichier que l'ancienne version, je l'ai juste remplacé. Voila http://www.multimania.com/hwti/db92.zip

ok, désolé

Pour un portage _nostub, vu que db92 n'utilise pas de librairies, ce n'est pas trop difficile. (Mais je n'ai absolument pas le temps en ce moment. )

Ce qu'il faut faire:
* inclure "OS.h" plutôt que "doorsos.h" (1 ligne)
* ajouter xdef _nostub (1 ligne)
* remplacer xdef _main par un bra _main tout au début (1 ligne)
* convertir tous les ROM_CALLs de jsr doorsos::NOM en:

 move.l $c8,a0
 move.l NOM*4(a0),a0
 jsr (a0)

(10 minutes)
* rajouter $40000 à l'adresse du programme à déboguer (1 ligne)
* convertir les RAM_CALLs ou insérer du code pour trouver leurs adresses: c'est là la plus grande partie du travail

Ensuite, si on veut pouvoir supprimer complètement la version kernel, il faudra trouver une solution pour que l'on puisse déboguer les programmes en mode kernel (mais il faudra que JM nous explique le problème en détail pour que je puisse penser à un workaround le moins compliqué possible). Sinon, on peut toujours garder les 2 versions.

Alors, un volontaire pour nous faire ce portage?
[edit]Edité par Kevin Kofler le 17-09-2001 à 00:06:05[/edit]

Et pas de enter_ghost_space ?

Il suffit de compresser avec ExePack, qui utilise automatiquement enter_ghost_space.

Et si on en pas de ttpack sur sa calc, on fait comment ?

Il ne s'agit pas de compresser le programme à déboguer, mais juste db92!
[edit]Edité par Kevin Kofler le 18-09-2001 à 23:21:22[/edit]