Problème d'assemblage d'une lib dynamique - Page 1

yop,

J'ai ce code dans ma lib:

;==========================================================
;	GetCurrentArgPtr
;
;	Return a ptr to the current arg
;
;	input	a0	CMDLINE*
;	output	a0	Arg
;	destroy	d0/a0
;==========================================================
butillib@0009:
	move.w	ARGIT(a0),d0
	movea.l	ARGV(a0),a0
	movea.l	0(a0,d0.w),a0
	rts


;==========================================================
;	IsArgSwitch
;
;	Return 0 if the current arg is not a switch (ie if it doesn't begin with +/-)
;
;	input	a0	CMDLINE*
;	output	d0.b	0 if the arg is not a switch
;	destroy d0/a0
;==========================================================
butillib@0003:
	bsr	butillib@0009
	moveq.l	#'-',d0
	cmp.b	(a0),d0
	beq.s	\Switch
	cmpi.b	#'+',(a0)
	seq.b	d0
\Switch:
	rts

A68k m'assemble le "bsr butillib@0009" en "bsr butillib@0000". Pourtant, kernel::LibsPtr me renvoie un pointeur correct vers cette fonction, donc la table d'export est correcte. Le workaround est évident, mais j'aimerais comprendre pourquoi ça ne marche pas... Le problème est identique si j'écris "bsr butillib::GetCurrentArgPtr

C'est parce que tu essaies d'utiliser un libcall à l'intérieur de la lib elle-même, mets un label normal à la fonction et utilise ce label.

C'est bien sûr fait, mais :
- ça reste un bug
- ça marche comme attendu à d'autres endroits (saut pc-relatif à la bonne fonction), genre là :
Maintiens-tu encore A68k ? En clair, est-ce utile que je remplisse un bug report sur le tracker ?

À mon avis, ce n'est pas A68k ton problème, mais le linker. (Je pourrais t'en dire plus avec un testcase complet et compilable.)

Et ce n'est pas un bogue, ça ne marche que par hasard dans certains cas. Un libcall importe la lib, un libcall à l'intérieur de la même lib n'est pas valide.

Tu veux ma lib ? Elle compile.

Envoie-moi-la, mais je ne te promets pas que je vais corriger ton truc.

Pour ld-tigcc, un relogement vers un symbole de la forme libname@nnnn est toujours une importation, il ne va pas aller chercher le nom du binaire que tu es en train de linker pour vérifier que ce n'est pas le même nom. (D'ailleurs, quand tu exportes un label de la forme libname@nnnn, ld-tigcc ne va pas vérifier la partie libname non plus, tu peux mettre n'importe quoi et il en fera toujours une exportation.) Et évidemment un libcall ne peut pas être PC-relatif, donc forcément ça va foirer.

Kevin Kofler (./6) :
il ne va pas aller chercher le nom du binaire que tu es en train de linker pour vérifier que ce n'est pas le même nom

C'est juste ça qui manque pour que ça marche si je comprends bien.

Kevin Kofler (./6) :
Et évidemment un libcall ne peut pas être PC-relatif, donc forcément ça va foirer.

Ben je ne sais pas où est le bug, mais parfois ça marche.

Sinon ok, j'envoie tout de suite.

Kevin Kofler (./4) :
Un libcall importe la lib, un libcall à l'intérieur de la même lib n'est pas valide.

n'importe quoi !!!!

Kevin Kofler (./6) :
Pour ld-tigcc, un relogement vers un symbole de la forme libname@nnnn est toujours une importation, il ne va pas aller chercher le nom du binaire que tu es en train de linker pour vérifier que ce n'est pas le même nom. (D'ailleurs, quand tu exportes un label de la forme libname@nnnn, ld-tigcc ne va pas vérifier la partie libname non plus, tu peux mettre n'importe quoi et il en fera toujours une exportation.) Et évidemment un libcall ne peut pas être PC-relatif, donc forcément ça va foirer.

c'est un gros bug de ld-tigcc alors!

Ce n'est pas un bogue, ce comportement est parfaitement conforme à la documentation: http://tigcc.ticalc.org/doc/ld.html#symbols_lib_call.

Alors c'est le design qui est déconne ?

TIGCC n'est pas fait pour faire du kernel-based, ça n'est pas une nouveauté
Il est plus simple de dire que c'est un bug et refuser de corriger le problème

De toute façon, le fait que ça marche parfois comme il le faudrait montre que c'est bogué ^^

Je suis tombé sur une feature pas mal hier :
moveq.l #TEXT_TAG,d0
et dans le répertoire du projet :

$ grep TEXT_TAG *
$

Le TEXT_TAG était assemblé comme un $0

Folco (./12) :
De toute façon, le fait que ça marche parfois comme il le faudrait montre que c'est bogué ^^

Ça "marche" quand A68k crée un relogement interne au fichier au lieu d'un relogement par nom. Mais ceci n'est pas documenté.

Folco (./13) :
Je suis tombé sur une feature pas mal hier :
moveq.l #TEXT_TAG,d0
et dans le répertoire du projet :

$ grep TEXT_TAG *
$

Le TEXT_TAG était assemblé comme un $0

A68k accepte silencieusement du code incorrect, c'est nouveau?
Des sources existantes utilisent tout et n'importe quoi (on trouve par exemple du moveq.w ou moveq.b ), donc corriger ce genre de problèmes pourrait causer pas mal de cassage. Bref, si tu veux un assembleur qui reporte toutes tes erreurs, utilise GNU as.

Kevin Kofler (./15) :
Bref, si tu veux un assembleur qui reporte toutes tes erreurs, utilise GNU as.

Il m'a déjà planté parce qu'il accepte aussi du code invalide (et que A68k détecte ).

Kevin Kofler (./15) :
A68k accepte silencieusement du code incorrect, c'est nouveau?

Lol, j'ai une brochette d'exemples à disposition, et le coup du moveq est des moindres ^^

Kevin Kofler (./6) :
Pour ld-tigcc, un relogement vers un symbole de la forme libname@nnnn est toujours une importation, il ne va pas aller chercher le nom du binaire que tu es en train de linker pour vérifier que ce n'est pas le même nom. (D'ailleurs, quand tu exportes un label de la forme libname@nnnn, ld-tigcc ne va pas vérifier la partie libname non plus, tu peux mettre n'importe quoi et il en fera toujours une exportation.) Et évidemment un libcall ne peut pas être PC-relatif, donc forcément ça va foirer.

C'est là que le concept est mauvais :
- il ne filtre pas les exports bogués, tu ne t'en rends compte que par des bugs au run-time, alors qu'il sont détectables à la compilation
- il y a un abus de la directive xdef, qui sert à rendre un label visible globalement tout autant qu'à exporter une adresse dans un binaire (fonction ou variable). Un symbole "export" spécifique pour les dll et les libs statiques aurait évité ce genre de confusions. Mais ça, c'est plus de la faute de l'assembleur.
- les bcc/jsr/jmp lib@xyzt devraient être vérifiés, et assemblés en pc-relatif si "lib" correspond au nom du binaire en cours d'assemblage (et si les adressages sont pc-relatifs pour les jsr/jmp évidemment)

Bref, à mon sens, tout ça est du bricolage. Et ça m'emmerde de devoir suivre ces règles dans mon implémentation pour obtenir une compatibilité source, je trouve ça mal foutu...

Bah, tout le format kernel est du bricolage. ld-tigcc ne peut qu'implémenter ce qui est là, ça a été inventé bien avant! À la limite on pourrait résoudre le problème des libcalls qui n'en sont pas (libcalls internes à une seule et même lib, il doit y avoir moyen de les reconnaître et de faire ce que tu attends), mais les noms de symbole "magiques" devront forcément rester pour la compatibilité (comme tu l'as déjà remarqué toi-même).

Et au fait, la raison pour laquelle le comportement actuel est tel qu'il est est que dans la représentation de ld-tigcc, ces symboles "magiques" ne sont justement plus de symboles magiques, un libcall est représenté totalement différemment qu'un relogement "normal". Donc ce n'est pas évident de gérer ce cas particulier (mais certainement possible, juste casse-pieds).

GCC4TI rulez !