IBM POWER9

Palaiseau, le mercredi 9 décembre 2020

Les résultats de reconstruction d'archives continuent de tomber. Cette fois ci, une série de bugs a été ouverte auprès de paquets affectés par des régressions sur architecture ppc64el, l'une des architectures du grand bleu inventeur du texte TOUT EN MAJUSCULES. Ah tu nous manques, FORTRAN IV !

La liste des bugs ouvert auprès de paquets gérés par l'équipe Debian Med est : #976906, #976908, #976925, et #976929. Je me suis permis de jeter un œil au paquet spaln, affecté par #976908. La partie du code en erreur à la compilation contient une structure comportant notamment deux variables de type char. Ces variables sont utilisées comme des nombres entiers négatifs ; c'est dangereux !

Le type char est un type dédié au stockage des caractères ASCII, et fait un octet de large, indépendamment de l'architecture de processeur. Par contre, il n'est pas précisé si ce type doit se comporter comme un entier signé ou non signé, et pour cause, les caractères d'un texte n'ont pas de notion de signe mathématique en temps normal. Le comportement dépend donc de différent paramètres, dont l'architecture du processeur cible.

Il existe plusieurs solutions pour remédier à ce genre de problème :

• forcer le signe du type de données dans le code, par exemple :

  signed   char variable_signee;  /* entiers relatifs de -128 à 127 */
  unsigned char variable_non_signee; /* entiers positifs de 0 à 255 */
  

• forcer globalement le signe du type de donnée en le forçant au niveau du compilateur ; avec GCC, ce sont les fanions -fsigned-char et -funsigned-char.

En général, l'option facile pour résoudre les problèmes de portabilité est d'ajouter -fsigned-char aux options de compilation. Les caractères sont signés par défaut en amd64, et la plupart des projets libres ciblent cette architecture de processeur, étant donné que ce sont les CPU les plus répandus de nos jours. Il est intéressant de noter que l'architecture arm64 travaille avec des entiers non signés. Évidemment, comme c'était facile à résoudre, quelqu'un d'autre a eu le temps de corriger le paquet pendant que prenais mes notes ici.  :)

Histoire de tout de même avoir un petit coup d'endorphine, j'ai téléversé la mise à jour 0.8.4 de seqmagick dans l'archive, tout en rendant la suite de test un peu plus verbeuse ; ce n'était pas entièrement nécessaire, mais bon, j'étais tombé sur un idiome en Shell qui me paraissait douteux, et je voulais le corriger.

J'ai également jeté un œil au bug #976876 afin d'intégrer une rustine de Helmut Grohne, afin de résoudre un problème empêchant la compilation croisée du paquet e-mem. Debian fournit de l'excellent outillage pour déclencher divers types de compilation, il est triste que cet effort soit gâché par un mauvais usage des variables d'environnement affectant le compilateur. Mais bon, de fait, les compilateurs sont des outils compliqués, et se louper avec n'a rien de surprenant ; je pense que j'ai encore beaucoup à apprendre rien que sur leur utilisation. C'est très dommage que la licence utilisée par le projet Gnu, la GFDL, afin de documenter son compilateur GCC, ne soit pas libre, du moins pas aux yeux des licences considérées comme libres par le projet Debian. Avec un peu de chance, ce devrait être le bug fermé du jour.

Enfin, j'ai intégré une rustine de Vagrant Cascadian, fournie avec le rapport de bug #972752, qui affecte seqan2. Le temps de compilation est assez long, donc les tests de reproductibilité sont au moins deux fois plus longs, souvent beaucoup plus. Je ne pense pas que j'aurais le temps de fermer ce bug aujourd'hui : les tests ont tourné pendant la majeure partie de l'après-midi et de la soirée, et consomment à l'instant t 26 Gio de mémoire juste pour système de fichier temporaire de l'environnement de travail de sbuild.

À noter, cette entrée n'est pas liée à la récente nouvelle comme quoi la distribution CentOS serait recyclée en laboratoire pour l'intégration des mises à jour Red Hat par IBM. Je pourrais deviser sur le tort que cela pourrait produire sur l'ensemble des utilisateurs de logiciels libres, et pas seulement de CentOS, mais il reste plein de bugs à corriger dans Debian, je n'ai pas le temps de me lamenter là dessus.

Enfin, le mot de la fin, j'ai appris que les problèmes de boutisme sont apparus lors du câblage des CPU, et du réseau. Le gros boutisme est en quelque sorte l'ordre naturel (sic) dans lequel on se représente une donnée binaire, par exemple un entier, avec les bits de poids fort en premier, et les bits de poids faible à la fin ; c'est l'ordre utilisé dans les transmissions réseau. Pourquoi certains CPU, notamment les Intel, sont petits boutistes ? Les bits de poids faible arrivent en premier, donc les calculs avec retenue sont plus performants.

	Name	Last modified	Size
	Parent Directory		-