Exportation nostub dans MakePrgm incorrecte - Page 1

MakePrgm dans PreOs 1.0.7 ne crée pas correctement la table de relogements _nostub:

		// Output code
		for (int i=0;i<codeSize;i++)
			WriteByte(code[i]);
		// Code relocation table
		for (int i=0;i<reloc[0].count;i++)
		{
			WriteWord(ReadDWord(reloc[0].ofs[i]));
			WriteWord(reloc[0].ofs[i]);
		}
		WriteWord(0); // Termination marker for TI's relocation method

Le WriteWord(0); devrait être entre le code et la table.

(J'ai remarqué ça parce que je voulais montrer à quel point le code était moins lisible que celui de ld-tigcc. Mais celui de obj2ti était pire. )

Kevin Kofler (./1) :
(J'ai remarqué ça parce que je voulais montrer à quel point le code était moins lisible que celui de ld-tigcc.

T'as de ces objectifs dans la vie, toi

Bah, compare:

obj2ti:

		for (; n--; R32++) {
			bw2 (o16--, (unsigned short)*R32);
			bw2 (o16--, (unsigned short)br4 (&dat[*R32]));
		}	*o16 = 0;

Totalement illisible et le terme "commentaire" paraît inconnu.

MakePrgm:

                // Code relocation table 
                for (int i=0;i<reloc[0].count;i++) 
                { 
                        WriteWord(ReadDWord(reloc[0].ofs[i])); 
                        WriteWord(reloc[0].ofs[i]); 
                } 
                WriteWord(0); // Termination marker for TI's relocation method

Moyennement lisible et commenté, bogué.

ld-tigcc:
http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/tigcc/ld-tigcc/export/exp_tios.c?revision=1.1&view=markup#l_108
Noms de variables parlants, code bien commenté et surtout correct.

C'est le concept d'aller regarder le code des autres juste pour le plaisir de critiquer que j'ai du mal à comprendre

Kevin Kofler (./3) :
for (; n--; R32++) {
bw2 (o16--, (unsigned short)*R32);
bw2 (o16--, (unsigned short)br4 (&dat[*R32]));
} *o16 = 0;

Peu lisible.
Nom de variable non explicite.
Nom de fonction non explicite.
Et, horreur, l'appel d'une fonction imbriqué dans un appel de fonction ?
Et d'une façon générale, aucun commentaire.
Bien sûr je ne dirai rien sur l'horrible position de l'accolade ouvrante

115 // Write out the relocation table.
116 for (Reloc = GetLast (MainSection->Relocs); Reloc; Reloc = GetPrev (Reloc))

aucune explication sur la raison de pourquoi on commence par la fin; nom de variables en majuscules, commentaires C++ dans du C

enfin bref

squalyl (./6) :
commentaires C++ dans du C

Ex-tension

Ximoon (./5) :

Kevin Kofler (./3) :
for (; n--; R32++) {
bw2 (o16--, (unsigned short)*R32);
bw2 (o16--, (unsigned short)br4 (&dat[*R32]));
} *o16 = 0;

Peu lisible.
Nom de variable non explicite.
Nom de fonction non explicite.
Et, horreur, l'appel d'une fonction imbriqué dans un appel de fonction ?
Et d'une façon générale, aucun commentaire.
Bien sûr je ne dirai rien sur l'horrible position de l'accolade ouvrante

C'est obj2ti ça, j'ai bien écrit noir sur blanc que ce code est illisible (et bien pire que MakePrgm, je suis bien d'accord). Demande-toi pourquoi TIGCC n'utilise plus obj2ti depuis la version 0.95 Beta 1…

squalyl (./6) :
aucune explication sur la raison de pourquoi on commence par la fin

AMS lit la table depuis la fin, donc ça fait qu'elle est lue dans l'ordre, ça me semble plutôt évident, mais je veux bien rajouter un commentaire si tu veux. (Comme ça Lionel va encore se plaindre des commits qui ne changent rien. )

nom de variables en majuscules

C'est la convention de codage de ld-tigcc, je ne vois pas le problème.

commentaires C++ dans du C

C'est conforme au standard C99. Et puis ld-tigcc (et TIGCC en général) n'est compilable qu'avec GCC (à commencer par GCC lui-même, on ne peut compiler avec un autre compilateur qu'avec un bootstrap complet et on ne peut pas faire un bootstrap complet sur un cross-compilateur). Il y a aussi des fonctions imbriquées.

ok pour ams qui lit la table a l'envers. Fais pas un commit pour ça, attends donc la prochaine fournée de contributions externes.

Et quid du bogue reporté dans le post d'origine?

poste un patch voyons, PpHd n'a pas que ça à faire

Déplacer une ligne 6 lignes vers le haut devrait être à sa portée.

je note pour les futurs bug reports tigcc qui arriveront sur le forum.

J'ai voté pour la 1^ère et la 3^ème solution, les 2 sont acceptables (MakePrgm est totalement obsolète: pas de gestion du COFF, pas de linking entre plusieurs fichiers etc.). En revanche, ne rien faire est certainement la mauvaise réponse et "Supprimer la possibilité de générer du nostub", certes, visiblement personne ne l'a utilisée, du moins avec un programme qui contient des relogements, mais ça rendrait MakePrgm encore plus obsolète et inutile et ce serait plus de travail que de corriger le problème.

Je crois que le résultat du vote est sans appel : Fichier joint : (vote.png)

faisons une commission, petite ou grosse, pour déterminer l'avenir de ce programme.

4 avis pour ne pas faire de nostub !!! c'est l'expression de la volonté générale

Je crois que le résultat du vote est sans appel : Fichier joint : (vote.png)

Lol le double post à 9 h d’intervalle !

Je suis super content que Kevin ait trouvé ce bug hyper emmerdant. Ca va obliger PpHd à faire une release avec un kernel.h qui fonctionne à tous les coups (encore perdu 1 heure avec les define/undef (_(_))main, à recherche sur le forum où on en avait parlé )

Trouve moi plutôt un bug dans preos et je fais une release

Tu veux que je reprenne les torture test ? T'as une piste par où chercher ? je verrais plutôt RAM_THROW/SYSCALL ajouté, ou une api plus complète pour les pack-archive

PpHd (./23) :
Trouve moi plutôt un bug dans preos et je fais une release

La commande "takeover world" ne fonctionne pas sous PreOs.
Allez au boulot !

Bug report: la somme MD5 de PreOs ne correspond pas aux premières décimales de pi.

Tu t’ennuies ?

Kevin Kofler (./26) :
Bug report: la somme MD5 de PreOs ne correspond pas aux premières décimales de pi.

l'exécutable on calc ou le fichier .89z ?

Méditation de ce matin dans les gaz du réveil : dommage que la toolchain releasée avec PreOS sdk dépende tant de la version binaire....
En clair, il faudrait une version dev vraiment indépendante de la version binaire, pour éviter de devoir trouver un bug dans le kernel quand on veut un maj des outils.
Surtout que vu la gueule des derniers bugs, il doit vraiment plus y en avoir légion... j'ai même plus aucune idée de connerie à essayer...

Nan, mais j'empêche personne de faire une release des outils à ma place ! Surtout pour corriger ce bug ignoble qui ne touche que les programmes _nostub, qui comme tout le monde le sait, utilisent tous makeprgm !!