Docs - pmdata's blog

jeudi 11 décembre 2008

Incompatibilité entre le code FPU et non-FPU

Par Patrice Mandin le jeudi 11 décembre 2008, 20:52

En essayant de compiler une application qui utilise le FPU, je suis tombé sur un problème embêtant, car j'utilisais une librairie qui n'avait pas de version FPU, mais qui avait une fonction qui retournait une valeur flottante (float, ou double, peu importe).

L'ABI pour le code non-FPU, est de renvoyer la valeur de retour dans d0; Bien sûr, pour le code FPU, la valeur de retour se trouve dans le registre fp0.

Maintenant, si vous compilez votre application pour -m68020-60 (or -m68030 -m68881) et qu'elle est liée avec une bibliothèque qui a une fonction retournant un float ou un double, et qui n'a pas de version FPU (donc liée avec la version 68000 ou 68020 de ladite bibliothèque), votre application a de grandes chances de se comporter bizarrement. Tout cela car la bibliothèque retourne la valeur dans d0, et votre application l'attend dans fp0, et vous vous demandez pendant des heures où est le bug dans votre code (et il n'y en a pas :-)).

Pour faire court:

- application FPU + bibliothèque FPU = OK

- application FPU + bibliothèque non-FPU = OK seulement si aucune fonction de la bibliothèque ne retourne de valeur flottante. Pour celles-ci, grande chance de bug, dûe à la différence d'ABI (registre d0 pour la bibliothèque, registre fp0 pour l'application).

- application non-FPU + bibliothèque FPU = Même problème que au-dessus, dans le sens inverse. Mais cela en pratique n'arrive jamais, puisqu'une application qui est compilée pour m68000 ou m68020, dispose toujours d'une libraire dans cette version.

- application non-FPU + bibliothèque non-FPU = OK.

Que faire?

Ne pas mixer le code FPU et non FPU. Cela signifie qu'il faudrait interdire à gcc (et ou ld) d'utiliser les versions m68000 ou m68020 des bibliothèques quand on compile une application FPU. Le problème est de savoir si c'est possible, et faire ensuite les corrections nécessaires.

Problème dans l'utilisation des multilib avec gcc

Par Patrice Mandin le jeudi 11 décembre 2008, 20:34

J'ai fait une lib toute bête, avec une fonction void display(void) dedans, et j'essaie de linker mon prog avec differents parametres:

gcc monprog.c -t -lmalib : repertoires de base avec lib .
gcc monprog.c -t -m68020 -lmalib : repertoires de base avec libs m68020
gcc monprog.c -t -m68020-60 -lmalib : repertoires de base avec libs m68020-60

Donc pour l'instant, tout est ok, maintenant si je precise que ma lib se trouve dans un repertoire différent des autres libs, avec -L:

gcc monprog.c -t -Lmalib -lmalib : repertoires avec lib . et ajout de malib comme repertoire pour linker ma lib
gcc monprog.c -t -m68020 -Lmalib -lmalib : repertoires de base avec libs m68020 et ajout de malib comme repertoire pour linker ma lib
gcc monprog.c -t -m68020-60 -Lmalib -lmalib : repertoires de base avec libs m68020-60 et ajout de malib comme repertoire pour linker ma lib

Donc a priori, la aussi tout va bien, le probleme c'est quand le repertoire passé en parametre de -L est l'un des repertoires de base, genre /usr/lib ou /usr/local/lib et qui contient d'autres librairies:

En supposant que j'ai installé malib dans /usr/lib par exemple:

gcc monprog.c -t -L/usr/lib -lmalib : utilisation seulement de /usr/lib
gcc monprog.c -t -m68020 -L/usr/lib -lmalib : utilisation seulement de /usr/lib
gcc monprog.c -t -m68020-60 -L/usr/lib -lmalib : utilisation seulement de /usr/lib

Donc a priori -L desactive la generation des repertoires pour multilib, pour le repertoire concerné. Je suppose que gcc fait le menage pour supprimer les repertoires en double dans ceux qu'il va utiliser, le pb, c'est que dans ce cas, les rep pour le multilib ne sont plus utilisés.

Le fichier libgcc.a qui se trouve dans un repertoire interne de gcc n'est pas impacté, donc je pense que c'est ce qui arrive, et que la aussi le multilib serait désactivé si on ajoutait -L/repertoire/de/libgcca.

Je suppose que ca doit etre la meme chose pour gcc 4.3 et les binutils 2.18, je n'ai pas testé.

C'est un gros probleme, quand on utilise des libs dans un programme, dont les parametres de linkage sont renvoyés par un script malib-config, ou par pkg-config, comme par exemple SDL.

lundi 18 août 2008