194 lines
8.2 KiB
Markdown
194 lines
8.2 KiB
Markdown
# Travail pratique 1
|
||
|
||
## [Q1] Quelle est l'architecture processeur de la carte SAMA5D3 Xplained
|
||
|
||
C'est un processeur d'architecture ARM CORTEX A5
|
||
|
||
Quelques specs :
|
||
- Supporte le jeu d'instruction Thumb2
|
||
- Dispose d'un MMU (Presque essentiel pour linux embed)
|
||
- Dispose d'une unité de calcul a virgule flottante
|
||
|
||
Il m'est demandé ensuite dans le TP d'aller chercher une Toolchain compatible avec certains critères tels que GCC13+ ou l'API Musl
|
||
|
||
Je suis allé sur https://toolchains.bootlin.com
|
||
|
||
Ensuite j'ai choisi de voir uniquement les toolchains destinées aux processeurs ARM A5 basées sur l'API Musl.
|
||
|
||
Il existe aussi des versions avec GlibC mais cette librairie est trop lourde et fait des executables trop lourds eux aussi pour ce que l'on veut faire
|
||
|
||
J'ai ensuite choisis la seule toolchain qui supportait GCC 13+
|
||
|
||
## [Q2] Quel est le nom complet de la toolchain téléchargée ?
|
||
|
||
Le nom complet est armv5-eabi--musl-stable-2024.05-1
|
||
|
||
- Armv5 veut dire que la toolchain contient un GCC qui va compiler pour un processeur ARM5 V5.
|
||
- Les termes EABI indiquent si la target est sensée être en Big endian, si elle supporte les floats etc...
|
||
- musl indique la librairie C utilisée. Ici Musl pour sa taille réduite et la taille minimale des exectuables ainsi créés
|
||
- stable veut dire que c'est une version normalement plus stable que les versions bleeding edge
|
||
- La date nous indique simplement quand la toolchain a été build
|
||
|
||
Dans le nom on ne voit pas la version de GCC, peut-être que on peut la déduire avec la date mais en tous cas sur bootlin la version GCC était indiquée comme étant 13.3.0
|
||
|
||
## [Q3] Quelle est la version complète de GCC de votre chaine de compilation
|
||
|
||
On peut voir dans le dossier BIN de la toolchain différents executables qui ont des noms du genre :
|
||
|
||
`arm-buildroot-linux-muslabi-gcc-13.3.0`
|
||
|
||
Donc j'en déduis que la version de FCC est 13.3.0 mais pour en être sur il faudra l'executer ce que je vais faire un peu plus bas dans ce tp
|
||
|
||
## [Q4] Quel est le nom de la librairie C de votre chaine de votre toolchain ainsi que son numéro de version
|
||
|
||
La toolchain a été choisie justement par ce que sa librairie C était Musl et on peut voir dans les noms des executables que vraissemblalement c'est bien le cas.
|
||
|
||
Je ne sais pas comment connaitre sa version car il n'y a pas d'executable juste Musl. Et en executant ces derniers je n'ai la version que des outils eux mêmes et pas de Musl
|
||
|
||
## [Q5] Dans quel répertoire se trouvent les binaires principaux de votre toolchain ?
|
||
|
||
Tous les outils comme GCC les linkers etc... sont stockés sous
|
||
|
||
`toolchain/bin`
|
||
|
||
Il est ensuite demandé d'ajouter au PATH ce repertoire pour que l'on puisse utiliser ces différents outils depuis nimporte ou dans notre machine
|
||
|
||
Pour ce faire il faut aller éditer le fichier .Bashrc qui se trouve à la racine utilisateur
|
||
|
||
`cd ~`
|
||
`vim .bashrc`
|
||
|
||
Dans le fichier bashrc si on n'a jamais rien ajouté au path on vient à la fin du fichier ajouter :
|
||
|
||
```bash
|
||
# Custom PATH
|
||
export PATH="$PATH:~/tp/toolchain/bin"
|
||
```
|
||
|
||
Attention il est important de ne pas oublier le `$PATH:` avant le lien vers notre toolchain.
|
||
|
||
Si on l'oublie on override le PATH existant et on aurait plus accès aux bin de notre linux ce qui serait vraiment dommage.
|
||
|
||
`/tp/toolchain`c'est simplement le chemin vers ma toolchain
|
||
|
||
## [Q6] Testez votre toolchain avec un petit programme c de votre choix et donnez sa taille
|
||
|
||
Pour ce test voici le code C que je vais essayer de compiler :
|
||
|
||
```C
|
||
#include <stdio.h>
|
||
|
||
int main(){
|
||
printf("Hello, world !");
|
||
}
|
||
```
|
||
|
||
Ce qui est juste le code minimum en C.
|
||
|
||
Voici la commande que j'utilise pour compiler ce code avec la toolchain
|
||
|
||
`arm-buildroot-linux-muslabi-gcc test.c -o test-arm`
|
||
|
||
Cette commande utilise le GCC de ma toolchain pour compiler mon fichier test.c
|
||
|
||
Ensuite pour voir la taille de mon fichier j'utilise
|
||
|
||
`du -sh test-arm`
|
||
|
||
du est la commande disk usage et avec l'argument -s je summarize et avec le -h je le rend Human Readable ce qui veut dire que les unités sont plus faciles à comprendre
|
||
|
||
Cette commande nous retourne
|
||
|
||
`8.0K test-arm`
|
||
|
||
Notre executable fait donc 8000 bits ce qui est très peu !
|
||
|
||
## [Q7] Que se passe-t-il si vous essayez d'executer l'executable obtenu sur votre machine de developpement ? Quelle est la raison de l'erreur obtenue ?
|
||
|
||
Si on essaie d'executer test-arm on obtient :
|
||
|
||
`./test-arm`
|
||
|
||
`bash: ./test-arm: cannot execute binary file: Exec format error`
|
||
|
||
Cette erreur indique en général un problème d'architecture. Elle indique que le fichier binaire que l'on a essayé d'executé n'est pas compatible avec l'architecture processeur de notre machine.
|
||
|
||
Comme personnellement je code sur un MAC M3 j'ai souvent eu cette erreur car la toolchain a été build pour que GCC tourne sur une architecture X86 qui n'est pas la mienne.
|
||
|
||
Pour contourner ce problème j'ai bien galèrer mais j'ai fini par trouver une solution qui conciste à utiliser une machine virtuelle qui émule du X86 avec un ubuntu server car un ubuntu Desktop est trop lent à virtualiser.
|
||
|
||
J'aurais aussi pu simplement build ma propre toolchain avec l'idée de faire tourner GCC sur arm mais je n'avais pas envie de me lancer la dedans
|
||
|
||
## [Q8] Quelle est l'architecture cible exacte de l'exectuable compilé précédemment.
|
||
|
||
Normalement cela devrait être un executable destiné à des processeurs de type ARM V5.
|
||
|
||
## [Q9] Comment pouvez-vous assurer avec certitude que le code binaire généré correspond bien à cette architecture ?
|
||
|
||
Je peux m'en assurer en utilisant la commande
|
||
|
||
`file test-arm`
|
||
|
||
qui me retourne
|
||
|
||
`test-arm: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-arm.so.1, not stripped`
|
||
|
||
Cela me permet de voir que ma target est correcte avec un processeur ARM V5 EABI 32 bits
|
||
|
||
On peut comparer avec un fichier que j'ai compilé avec le GCC de ma machine
|
||
|
||
Déja il fait 16000 bits ce qui est le double de taille
|
||
|
||
Et ensuite si je fais
|
||
|
||
`file test-x86`
|
||
|
||
la réponse :
|
||
|
||
`test-x86: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]blablabla, for GNU/Linux 3.2.0, not stripped)`
|
||
|
||
## [Q10] A titre de comparaison, compilez à nouveau votre petit programme C, mais en executant une edition de lien statique. Quelle est la taille de ce nouvel executable
|
||
|
||
Pour ce faire j'utilise la commande
|
||
|
||
`arm-buildroot-linux-muslabi-gcc -static test.c -o test-arm-static`
|
||
|
||
Ce qui nous donne un nouvel executable et si on utilise la commande
|
||
|
||
`du -sh test-arm-static`
|
||
|
||
expliquée plus haut on obtient
|
||
|
||
`44K test-arm-static`
|
||
|
||
Ce qui veut dire que on est passé de 8kb à 44kb car on a du inclure la librairie stdio.h dans l'executable si je ne dis pas de betise
|
||
|
||
## [Q11] Expliquez la différence de taille obtenue
|
||
|
||
Comme tout juste expliqué, de ce que j'ai compris dans une execution statique on a un exectuable qui doit contenir tout ce dont il a besoin pour tourner et donc on ajoute par exemple dans notre cas la lib stdio.h
|
||
|
||
Pour comparer j'ai fait la même chose avec mon gcc de ma machine et après avoir compilé en statique un simple hello world on se retrouve avec un fichier qui fait 768KB ce qui est IMMENSE par rapport aux pauvres 44kb de Musl
|
||
|
||
De ce qu'on a entendu en cours, la raison pour laquelle on utilise Musl est justement par ce que les executables surtout ceux statiques sont beaucoup moins lourds
|
||
|
||
## [Q12] Quelle est la taille de chaque executable après la suppression des symboles avec strip
|
||
|
||
Evidemment on ne peut pas utiliser le strip de notre machine. Il faut utiliser le strip de notre toolchain et dans mon cas cela donne une commande comme ca
|
||
|
||
`arm-buildroot-linux-muslabi-strip test-arm-static`
|
||
|
||
Et maintenant quand je fais un
|
||
|
||
`du -sh test-arm-static`
|
||
|
||
je recupère
|
||
|
||
`28K test-arm-static`
|
||
|
||
J'ai donc divisé par 2 la taille de mon executable
|
||
|
||
De ce que j'ai pu lire sur internet, la fonction strip retire tous les symboles et toutes les informations de debug ce qui peut réduire drastiquement la taille de l'executable.
|
||
|
||
Ca ne devrait en rien impacter les performances de l'executable mais il devient plus dur de le débug.
|
||
|
||
Voila c'est la fin de ce TP. J'ai passé 5-6h dessus je pense mais c'est ma faute car j'ai décidé de daily drive une machine ARM alors que tout le monde à l'HEPIA semble être sur des architectures X86 |