bug avec tigcc 0.95 - Page 4

Ca fait quoi exactement, l'option "ut ranges" ? Il me semble pas qu'on puisse faire des lea.s / lea.w (en tout cas je ne l'ai jamais utilisé)

encore une question : comment on fait pour faire des header files ASM sur 0.95 ? Sur la 0.94, l y avait le choix entre ASM et C, plus maintenant Du coup, ça fait tout plein d'erreurs

Pollux :
Encore un bug de TIGCC 0.95?

<SARCASM>Oh, que c'est grave, un bogue dans un assembleur dépassé avec un mode d'adressage que presque personne n'utilise. </SARCASM>
Et le bogue sera corrigé aussitôt que possible, soit dans le cadre de la prochaîne bêta, soit par une mise à jour séparée de A68k.

"dépassé"?
Et (pc,dn.w) n'est pas si rare que ça (jump tables...)

Flanker
: Ca fait quoi exactement, l'option "ut ranges" ? Il me semble pas qu'on puisse faire des lea.s / lea.w (en tout cas je ne l'ai jamais utilisé)

Sans cette option, si tu as des trucs du style:
move.l #stuff,d0
le linker en fait du:
move.l stuff(PC),d0
nop
pour économiser un relogement sans changer la taille.
Avec l'option "cut ranges", le nop n'est pas créé, et le code qui suit est décalé vers l'avant. Cela implique qu'il faut changer tous les offsets. L'assembleur doit donc communiquer au linker tout endroit où il y a des offsets, et c'est ce que fait le mode all-relocs. Mais comme c'est expérimental, et comme son implémentation dans A68k est un hack assez grossier (ce n'était pas du tout prévu par A68k - GNU as contenait déjà une bonne partie du support pour le mode all-relocs, il fallait juste rajouter l'implémentation m68k-COFF), il peut y avoir des bogues. Surtout avec des trucs peu testés comme x(PC,Dn).

Flanker :
encore une question : comment on fait pour faire des header files ASM sur 0.95 ? Sur la 0.94, l y avait le choix entre ASM et C, plus maintenant Du coup, ça fait tout plein d'erreurs

Oups... Il faut en parler à Sebastian, mais pour le moment, la solution est:
* changer les commentaires au début de // en ;
* fermer le projet (ou l'IDE)
* réouvrir le projet (ou l'IDE)

mais dans ce programme je ne pouvais pas utiliser de relogements, donc il n'y en a pas (sinon ça se serait vu tout de suite) => je ne sais pas si désactiver l'option va changer qqc ...

Pollux
: "dépassé"?

Ben oui, c'est un assembleur Amiga d'il y a 16 ans (dont 10 pendant lesquels il n'a pas été touché, alors que GCC, GNU as et semblables ont évolué pendant tout ce temps!), maintenu seulement pour la compatibilité antérieure. Il n'y aura probablement plus de nouvelles fonctionnalités de ma part (j'ai déjà mis tout ce que j'avais à mettre), et il y a peu de chances que quelqu'un d'autre y rajoute encore quoi que ce soit.
L'assembleur moderne et mis à jour est l'assembleur GNU. Il sait déjà faire pratiquement tout ce que sait faire A68k (par exemple, .incbin est là depuis la version 2.12 au moins) et des trucs en plus.

Et (pc,dn.w) n'est pas si rare que ça (jump tables...)

Bon, d'accord. Je n'ai jamais utilisé les "jump tables" parce que c'est presque toujours une perte en taille.

Flanker
: mais dans ce programme je ne pouvais pas utiliser de relogements, donc il n'y en a pas (sinon ça se serait vu tout de suite) => je ne sais pas si désactiver l'option va changer qqc ...

En mode all-relocs, ton instruction te donne un relogement PC-relatif, qui sera résolu par le linker après la phase d'optimisation. Et comme de toute façon il n'y a pas de relogements à optimiser, désactiver l'option ne devrait même pas porter de désavantage dans ton cas (sauf peut-être si le linker pourrait optimiser des bxx.w en bxx.s).

* bogue confirmé en mode all-relocs
* absence du bogue confirmée en mode non-all-relocs
Donc désactiver "Cut Ranges" résoudra ton problème en attendant la correction du bogue.

Ben oui, c'est un assembleur Amiga d'il y a 16 ans (dont 10 pendant lesquels il n'a pas été touché, alors que GCC, GNU as et semblables ont évolué pendant tout ce temps!), maintenu seulement pour la compatibilité antérieure. Il n'y aura probablement plus de nouvelles fonctionnalités de ma part (j'ai déjà mis tout ce que j'avais à mettre), et il y a peu de chances que quelqu'un d'autre y rajoute encore quoi que ce soit.

Oui, c'est normal, tout simplement parce qu'un assembleur peut être considéré comme "terminé" (alors qu'un compilo, non). Ce n'est donc absolument pas un argument valable.

Et le bogue est bien dans l'assembleur et pas dans le linker (ou alors dans le code d'importation dans le linker, mais ça m'étonnerait), parce que ce que reçoit le linker est faux dès le départ:

*** DUMP 0 ***
Section
  File: test7.o
  All Relocs Included
  Code
   _ti92plus: (local)
   _ti89: (local)
   _nostub: (local)
   __ld_all_relocs: (local)
   test7.o .text: (local)
     0x000000: 41 FB 70
     0x000003: <1B: test7.o .text+15 (rel) - 1>
     0x000004: 30 18 32 10 4C DF 01 80 4E 75
   coord_list2icone_data: (local)
     0x00000E: 4E 71

(Le +14 est coupé en +15-1 pour gérer mieux les sauts courts; c'est un détail qui n'a aucune importance ici. Ce qui compte est que la source est 3 et le target est 14, donc l'offset calculé est 11, alors que l'offset attendu est 12. L'assembleur devrait donc émettre un offset de +15 (qui sera coupé en +16-1 plutôt que +14+1, mais c'est inévitable, et ça ne devrait pas créer des problèmes, parce que le linker ne va de toute façon pas optimiser les données à l'adresse du label).) Je vais corriger ça.

Et c'est quand qu'on peut assemble des sources > 32768 erreurs sans avoir des random errors ?

32768 erreurs???
Je suppose que tu veux dire 32768 lignes. Ben, ce n'est pas prévu. La limitation est documentée et l'a toujours été. Il faut compiler en plusieurs morceaux et utiliser un vrai linker, ou alors utiliser l'assembleur GNU.

... ou l'assembleur GTC

Et il fait comment pour faire un TIB avec ton assembleur, vu que tu n'utilises pas les fichiers objet?

Il va effectivement y avoir un problème pour les progs de + de 64k. Mais si sa ROM avait pris moins de 64k, il n'y aurait eu aucun pb...

Le bogue du message de départ est corrigé par:

$ diff -u 271f3o/Operands.c Operands.c
--- 271f3o/Operands.c   Sun Oct  5 01:21:26 2003
+++ Operands.c  Mon Dec  1 03:18:22 2003
@@ -380,6 +380,11 @@
        if ((op->Hunk >= 0) && (op->Hunk != ABSHUNK))
            Error (op->Loc, RelErr);    /*  Relocatable displacement */
 #endif
+
+/* Bugfix by Kevin Kofler (v.2.71.F3p): Handle the non-ABSHUNK-case correctly.*/
+       if ((op->Mode == PCDisX) && (op->Hunk >= 0) && (op->Hunk != ABSHUNK))
+         op->Value++;
+
        return;
     }

Je vais mettre à jour A68k sur mon site et envoyer la mise à jour à Sebastian quand j'aurai le temps. J'ai envoyé un nouvel A68k.exe en binaire seul à Flanker en attendant. (L'université m'occupe beaucoup en ce moment.)

Et ce bogue était là parce que ce type de relogements n'était pas du tout géré dans A68k. Il y avait ça avant à cet endroit (c'est le #if 0 dont on voit la fin dans le patch):

	if ((op->Hunk >= 0) && (op->Hunk != ABSHUNK))
	    Error (op->Loc, RelErr);	/*  Relocatable displacement */

Entre 2 sections différentes, ça ne marchait pas même sans le mode all-relocs.

Encore un bug dans TIGCC ?
pour tester mon désassembleur, j'ai créé un petit programme dont voici le code :
xdef _ti92plus
xdef _main
xdef _exit
xdef test_ker@0000
_ti92plus:
_main:
dbra d0,_exit
rts
_exit:
jsr graphlib@0001
dbra d0,test_ker@0000
move.l graphlib@0017+44,d4
move.l _ROM_CALL_012,d0
move.w d4,_RAM_CALL_011+50
test_ker@0000:
rts

mon désassembleur renvoie le fichier suivant :

xdef _ti92plus
xdef _v200
xdef _main
xdef _exit
xdef _lib@0002;<- l'erreur est là
xdef _lib@0001;et là : les fonctions n'existent pas
xdef _lib@0000
_ti92plus:
_v200:
_main:
dbra d0,_L_82
rts
_exit:
_L_82:
jsr graphlib@0001
dbra d0,_L_9E
move.l graphlib@0017+44,d4
move.l _ROM_CALL_0012,d0
move.w d4,_RAM_CALL_0011+50
_L_9E:
_lib@0000:
rts

après vérification, le nombre de fonctions exportées dans le fichier est bien de 3. C'est normal ?
si a3 pointe vers le début du fichier, j'obtiens le nombre de fonctions exportées par
moveq #0,d6
move.w $16(a3),d6;offset vers la table d'exportation
beq \skip
move.w 0(a3,d6.l),d6;nombre de fonctions exportées
subq.w #1,d6

En plus, sur hexlib et linelib, j'obtiens le bon nombre de fonctions exportées

Au passage, mon désassembleur a l'air de marcher plutôt bien, vu que j'ai pu réassembler txtrider sans retoucher le code ; il y a juste le stub à supprimer à la main. Au passage, mon txtrider pèse 9569o, alors que celui d'origine fait 10327o

On voit que celui d'origine a été assemblé avec une version boguée de A68k qui n'optimisait pas correctement les branchements (2.71.F2).

Flanker
: après vérification, le nombre de fonctions exportées dans le fichier est bien de 3. C'est normal ?

Non, mais je ne peux pas reproduire ça ici. J'ai une seule fonction exportée, moi.

bon je vais revoir ça alors. Me serais-je trompé ?

dans la serie bugs pourquoi TIGCC me met un warning du style(je me souvient plus du nom exact) "addind program startup code into library" sur certaines de mes libs.

Vérifie que tu n'utilises pas des trucs que tu ne devrais pas utiliser dans une librairie, qui nécessitent du code de démarrage.
C'est peut-être aussi le rajout automatique de SET_FILE_IN_USE_BIT quand on appelle une fonction AMS qui en a besoin qui fait ça.

Vérifie que tu n'utilises pas des trucs que tu ne devrais pas utiliser dans une librairie, qui nécessitent du code de démarrage. C'est peut-être aussi le rajout automatique de SET_FILE_IN_USE_BIT quand on appelle une fonction AMS qui en a besoin qui fait ça.

Ca j'avais compris mais qu'est ce qui pourrait nécessiter du code de démarrage?

SET_FILE_IN_USE_BIT par exemple.
Peut-être aussi d'autres trucs que tu as définis toi-même.

Flanker :
Encore un bug dans a68k ?
voilà mon problème :
le morceau de code suivant me donne un address error quand il est exécuté


lea coord_list2icone_data(pc,d7.w),a0
move.w (a0)+,d0
move.w (a0),d1
movem.l (a7)+,a0/d7
rts
coord_list2icone_data:


en débugguant, je vois qu'il donne quand il est assemblé :

lea $B(pc,d7.w),a0
move.w (a0)+,d0
move.w (a0),d1
movem.l (a7)+,a0/d7
rts
ça devrait pas donner lea $C(pc,d7.w),a0 ?

Une mise à jour de A68k corrigeant ce bogue (2.71.F3p) est disponible: A68k 2.71.F3p. Binaire Win32 inclus. Un binaire x86/Linux peut être mis à disposition sous demande, mais c'est facile à compiler soi-même (juste make, pas de trucs style configure).