nouvelle version de DB92 - Page 7

ExtendeD
a écrit : Cette version fait freezer ma calc dès le lancement (et l'écran affiche n'importe quoi)

Quoi ? Elle marche sur la mienne, je vais regarder ça

PpHd > Combien faudrait-il de stack ?

LA question que je redoutais.
Heu, beaucoup, beaucoup.

Mettons qu'un programme Kernel necessite une lib, necessitant une lib, en necessitant une autre, etc.
Que chaque lib soit compresse avec machin1lib, compresse elle meme par shrnklib.
Heu... Mettons 4K au pif.

Passe plutot en mode user pour la reloc.

Tu est sûr que 4Ko suffiront dans tous les cas ? (je vais quand même voir pour repasser en mode user au moment de le reloc si c'est possible, ça utiliserait moins de mémoire)

voila tout est corrigé : même adresse de download

Il utilise la pile user pour (un)reloc2 (tout en restant en mode superviseur)

Ca devrait marcher. Mais j'ai pas envie de tester.

Je vais tester, moi.

Est-ce que ER_success est identique sur tous les AMS ?

Mon problème est que en travaillant sur l'affichage des erreurs ER_throw, j'ai trouvé un bug : si on quitte DB92 alors que l'on déboguait un programme ayant éxécuté ER_catch mais pas ER_success, AMS plante. Comment remédier à celà ?

hwti
a écrit : Est-ce que ER_success est identique sur tous les AMS ?

À priori oui.

Mon problème est que en travaillant sur l'affichage des erreurs ER_throw, j'ai trouvé un bug : si on quitte DB92 alors que l'on déboguait un programme ayant éxécuté ER_catch mais pas ER_success, AMS plante. Comment remédier à celà ?

Une idée (je l'écris en C là, il faudra mettre ça en assembleur pour DB92):
ERROR_FRAME buffer;
ER_catch(buffer);
void *origerrframe=buffer->Link;
ER_success();

// lance le programme

void *errframe;
while (1) {
ER_catch(buffer);
void *errframe=buffer->Link;
ER_success();
if (errframe==origerrframe) break;
ER_success();
}

erf, je me connectais pour poster exactement le même bout de code
Je l'ai fait en asm, je ne l'ai pas testé, j'espère qu'il n'y a pas de bug :

juste avant d'appeler le programme, on trouve l'ancre de la liste chaînée des ERROR_FRAMEs :

 move.l ($C8).w,a5
 lea -$3C(a7),a7 ; de la place pour un ERROR_FRAME
 pea (a7)
 move.l ER_catch*4(a5),a0
 jsr (a0) ; un ER_catch bidon
 lea ERR_FRAME_anchor(pc),a0
 move.l $38(a7),(a0) ; l'ancre de la liste chaînée
 move.l ER_success*4(a5),a0
 jsr (a0) ; on supprime l'ER_FRAME bidon de la liste
 lea $3C+4(a7),a7

 (...)

ERR_FRAME_anchor dc.l 0

Puis juste après l'exécution du programme, on regarde si l'ancre a bougé, si c'est le cas on enlève tous les ERR_FRAME en trop dans la liste chaînée :

 
 move.l ($C8).w,a5
 lea ERR_FRAME_anchor(pc),a0
 move.l (a0),d4
 lea -$3C(a7),a7 ; de la place pour un ERROR_FRAME
FreeErrFrames:
 move.l a7,-(a7)
 move.l ER_catch*4(a5),a0
 jsr (a0) ; un ER_catch bidon
 move.l $38(a7),d3 ; l'ancre actuelle de la liste chaînée
 move.l ER_success*4(a5),a2
 jsr (a2) ; on supprime l'ER_FRAME bidon de la liste
 cmp.l d3,d4 ; l'ancre actuelle est-elle l'ancienne ancre ?
 beq.s FreeErrFramesDone ; oui -> on a tout nettoyé
 move.l d3,(a7) ; sinon on supprime l'ERR_FRAME en trop
 jsr (a2)
 addq.w #4,a7
 bra.s FreeErrFrames ; on verifie s'il n'y a oas 
FreeErrFramesDone:
 lea $3C+4(a7),a7

OK je vais tester ça. Aucune ER_frame n'est jamais déplacée lors de réorganisations de la RAM ? Même celles utilisées par le système ? Parce que l'AMS et les bugs bizarres...
(je me souviens du temps que j'avais passé à trouver la cause d'un plantage aléatoire dans DB92, il fallait refaire un FindSym pour retrouver le twin à supprimer alors que si on passait directement l'adresse qui n'avait pourtant pas changé ça plantait)

Les ERROR_FRAMEs sont donnés en argument par le programme qui appelle la rom call, donc de toute façon c'est à lui de s'assurer que le bloc où se trouve l'ERROR_FRAME est locké.

voila la 0.36 http://membres.lycos.fr/hwti/db92-nostub-alpha-036.zip
- appel de ER_catch et gestion des ER_throw
- correction de bugs dans la fenêtre des registres
- correction du kernel loader ($34)
- amélioration de la routine de swap d'écran
- ...

La fenêtre des registres est plus petite ?
Et il y a 2 petits bugs : quand on fait F5, le bas de l'écran est mal affiché (du blanc ou n'importe quoi parfois). Et l'explorateur de fichier descend un peu trop bas, on ne voit pas le dernier fichier.
Et on ne peu plus éteindre la calc dans db92 (ça crashe parfois quand on essaie, ou après quand on quitte).
Et j'ai eu un crash en éteignant la calc sous l'OS après avoir utilisé db92, mais je n'arrive pas à le recréer, donc je suis pas sûr que ça vienne de lui.

sur 92+ ?
l'exctinction je ne pense pas que ce soit DB92 (j'avais bien vérifié ça quand j'avais corrigé cette routine)
les autres problèmes sont surement liés à des modifications faites pour la 89 que je n'ai pas répercutées sur la 92+ (je ne teste presque que sur 89 c'est vrai)

Ok.

Pourtant pour le problème de l'extinction, je n'ai rien d'autre installé (pas de kernel ni tsr, juste après un reset).

On obtient une protected memory violation si on modifie la valeur d'un des registres
Ca a l'air d'être de plus en plus difficile à maintenir, ce projet, tu es courageux (et il semble qu'on est plus beaucoup à l'utiliser).

Moi je m'en sers quotidiennement... mais mon niveau en ASM n'est pas comparable aux votres, donc... en plus j'ai encore une vieille alpha, la 0.34, mais j'en suis très content. Je me mettrai à jour dans peu de temps pour être actif sur le béta-test.

pour les registres j'avais corrigé ça est c'est revenu (surement lors de modifications ailleurs, j'ai un peu optimisé ces routines)

ExtendeD
a écrit : Ca a l'air d'être de plus en plus difficile à maintenir, ce projet, tu es courageux (et il semble qu'on est plus beaucoup à l'utiliser).

En effet. Moi, ça fait lontemps que j'ai laissé tomber ce projet...

Mais ce n'est pas possible de le reprendre à 0 ?
Ce serait trop compliqué ou trop long ?

reprendre à 0 ?
ce n'est pas impossible, mais ça prendrait un temps fou (regarde la taille des sources) et ce serait compliqué aussi (il faudrait quelqu'un ayant beaucoup de motivation, le temps, et le niveau)

je l'utilise de temps en temps...
moins pr débogguer mes progs que pour matter le code de la ROM (code de certains ROM_calls ou autre, plus par curiosité qu'autre chose)

(je sais que VTI le fait aussi, mais qd je n'ai pas de PC, je n'ai pas VTI )

pour l'extinction, je n'ai pas trouvé de problème, mais j'ai un gros bug :
sur AMS1.05 (89 et 92+) on a address error dans AMS si on quitte DB92 par 2 appuis rapides sur ESC, et également si on a éteind la calc (le plantage a l'air de se produire plus tard dans ce cas)
pas de problèmes sur AMS2

ExtendeD : tu n'aurais pas d'idée là ? parce que le bug se produit pas dans le code de DB92. (pour l'extinction, c'est peut-être parce que le trap #4 est éxécuté avec a7=$4300 )

Oui, c'est bien ça le problème.
NG_execute() a sa pile à ce niveau là quand il lance DB92, et elle est abimée par les appels des trap et des fonctions avec ce pointeur de pile (le problème quand on quitte vient du move.w #$4230,a7 dans insthandlers, c'est le même problème).
Pourquoi ne pas tout simplement utiliser la pile superviseur qu'on peut vraiment utiliser, celle donnée par SSP au démarrage du programme ? (je sais pas trop si c'est possible, je n'ai pas vraiment regardé les sources).

la pile de NG_execute ? l'estack ?
$4300 n'est pas cencé être dans la zone réservée pour la pile système ?

utiliser le SSP d'origine pose des problèmes : on doit prendre celui du programme débogué pour si il utilise la pile système, mais si le programme alloue une autre pile système comme le fait DB92, elle n'est pas dans les bonnes adresses donc le trap #4 fait un reset. On peut détecter ce cas mais alors il est impossible de déterminer l'adresse de la pile système d'origine (si le programme utilise à la fois la pile système et une autre alouée).

Donc il faudrait trouver une zone libre sur AMS1 et 2 qui soit dans la plage acceptée par le trap #4, car on pourrait interdire l'extinction dans les cas qui posent problème, mais çe serait plus gênant pour insthandlers (on ne pourrait plus faire sauver les vecteurs d'interruption par le trap #11)

hwti
a écrit : la pile de NG_execute ? l'estack ?

Non, la vraie pile (utilisateur je crois).

Et est-ce qu'il existe vraiment des programmes qui utilisent une deuxième pile superviseur ? Si c'est le cas, ils sont très minoritaires et on peut se passer de les debugger.

j'ai mis $4500 à la place de $4230 et $4300
ça semble fonctionner correctement (si on prend les limites fixées par le trap #11, la SSP est entre $4200 et $4C00 pour AMS2 et entre $4400 et $4C00 pour AMS1)
j'ai également corrigé les problèmes sur la 92+ et le bug dans la modification des registres

hwti
a écrit : j'ai mis $4500 à la place de $4230 et $4300

mouais, je trouve ça quand même pas propre.

j'ai également corrigé les problèmes sur la 92+ et le bug dans la modification des registres

ExtendeD a écrit :
mouais, je trouve ça quand même pas propre.

c'est le plus simple, mais sinon je peux utiliser le SSP du programme et ne pas appeler les traps #4 et #11 si il est incorrect avec les critères AMS1 (les plus restrictifs), mais dans new_auto6 il faut dans ce cas tester le SSP pour voir si il est correct, ou si c'est celui de DB92, ou si il est incorrect

Oui, ça serait mieux.