DB92 en _nostub - Page 5

Ça m'énerve de devoir ressortir une alpha pour si peu de choses, mais voilà. Nouvelle alpha (0.26) qui corrige le bogue du Line1111 en mode utilisateur.
[edit]Edité par Kevin Kofler le 09-01-2002 à 13:19:02[/edit]

Je suis d'accord avec Kevin (post 117).

Et la nouvelle alpha avec fix des nostub retournant une valeur ?

Demain ou après-demain probablement. (J'ai d'autres choses à faire aussi.)

>J'ai d'autres choses à faire aussi.

Hehehe...

En tout cas c'est du tres bon boulot.

Quand même

Comme la version _nostub peut maintenant bien déboguer les progs kernel, je ne sais pas si je vais continuer ma version.
J'ai corrigé quelques petites chose cette semaine et certaines concernent la version _nostub:
1- il faut ajouter clr.w -(a7) avant pea.l Prg_Name(pc) et c'est donc addq.l #6,a7 après.

2- move.l a5,d0
beq a5nul
move.b #$20,(a5)
a5nul
ne servent plus à rien

3- move.l a1,envaddr ne sert à rien

4- beacoup de variables semblent ne pas être utilisées : IsTSR, DumpMode, VarSelAddr, LabSelAddr, FindSymbLen, EnvAddr, OldStackSize
certaines sont peut-être utilisées sans que leur nom soit mentionné (par rapport aux variables précédentes, peut-être)

5- RCNum est mis en tant que variable alors que ça ne sert à rien, on peut la remplacer par une constante

6- il faudrait mettre une routine du même type que celle pour Adress Error sur Protected Memory Violation, car si cette erreur ce produit db92 quitte.

7- il faut inverser bsr Do_ClrScr et bsr DBScreen dans la routine Do_MsgBox (dans C2.asm)

8-je ne sais pas si tu as corrigé les bugs des routines d'interception d'adress error et autre, car sur ma version, après un adress error, PC pointe sur l'adresse lue ou écrite et pas sur le code qui a provoqué le bug.

Je vais vérifier tout ça, parce que j'ai fait un certain nombre de changements dans ma version et je ne sais pas si tout s'applique encore tel quel.

Et la routine du Address Error ne marche pas correctement chez moi non plus.

J'ai en principe corrigé le problème du RETURN_VALUE (mais pour les programmes qui utilisent la pile d'expressions, il ne faut pas les relancer tout de suite après une exécution terminée ou après F2, ça ne marche pas encore, il faut quitter et relancer DB92) et les points 1-2 et 6-8 de hwti, mais il faut que je teste tout ça avant de sortir une nouvelle alpha. Et pour les points 3-5, ce n'est que du code inutile qui ne fait rien de grave, donc je verrai ça après.

Ca avance vite

ouais youpi ! vive kevin !

ça, c'est une manifestation d'enthousiasme, ou je ne m'appelle plus squale92

topic.up();

c'est pour quand la prochaine alpha ??

J'ai trouvé un bug assez gênant : on ne peux plus affichier Breakpoints & Files, db92 crashe

Et j'ai trouvé un truc bizarre:
Si je compile ca avec side:
rts
dc.b 0
et que je le debugge avec db92, il y a une address error... Et ca me fait ca même pour des sources très longues. Si je rajoute un dc.b 0 a la fin de la source, ca corrige le bug, mais c'est quand même bizarre...

Sinon ma connection internet remarche, et je suis un peu plus disponible, je pourrais continuer à corriger les bugs restant. Je vais encore chercher comment gérer le mode superviseur correctement (j'ai encore trouvé pleins de bug de débugage de trap et d'instruction qui modifient sr, ou qui touchent à la pile en superviseur), et je vais encore chercher pour une protection efficace contre le débugage du trap #11.

Je vois qu'il reste une montagne de bogues.
Il y a aussi l'histoire du [F5] qui marche très mal avec les niveaux de gris. (J'ai essayé avec TI-Chess, et avec SMQ sous PreOs, et à chaque fois plantage.)
Pour la prochaine alpha, c'est vrai que je n'ai plus fait grand chose sur DB92 depuis un certain temps. Je vais essayer de sortir quelque chose demain ou après-demain. Mais en voyant le nombre de bogues qui restent, je ne suis pas très motivé de sortir quoi que ce soit.
[edit]Edité par Kevin Kofler le 20-01-2002 à 22:09:21[/edit]

au fait jai eu bug magnifique javais un programme que jai compile on calc avec as et quand je le lancais ca me faisais un protected memory violation. alors je lai lance avec db92 pour voir pourkoi il marchait pas (paske compilé sur mon pc il marchait) et pis je sais plus exactement mais ca ma refait des protected memory violation et quand jai voulu etaindre ma calculette jai eu un superbe ecran de db92 stack corrupted alors que je pensais lavoir quitter depuis un sacre bout de temps puis un superbe ecran bleu (alors que jai une 89 hw2 hein alors le bleu cest beau mais faut pas deconner) et ben je mesuis jete dessus pour enlever une pile et heureusement elle marche.
ben si tu veux tous ce que javais quand ca mest arrive je veux bien te lenvoyer (tu crieras pas en disant quon tempeche de reproduire les bugs) mais bon je sais pas exactemnet comment jen suis arrive la et puis je pense que cest pas top pour la calc et sous vti ca le fera pas (pas lecran bleu en tout cas)

Il faut se rappeler que db92 récuppère les bugs comme il peux, mais si ton prog a écrit n'importe où dans la mémoire, ce qui n'a pas forcément des conséquences tout de suite, il ne peux pas faire grand chose...

Kevin Kofler> ah oui aussi un autre truc tout bête, Address Error ca s'écrit avec 2 'd', c'est marrant que personne ne s'en soit rendu compte

Pour ton histoire de pb de rts / dc.b 0, regarde avec un hexa editeur le contenu exact de ce qu'a compile as.

J'ai regardé rapidement, il n'y a pas l'air d'y avoir de problème. Le programme tourne parfaitement, et on peut le debugger sous vti.

mon programme fonctionnait parfaitement compile sur mon pc

>jpflori: j'aimerais bien voir ta source.
[email]ola.e-ml@wanadoo.fr[/email]

>ExtendeD:
>Et j'ai trouvé un truc bizarre:
>Si je compile ca avec side:
>rts
>dc.b 0
>et que je le debugge avec db92, il y a une address error... Et ca me fait ca même pour des sources très longues. Si je rajoute un dc.b 0 a la fin de la source, ca corrige le bug, mais c'est quand même bizarre...

Il faudra que Nitro fasse en sorte que AS mette la table de relogement toujours à une adresse paire, c'est-à-dire qu'il faut rajouter un 0 si la taille du programme sans compter la table de relogement et l'ASM_TAG est impaire.
Le problème ne se pose pas avec A68k parce que pour les programmes produits par A68k, la taille du programme sans compter la table de relogement et l'ASM_TAG est toujours multiple de 4.
[edit]Edité par Kevin Kofler le 22-01-2002 à 21:18:03[/edit]

cetait ptete aussi paske javais une vieille version de as mais celle la je lai plus ........... par contre jai la source

Au fait, je ne sais pas si ça concerne ton problème. (J'ai corrigé le message précédent.) Un programme avec une taille impaire causerait plutôt un "Address Error" comme chez ExtendeD. Je pense que ton problème est plutôt autre chose.
[edit]Edité par Kevin Kofler le 22-01-2002 à 21:19:27[/edit]

>Il faudra que Nitro fasse en sorte que AS mette la table de relogement toujours à une adresse paire

Tiens je savais pas ça... ?

La table de relogements est constituée de words, donc si c'est à une adresse impaire, problème. À moins que EX_patch ne lise ça octet par octet (auquel cas ce serait DB92 qui est fautif)...
[edit]Edité par Kevin Kofler le 22-01-2002 à 21:30:47[/edit]

Bon, j'ai vérifié et au fait EX_patch lit les words octet par octet. Je vais faire de même dans DB92 (ou tout simplement utiliser EX_patch). (Tu ne dois pas modifier AS.)
[edit]Edité par Kevin Kofler le 22-01-2002 à 21:34:50[/edit]

Il faut quand meme savoir que certains programmes (i.e. userlib de teos ou dorrsos) le font a la main, et ils le font word par word.

Et ils ne respectent pas le format. Ce n'est pas as qui est le coupable. (Il y a une raison que EX_patch travaille octet par octet.)