Programmation système 01 – Mécanique de compilation et d'édition des liens

Ce document vise à décrire ce que signifie programmer au sens de la mécanique de la programmation en tant que tel. Nous y examinerons :

• Ce que signifient les termes compiler et éditer des liens
• Ce qui se passe quand un programme est chargé en mémoire puis exécuté
• Ce qu'est un langage d'assemblage
• Ce qu'est la pile d'exécution d'un thread; etc.

Mécanique de la compilation C++

Ce qu'on nomme compilation, par souci de simplicité, est souvent un abus de langage, du fait que nous tendons à y regrouper la combinaison de plusieurs actions connexes incluant la compilation à proprement dit.

Idée de projet

Résumé : un(e) informaticien(ne) développe un ou plusieurs algorithmes qu'il/ elle traduit à l'aide d'un langage de programmation donné. L'objectif du code ainsi produit est d'en faire un exécutable, soit un automatisme permettant de résoudre un problème ou une classe de problèmes, ou encore d'en faire une bibliothèque susceptible d'être utilisée par des programmes.

Dans nos exemples plus bas, nous présumerons un projet nommé UnProjet qui inclura les fichiers sources octets.cpp, bits.cpp et UnProjet.cpp, et qui aura pour but de générer l'exécutable UnProjet.exe.

On pourrait donc dire, à la limite, que le projet du projet UnProjet est la génération de l'exécutable UnProjet.exe.

Commençons par quelques définitions :

• Un projet est un regroupement de fichiers utilisés dans la génération d'un exécutable
• Un exécutable est un fichier pouvant être chargé en mémoire et exécuté

Puisque la programmation C++ a entre autres pour but de générer des exécutables, il est de mise d'y construire des projets. Au minimum, tous les fichiers sources utilisés (donc contenant du code dont le programme a besoin – il y a une nuance à apporter au sujet des bibliothèques à liens dynamiques, mais nous ne nous en occuperons pas pour le moment – devront y figurer.

Les fichiers essentiels à la génération d'un exécutable sont les suivants :

• Les fichiers sources, portant en C++ l'extension .cpp, sont des unités qu'on peut compiler, c'est-à-dire traduire en code objet
• Les fichiers d'en-tête, portant généralement en C++ l'extension .h ou (moins souvent) .hpp, sont des unités contenant de l'information de support pour les fichiers source : des prototypes de fonctions, des constantes, des déclarations de types, et ainsi de suite

La compilation C++

Il y a au moins deux manières, grossièrement, de prendre du code source et d'en faire un exécutable : le compiler et l'interpréter. Dans ce document, nous allons nous intéresser à la mécanique de la compilation, spécialement pour le langage C++.

• La compilation est la traduction de code source, écrit dans un langage de programmation dit évolué, en code machine.
• Le code machine est le code propre à une catégorie spécifique de machines, une codification numérique dictant les opérations d'un programme en des termes que la machine en question sera en mesure de comprendre.

Le code machine produit par la compilation n'est pas un exécutable, mais y ressemble beaucoup. On dit de ce code que c'est du code objet (portant souvent l'extension .obj).

On compile donc du code source pour générer du code objet, mais la compilation en soi n'est pas suffisante pour générer un exécutable. Dans le schéma ci-dessus, on remarque qu'il y a une phase précédant la compilation en langage C++ (tout comme en langage C). C'est la phase de précompilation, qui repose en bonne partie sur l'action du préprocesseur.

Que compile-t-on?

On ne compile, en C++, que des fichiers sources. Les fichiers d'en-tête servent de support à la compilation, mais ne sont pas compilés.

Ainsi, pour le projet UnProjet en exemple ici, les fichiers bits.cpp, octets.cpp et UnProjet.cpp seront compilés, mais pas les fichiers bits.h et octets.h. Toutefois, ces derniers seront inclus dans des fichiers sourced pour que ceux-ci aient tout le nécessaire pour être correctement compilés.

Dans notre exemple, on présumera avoir écrit des fonctions capables de manipuler des bits et des octets (respectivement dans bits.cpp et dans octets.cpp). Le module UnProjet.cpp comptera sur leur existence pour sa propre exécution.

#include "bits.h"

using mot_t = unsigned short;
using posbit_t = unsigned char;
bool lire_bit(mot_t mot, posbit_t position);

Ceci signifie que tous les fichiers source connaissant ce prototype savent comment appeler une fonction appelée lire_bit(), retournant un bool et prenant deux paramètres (un mot_t, ce qui équivaut à un unsigned short , et un posbit_t, ce qui équivaut à un unsigned char).

Le lien entre la fonction appelée et le code associé, lors de l'appel de code se trouvant dans un autre fichier objet, se fera lors de l'édition des liens.

Prototypes de sous-programmes

Le prototype d'un sous-programme indique au compilateur quelle est la signature de ce sous-programme. Muni de cette information, le compilateur est en mesure de valider toute utilisation faite du sous-programme en question et de distinguer les sous-programmes les uns des autres.

Un prototype de sous-programme déclare son nom, la description (type et – optionnellement – nom) de chacun de ses paramètres, et son type, aussi appelé type de sa valeur de retour. De manière optionnelle, le prototype peut aussi lister les exceptions que le sous-programme est susceptible de lever.

On dit de deux sous-programmes qu'ils sont différents l'un de l'autre s'ils diffèrent en signature.

À la base, cela implique que les deux sous-programmes diffèrent en nom, en nombre de paramètres ou en type de paramètres. Dans le cas des méthodes d'instance, il faut ajouter les qualifications const et volatile à la liste des facteurs permettant de distinguer un sous-programme d'un autre.

int f(int);
int g(int);
int g(int, int);
void g(int, int);

Une règle à retenir

Le langage C++ nécessite qu'on déclare chaque objet avant de s'en servir, peu importe que cet objet soit un type, une constante, une variable, une fonction, etc..

Parfois, un sous-programme ne peut être défini avant son appel. Parfois aussi on aimerait utiliser un sous-programme qui sera défini dans un autre module que celui où il est utilisé (ce qui est extrêmement commun dans les bibliothèques). Dans ces cas, le compilateur C++ acceptera que la définition du sous-programme en question vienne après son utilisation, dans la mesure où il en connaît déjà le prototype.

Déclarer un prototype permet au compilateur de reconnaître l'existence de la signature d'un sous-programme avant que celui-ci ne soit défini. Ainsi, sans savoir exactement ce que le sous-programme en question exécutera comme séquence d'instructions, le compilateur peut en générer le schéma d'appel.

// additionner(a,b) : retourne la somme de a et b
double additionner(double a, double b) {
   return a + b;
}

double additionner(double a, double b); // ou
double additionner(double, double);

Le rôle du prototype d'un sous-programme est de suppléer à l'absence de sa définition par l'essentiel de sa signature.

Le prototype devra posséder (cela va de soi) la même structure que l'en-tête de la définition du sous-programme, à la différence que la déclaration ne possède pas de corps et puisqu'il s'agit d'une instruction elle doit se terminer par un point virgule (;). Évidemment, là où les noms des paramètres sont optionnels dans le prototype, ils sont obligatoires dans la définition.

La syntaxe de la déclaration d'un prototype de sous-programme va comme suit.

type nom ([type0 [nom0], type1 [nom1], ... typeN [nomN]]);

int f(int a);
int g(int);
int g(int, int)
void g(int &a, int b) {
   a = b;
};

En C++, il est obligatoire de déclarer un sous-programme (donc d'indiquer sa définition ou au moins son prototype) avant de tenter de l'invoquer.

Certains compilateurs permettent parfois, par souci de compatibilité avec le code existant, de contourner cette obligation à l'aide d'options de compilation. Toutefois, les prototypes sont d'une utilité indéniable. En plus de clarifier le code en tant que tel, ils permettent d'éviter des erreurs fortuites dans l'exécution du code généré.

Le compilateur

Une fois que le préprocesseur aura terminé son travail, le compilateur cherchera à traduire le code source en code objet.

Pour ce faire, il accomplira trois types de validation :

• Une validation lexicale (p. ex. : il cherchera les fautes d'orthographe)
• Une validation syntaxique (p. ex. : il cherchera les fautes de grammaire)
• Une validation sémantique (p. ex. : il cherchera les fautes de sens, de type, de balancement de parenthèses, et ainsi de suite)

Dans les trois cas, il produira des erreurs s'il n'est pas en mesure de générer du code objet étant donné le code source qu'on lui demande de traduire, et produira des avertissements s'il note des opéraitons à première vue douteuses mais ayant un certain risque de fonctionner.

Ce qui manque au code objet pour en faire un exécutable

Le code objet contient le fruit de la compilation, mais n'est pas tout à fait complet. Il lui manque plusieurs petites choses pour pouvoir être transformé en exécutable. La première chose qui lui manque, d'ailleurs, est le code requis pour exécuter correctement les fonctions qui y sont invoquées mais qui sont définies dans d'autres modules.

Par exemple, si UnProjet.cpp contient un appel à la fonction lire_bit() définie dans bits.cpp, alors la compilation de UnProjet.cpp en UnProjet.obj aura été rendue possible du fait que le prototype de la fonction se trouve dans bits.h, que UnProjet.cpp incluait (sagement).

Par contre, du fait que le prototype d'une fonction se résume à sa signature, pas à son corps, il faut (éventuellement) que le code (compilé dans bits.obj, puisque la définition se trouvait dans bits.cpp) de cette fonction soit liée au code objet se trouvant dans UnProjet.obj.

L'éditeur de liens (Linker)

Un programme spécial se charge généralement des résolutions externes requises pour passer du code objet à un module qui sera exécutable.

L'éditeur de liens cherchera à résoudre les liens externes à chaque module objet (chaque fichier .obj), dans le but d'en arriver à un exécutable cohérent.

Ainsi, il pourra rencontrer certaines situations l'empêchant de réaliser sa tâche, la plupart du temps parce qu'il sera incapable de faire un choix entre plusieurs entités équivalentes ou parce qu'un sous-programme invoqué dans l'un des modules à lier dans l'exécutable en cours de génération ne semble être présent dans aucun autre.

Quelques exemples classiques de problèmes rencontrés lors de l'étape d'édition des liens :

• Deux fonctions (ou plus) dans les divers modules à lier ont la même signature. Dans ce cas, à laquelle des définitions l'éditeur de liens devrait-il connecter les invocations? Ceci est typique des gens qui insèrent des définitions de sous-programmes globaux dans un fichier d'en-tête : chaque fichier source incluant ce fichier se retrouve avec sa propre version de la définition du sous-programme en question, et l'éditeur de liens fait face à plusieurs fichier .obj contenant chacun une définition de sous-programme ayant la même signature (car, clairement, chacun a alors une copie identique du même sous-programme, mais l'éditeur de liens n'a aucun moyen de le savoir!)
• Une fonction est appelée dans un fichier source mais aucun des divers fichiers .obj faisant partie de l'étape d'édition des liens n'en contient la définition – souvent parce qu'il manque un ficheir source dans le projet (donc son fichier .obj n'est pas considéré lors de l'édition des liens) ou parce qu'il y a une différence de signature entre sous-programme appelé et sous-programme défini (ce qui tient souvent d'une simple faute d'orthographe : un prototype indiquant la fonction Abc() alors que la définition est celle de la fonction abc());
• L'exécutable en cours de génération n'expose aucun point d'entrée – aucun des fichiers .obj inclus dans le processus d'édition des liens du projet ne contient le code de la fonction main(). Dans ce cas, d'où débutera alors l'exécution de l'exécutable résultant?

Si l'éditeur de liens parvient à ses fins, alors un exécutable pourra être généré. Il ne reste plus qu'à regarder tout ça en détail.

Voici donc un schéma global du processus de compilation, tel que nous l'avons vu jusqu'ici.

Lectures complémentaires

Quelques liens pour enrichir votre compréhension.

• Pour un texte sur le préprocesseur, voir : ../Divers--c/preprocesseur.html
• Pour un texte sur la mécanique d'appels de fonctions, voir : Programmation-Systeme--Pile-execution.html
• Pour un autre texte sur le sujet de la mécanique de compilation avec C++, voir : http://www.lifengadget.com/lifengadget/compiling-linking-cplusplus/