Adebug en GPL - Page 3

Donc finalement, tu es a quel etat d'avancement si on se base sur la derniere version de adebug/assemble connue?
Quelle est ta roadmap? Tu orientes ton developpement plus vers le falcon et en mettant de cote les STE/F?

frost :
Stabylo: excellent !!! A quand une release débuggée ?

Pour l'instant, je me suis contenté d'un hack: je devrais attendre la VBL, mais je fais juste une boucle sur un NOP 2^16 fois (je voulais juste vérifier que le correctif était le bon)

Japrès je mettrai de l'ordre dans tout ça pour faire les choses correctement (c'est pas évident d'attendre la VBL quand on est potentiellement en IPL 7, mais j'ai vu que Brainstorm avait codé une routine "wait_vbl" qui doit prendre cette difficulté en compte, donc il y a de l'espoir )

skweek :
Donc finalement, tu es a quel etat d'avancement si on se base sur la derniere version de adebug/assemble connue?

La dernière version connue est la 2.12, mais comme Brainstorm n'incrémentait pas le numéro de version quand ils faisaient des correctifs, il y a potentiellement eu plusieurs version 2.12 . C'est en consultant le fichier TXT d'historique qu'on peut se faire une idée de la version qu'on a.

skweek :
Quelle est ta roadmap? Tu orientes ton developpement plus vers le falcon et en mettant de cote les STE/F?

Je voudrais ouvrir le CVS aux anonymes. Je voudrais que les gens intéressés récupèrent les sources, postent des patchs sur la mailing-list. Je voudrais aussi pouvoir donner un accès CVS complet aux gens qui le désirent. Bref, je voudrais qu'on puisse s'y mettre à plusieurs! .

Ensuite, le premier objectif sera d'ajouter le support de la CT60, puis des machines 060 et 040 en général. C'est (selon moi) prioritaire. Le reste viendra ensuite, ce seront des petits correctifs, et des nouveaux trucs. J'ai plein d'idées et je suis ouvert à toutes les suggestions. Tu en as pour les STE/F ?

stabylo :
J'ai plein d'idées

Pour compléter mon message : il y a plein de choses qu'on pourrait ajouter à Adebug, tant pour l'interface (utilisation de la couleur), que dans la robustesse (utilisation de la PMMU pour mieux protéger les zones mémoires d'Adebug, voire pour dissimuler Adebug du programme tracé [possible avec 030 ou plus]).

En ce moment, je bosse un peu sur STeadier, qui permet de rediriger les accès FDC (disquette) vers un fichier MSA. Dans l'esprit, ça se rapproche du concept de virutalisation (pensez VMware). Eh bien si ça s'avère utile, on peut imaginer d'ajouter des trucs comme ça à Adebug!

Héhé ça bosse dur chez les Removers

J'ai hâte de voir STeadier tourner sur CT60

Strider :
J'ai hâte de voir STeadier tourner sur CT60

Heu.. on n'y est pas encore il y aura quelques petites difficultés à résoudre car la PMMU 060 est moins souple que celle su 030...
Pour l'heure, je ne vais pas trop m'étendre ici ; je pense qu'on ouvrira un thread STeadier quand on aura avancé un peu plus

Salut tous !

Déjà désolé Stabylo je t'ai pas encore rencontacté depuis longtemps, honté sur moi...

Bravo pour le bug VIDEL, j'étais sûr que tu y arriverais une fois hors d'une party !

Sinon j'ai quand même regardé un peu STeADIER : avancé le désassemblage, trouvé encore 2 ou 3 bugs potentiels (à se demander comment ça réussissait à marcher), re-réflechi un peu à tout ça, potassé le 68040 User's Manual, chapitre PMMU, verset format des tables : pour le 040/060 ça pourrait être jouable pour du code non-STe n'accédant pas trop souvent aux registres vidéo (l'écrasante majorité des jeux ST quand même !).
En plus sur 030 et 040/060 on devrait pouvoir faire un mode d'émulation "léger" qui ne fasse que gérer les images disques sans pousser l'émulation ST(e) plus loin, et qui puisse être compatible avec la Fast-RAM (voire le TT et autres machines avec cartes accélératrices 030) pour plus de confort...
Si jamais je fais marcher ce truc sur 040/060, alors quelque pourra peut être un jour s'amuser à gérer les Hadès/Milan/Medusa voire ARanyM !

Plus de détails par courriel demain soir ou ce WE au pire !

Merci pour les infos, oui j'ai des suggestions du moins j'y reflechis. On verra plus tard.

Hello,

Les sources du compiler et du linker sont-ellles disponibles ?
Si oui, je peux les avoir ?

Stabylo> Incroyable, tu connais Alex de Brainstorm ! Ca me rappelle tant de souvenirs ! Ah que c'était bien ce bon vieux temps !
Passes-lui le bonjour et rappelles lui qu'il m'avait bien mourrir de rire avec sa méthode pour ne pas faire son service militaire

Et bon courage pour tout tes projets !

Quelques news vite fait :

- J'ai ajouté le support du bug Videl du Falcon quand on passe en résolution 2 couleurs
- J'ai trouvé que la routine wait_vbl était buggée (une inversion des labels des deux boucles imbriquées), mais il n'est pas possible de la corriger directement sans impacter le reste du code
- J'ai donc ajouté une nouvelle fonction wait_vbl2 débuggée pour mes besoins
- Le patch correspondant a été mis sur SourceForge
- La modification a été intégrée au CVS sur adebug.brainstorm.fr

Il me reste plus qu'à recontacter Alex pour lui dire tout ça et voir comment on peut faire pour ouvrir le CVS en anonymous

stabylo :
Il me reste plus qu'à recontacter Alex pour lui dire tout ça et voir comment on peut faire pour ouvrir le CVS en anonymous

super
en passant, n'oublie pas de lui parler de ce que tu sais

T'inquiète, j'ai pas oublié

Yo, toujours pas d'acces anonyme? Bon finalement, le code est pas libre... Tant pis.

Argh, oui y'a pas nouveau c'est vrai ; j'ai fait trop de SuperBurnout en Septembre/Octobre

stabylo (./74) :
Argh, oui y'a pas nouveau c'est vrai ; j'ai fait trop de SuperBurnout en Septembre/Octobre

En gros, on n'est pas prêts de jouer à des jeux ST sur Falcon 030/060 avec STEadier

j'ai fait trop de SuperBurnout en Septembre/Octobre

stabylo tu es en mon pouvoir , niark niark niark ...

et pour les sources de Madmac ?

Coucou tout le monde!

j'ai remis mon nez dans les sources d'Adebug et je me suis rendu compte que j'avais en fait 3 versions de sources!

* la première date de sept 1994 et c'est un fork du tronc commun dans lequel a été ajoutée l'évaluation d'expressions C en cours de débug avec [Ctrl_Alt_E]. (Je vous laisse imaginer la complexité que représente l'interprétation en direct d'une ligne de C. Ils étaient fous chez Brainstorm! ... tant mieux! ) Dans cette version, l'évaluation d'expressions C se compile avec Pure C et se linke avec Pure Link.

* la deuxième date du 16 déc 1994. C'est le tronc commun d'Adebug, tout en assembleur (donc sans l'évaluation des expressions C). Après l'avoir compilée hier, c'est EXACTEMENT (à l'octet près!) la dernière version diffusée sur le BBS Brazil (mi décembre 1994 donc), que j'ai récupéré je ne sais comment (version commerciale achetée en 1995 je crois), mais en tout cas c'est une version ultérieure à celle diffusée sur dhs.nu (faudra leur dire). Bref, cette version, c'est un peu "Adebug Reloaded"

* Et la troisième, du 19 déc 1994.. c'est le merge des deux branches! C'est donc LA version d'Adebug jamais diffusée. Cette version supporte même GCC! C'est une peu "Adebug New Generation"

A tous ceux à qui, j'ai transmis un ZIP de sources, soyez avertis que c'est la première de ces 3 versions que je vous ai fournie (j'm'a plantééé! ). Elle a donc encore quelques petits bugs qui ont été corrigés en novembre et décembre 1994.

Roooooooooooh !!! Mais dis donc !!!

Ca y est, Adebug Reloaded v2.13 est sorti!

Par manque de temps, j'ai fait une archive complète en téléchargement sur le site des Removers plutôt que de mettre ça sur la page SourceForge d'Adebug.
(Si quelqu'un peut m'aider à réaliser le design d'un nouveau site pour Adebug, je suis intéressé.)

J'ai passé beaucoup de temps et d'énergie à monter sur pied un package de qualité, mais j'ai peut-être laissé des bourdes à certains endroits.
Je suis donc très intéressé par votre feedback!

Merci à tous pour le soutien sur vous apportez à Adebug!

Ca vaudrait bien une news sur DHS

Merci pour la release en tout les cas.

frost (./80) :
Ca vaudrait bien une news sur DHS

Si j'm'a pas trompé, c'est déjà fait.
Et sur atari-forum.com aussi.

Et aussi sur les news de STMag

Merci pour Adebug Reloaded !

Je déterre le sujet...

Je travaille depuis quelques temps sur une version 2.14 d'Adebug qui supporte le 68060. J'ai plutôt bien avancé mais je me heurtais à une bonne quantité de bugs durant mes tests ; je viens de me rendre compte seulement aujourd'hui que les problèmes que je rencontre sont dûs à Magic !!! En fait, sous TOS normal, le debugger se comporte à peu près bien.

Pour résumé les problèmes:
Bugs Adebug 060 sous MagiC!
- plante sur ILLEGAL, mais breakpoints OK
- Plante en quittant dès lors qu'un programme est chargé

Bugs sous TOS:
- Quitte OK
- Quitte le programme User suite à un illegal, mais rend la main

Est-ce que quelqu'un aurait une idée du problème avec MagiC ?

Et si quelqu'un est intéressé pour bosser sur le debugger avec moi, faites moi signe. Une aide ne serait pas de trop.

Coucou!

Ce qui change essentiellement sous MagiC, c'est la gestion de la mémoire.

Les memory descriptors (ou MD) sont intercalés entre les blocs de mémoire alloués, et complétés de longs mots magiques, qu'on appelle aussi des "canaris". On dit des "canaris" parce dans les mines d'autrefois, on envoyait ces petits oiseaux en "éclaireurs" (au casse-pipe en fait) pour détecter le risque de coup de grisou.

Chez MagiC, le canari est un donc long mot "magique", et dès que sa valeur n'est pas la bonne, MagiC sait que ça sent le roussi. Comme les MD de MagiC forment une liste chaînée, et dès qu'un canari est altéré, on sait que le noeud de la liste est corrompu... Et là, c'est le drame : MagiC crashe comme un m...de lors du mfree() .

Pour résumer, la différence essentielle, c'est la fragilité aux "débordements de buffer". Quand tu rends à MagiC la mémoire que tu lui as allouée, si tu as débordé d'un tout petit peu d'un seul de tes blocs alloués (et c'est très vite arrivé!!), sous TOS ça se verra pas, mais sous MagiC ça va être le gros drame.

Evidemment, cette fragilité n'est pas un hasard. C'est le revers de la médaille de la rapidité de MagiC. Car grâce à ce système, les opérations d'allocation/libération de mémoire sont d'une vitesse foudroyante!

a+

PS : Prochaîne étape, documenter ça sur WikiPendium...

Wow, on apprend tous les jours. Merci Stabylo pour ces informations

Sinon, un truc tout bête : MagiC a horreur des malloc avec des tailles impaires. Il te vire sec si c'est pas pair. En général, ça va bien parce que les structures sont composées de int et long et pointeurs, mais s'il y a alloc mémoire d'un fichier ayant une taille impaire, ça va bomber.

Pour ça qu'on voit souvent des ajustements de la taille au prochain multiple de 2 ou 4 : genre malloc(((taille + 4) >> 2) << 2)


Sinon, je trouve assez saine cette protection de débordement mémoire. Un programme n'a pas à faire caca en dehors de son domaine.

Merci pour tes explications. Et MagiC fournit-il un moyen de débugger ça ? Parce que c'est pas forcément simple de débugger le débuggeur

Rajah: merci à toi aussi

Je vais tâcher de reprendre le patch 060 pour Adebug un de ces 4.

Rajah (./85) :
Wow, on apprend tous les jours. Merci Stabylo pour ces informations

De rien

Rajah (./85) :
Sinon, un truc tout bête : MagiC a horreur des malloc avec des tailles impaires. Il te vire sec si c'est pas pair. En général, ça va bien parce que les structures sont composées de int et long et pointeurs, mais s'il y a alloc mémoire d'un fichier ayant une taille impaire, ça va bomber.

Ca peut venir du fait qu'il place un canari à la fin du bloc, et que c'est un long mot. Alors sur 68k, boum !

Rajah (./85) :
Pour ça qu'on voit souvent des ajustements de la taille au prochain multiple de 2 ou 4 : genre malloc(((taille + 4) >> 2) << 2)

toutafé. on peut aussi considérer l'écrire comme ça : malloc((taille + 3) & -4)

Rajah (./85) :
Sinon, je trouve assez saine cette protection de débordement mémoire. Un programme n'a pas à faire caca en dehors de son domaine.

Certes... Mais il manque sans doute un coup de pouce pour déboguer les applis en développement.

frost (./86) :
Et MagiC fournit-il un moyen de débugger ça ?

Pas que je sache . Le plus gros souci, c'est que ça se gaufre à la libération du bloc, c'est-à-dire à un moment où tu ne sais plus du tout à quoi il correspondait, ce fichu bloc duquel tu as débordé.

Il faut alors se montrer créatif. Dans Animator, ce que j'ai fait, c'est un système maison similaire, mais qui cette fois me permet de savoir exactement où dans le code j'ai alloué le bloc de mémoire qui pose souci.

Ca repose sur les macros removers Malloc/Mfree (fichier macros.s/gemdos.s, lignes 506 à 588) pour assemble. En activant un EQU (__DEBUG_MALLOC_CANARIES), la macro rajoute des canaris et aussi l'adresse du code depuis laquelle la macro a été appelée. Ca donne ainsi une idée d'où vient le bloc.

frost (./86) :
Je vais tâcher de reprendre le patch 060 pour Adebug un de ces 4.

Ouille, si la CT a fait "pshit!", c'est sans doute compromis là, non ?

Trop fort.
Incidemment, je viens de retrouver la trace d'un test de CRAFT dans un très vieux ST Mag. (c'est marrant le niveau de l'article : ces outils étaient rarement connus à l'époque)

CRAFT comportait un sh (bourne shell) complet (avec les pipes!), un make, et un éditeur de texte nommé 'STedi'. Ces outils étaient utilisés par Brainstorm pour builder Adebug. L'éditeur STedi gère un système de repliage de code (code folding) et je viens de comprendre que c'est pour ça qu'on retrouve des #[ à tout bout de champ dans le code d'Adebug !! Ca indique en fait à STedi quelles sont les parties "repliables" !!!

La question est : quelqu'un sait-il où je pourrait trouver les binaires de ces outils de développement ??

stabylo (./88) :
c'est marrant le niveau de l'article : ces outils étaient rarement connus à l'époque

J'ai toujours eu l'impression qu'à cete période, un certain nombre de pigistes de ST Mag devaient être des étudiants (ou profs ?) et que du coup, ça se sentait dans leurs articles, avec des sujets un peu pointus (outils, algo, matheux las, ...) comme j'ai pu le faire en fac quelques années après, ou une ouverture assez marquée vers les stations Unix et leur actualité. D'ailleurs, il y a même eu quelques numéros avec un cahier Stations Unix. Alors certes, ils pouvaient considérer que c'était l'avenir, que Motorola équipait un certain nombre de ces stations et que même Atari tutoyait le monde Unix avec le futur TT Unix, mais pour y avoir accès à l'époque, il fallait généralement trainer ces guêtres dans les facs ou autres grandes écoles.

incidemment j'ai lu ce topic

il est marrant ce test, en effet
c'est sur qu'en le lisant maintenant que nous sommes éduqués, ça fait bizarre

bon, en gros craft = bash et stedi = vi (voire ed, mais je ne m'y connais pas assez en ed/vi)

et en effet, ça serait chouette de mettre la main sur ces binaires