Je suis bien d'accord avec toi, et je trouve la façon de faire d'A68k assez désagréable.
Je trouve qu'on devrait séparer les directives d'assemblage (xdef _ti89, etc.) des labels exportés.
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
Mais peut-être qu'il y a une raison qui justifie ce fonctionnement d'a68k ?
Peut-être tout simplement que ça facilite le travaille d'a68k : au final il traite de la même manière les labels exportés et les directives d'assemblage, il n'y a donc pas de code spécifique à écrire pour les directives d'assemblage. Ensuite, c'est le linker qui gère : il regarde quels sont les symboles exportés et agit en fonction.
Bon, n'empêche que j'aurais trouvé plus cohérent de mettre un autre mot clé pour les directives d'assemblage...
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
le truc c'est qu'un label définit un "symbole" associé à une adresse.
xdef marque ce symbole comme exporté.
Il ne peut rien faire si le symbole associé n'existe pas!
et a priori il n'y a aucune raison d'avoir différents types de symbole, un symbole est la représentation d'une adresse quelconque, et t'es pas obligé de t'intéresser à la valeur de cette adresse.
sinon c'est quoi une directive d'assemblage? xdef? xdef dit juste "copie ce symbole dans la table d'exportation" c'est tout.
un label EST un symbole.
ensuite effectivement le linker peut avoir un comportement controlé par la présence de symboles particuliers. mais c'est la présence du symbole qui comte plus que sa valeur associée.
Une directive d'assemblage c'est justement un symbole qui contrôle le comportement du linker.
Par exemple le symbole _ti89 qui demande de produire un fichier .89z.
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
oki.
mais ce sont des symboles normaux, qui commandent le linker au lieu d'utiliser des options de ligne de commande.
(tout ceci d'après moi, je sais pas si c'est 100% exact vérité vraie toussa)
ben non, ils sont deux symboles identiques en structure, mais n'ont pas le même rôle derrière.
de mon sens, dans l' *assembleur* ils doivent être traités de la même manière, et le *linker* fait cekifo quand il rencontre un symbole spécial.
en gros, l'assembleur génère des trucs à l'aveugle, mais c'est le linker qui fait le boulot.
l'assembleur se cantonne à transformer du texte en binaire et à stocker des associations (symbole, adresse)
ld-tigcc ne vérifie pas non plus l'unicité des exports, tu peux exporter le label foo dans chaque fichier .asm et ld-tigcc ne gueulera pas. Ce qui se passe, c'est que les références à l'intérieur du fichier seront résolues par l'assembleur vers le label dans le même fichier, et les références depuis les fichiers qui ne définissent pas foo seront résolus par ld-tigcc en n'importe quel foo.
Et ça va à l'encontre du standard C, d'ailleurs, mais c'est nécessaire, sinon les global imports ne fonctionneraient pas, notamment. (Un global import importe tous les fichiers des .a linkés qui exportent un certain symbole, c'est utilisé pour importer les bonnes sections de démarrage.)
D'ailleurs, un des patches les plus "fous" du GDB de TiEmu, c'est un patch à bfd/linker.c pour faire comme si le flag allow_multiple_definition était défini pour toutes les sections (parce que c'est comme ça que fonctionne ld-tigcc).
ça peut facilement générer un avertissement de symbole dupliqué, non?
