Journal Chaine(s) de compilation ARM

Posté par .
15
10
avr.
2012

Bonjour,

Ca fait longtemps que le problème m'interpelle, et la sortie du dernier Linux Magazine vient raviver mon sentiment d’incompréhension.

Pourquoi nos distributions préférées ne fournissent-elles pas de chaine(s) de compilation ARM packagées?

Les développements pour microcontrôleur sont pourtant bien supportés sous Linux. GCC supporte beaucoup de plateformes, comme AVR, MSP430, … et les paquets correspondants s'installent facilement (voir avr-gcc et mspgcc pour Debian par exemple).

Mais dès qu'il s'agit de ARM, plus grand chose de disponible! Pas de arm-gcc. J'ai pu simplement trouvé un arm-elf-gcc-base pour Archlinux, mais cela semble un OVNI par rapport aux autres distributions. Pourtant, on peut très simplement installer OpenOCD (Debian) comme on installe AVRdude, qui servent notamment à envoyer son code sur les plateformes ARM (OpenOCD) ou AVR (AVRdude).

Alors chaque tutoriel y va de sa petite combine, de son script de compilation, ou carrément de son outil "tout-intégré-qui-va-bien-pour-ma-cible [registration required]" mais rien de tout cela n'est semblable, ni cohérent, ni forcément maintenu, et il faut bien du courage pour retrouver ces petits là-dedans. Pourtant, il s'agit toujours du même projet, GCC et du même tarball source.

Alors, je comprends que ARM soit un vaste monde, et qu'un outil unique ne satisferait personne. Je comprends également que le gcc ARM pour un processeur qui fait tourner Linux a des pré-requis bien différents du compilateur qui fait tourner du code microcontrôleur sur un Cortex-M0. Mais les outils "fait maison" gère déjà ces différences, et il y a des arm-linux-*-gcc et des arm-none-eabi-gcc.

Pourquoi ne pas packager les 2 (ou 3 ou N)? Est-ce que chaque fabricant de composants à une option différente dans le build de GCC pour son processeur? Est-ce que les mainteneurs de paquets ne veulent pas se lancer là-dedans parce qu'il n'y a pas assez de demandes?

Il me manque sûrement des éléments pour juger de tout ça. Je sais qu'il y a ici des gens qui travaillent dans l'embarqué. J'aimerais avoir votre avis là-dessus.

  • # C'est peut-être plus aux mainteneurs des distributions qu'il faut demander ça ...

    Posté par . Évalué à  2 .

    Pour une distrib comme Ubuntu qui est plus orientée "grand public", ça ne me choque pas. Par contre effectivement, pour une distrib comme Redhat ou Debian, c'est un peu plus curieux. Mais eux seuls pourront te répondre.

    • [^] # Re: C'est peut-être plus aux mainteneurs des distributions qu'il faut demander ça ...

      Posté par (page perso) . Évalué à  1 .

      Euh… Bah justement, il me semble que l’ARM est beaucoup utilisé dans l’embarqué, notamment dans tout ce qui est tablettes et smartphones (et sans doute bientôt netbooks).
      Or, il me semble aussi que le « Grand public » s’oriente en ce moment vachement vers ce genre de matos… Donc le distros comme ubuntu ne devraient‐elles pas anticiper cette migration (qui est somme toute déjà en train de se faire) ?

      • [^] # Re: C'est peut-être plus aux mainteneurs des distributions qu'il faut demander ça ...

        Posté par . Évalué à  5 .

        Il y a une différence entre "tourner sur ARM" et "cross-compiler pour ARM".

        La plupart des grandes distros, y compris Fedora, Debian (et donc Ubuntu), openSUSE, etc.. ne sont pas cross-compilées, mais sont compilées nativement. Le projet Debian, par exemple, possède un cluster de machine ARM (je sais plus trop laquelle, exactement), sur lequel la distrib est compilée nativement pour ARM.

        Idem pour les autres architectures : PPC, MIPS, x86…

        Hop,
        Moi.

  • # Debian

    Posté par (page perso) . Évalué à  2 .

    Pour Debian on peut trouver des "cross compilers" déjà pré-compilés:
    http://wiki.debian.org/BuildingCrossCompilers#To_install_a_prebuilt_cross_compiler

    • [^] # Re: Debian

      Posté par . Évalué à  3 .

      Oui, mais ils sont "hébergés" par le projet emdebian.org (pourquoi pas directement pas Debian), et en plus ils ne couvrent que les cas de Linux embarqué, pas ceux des microcontrôleurs.

      Mais, ce qui est à retenir de ce lien, c'est:
      > MOST PEOPLE SHOULDN'T BE BUILDING THEIR OWN CROSS-TOOLCHAIN - THEY SHOULD JUST INSTALL A PRE-BUILT ONE LIKE ANY OTHER PACKAGE.

      J'aimerais pouvoir faire un apt-get install arm-cortex-m0-gcc sur ma machine.

      • [^] # Re: Debian

        Posté par . Évalué à  1 .

        le projet emdebian.org

        Je dis rien, on va attendre vendredi… ;-]

        MOST PEOPLE SHOULDN'T BE BUILDING THEIR OWN CROSS-TOOLCHAIN - THEY SHOULD JUST INSTALL A PRE-BUILT ONE LIKE ANY OTHER PACKAGE.

        Bon tant pis : Bwaahhaaa !
        Non, sans déc´, ils y croient toujours ?

        Bon sinon, compiler sa propre toolchain, c´est pas si compliqué : crosstool-NG est là pour ça (et pas plus ; ni moins, d´ailleurs). Et crossdev (que je ne connais pas) de Gentoo. Et buildroot, OpenEmbedded, openWRT, OpenBricks pour construire de systèmes complets…

        Hop,
        Moi.

  • # Libc

    Posté par (page perso) . Évalué à  3 .

    En fait, il faudrait une toolchain avec une libc, libm et libgcc compilée avec toutes les cibles ARM pour que ce soit efficace, ou au moins les familles :
    - ARMv4
    - ARMv5
    - ARMv6
    - ARMv6
    - ARMv7

    et aussi avec toutes les variantes des libc :
    - glibc
    - eglibc (avec quelles options ???)
    - uclibc (avec quelles options ???)
    - sans libc
    - newlib

    bref, ça fait un sacré boulot à générer… surtout pour plusieurs versions de GCC mais avec quels patchs ? ceux de codesourcery ou linaro ?

    Se limiter aux seules cibles ARMv7 d'Android sans libc, c'est un peu restrictif !

    • [^] # Re: Libc

      Posté par . Évalué à  0 .

      Je suis d'accord que c'est un sacré boulot, mais ça n'est pas plus complexe à gérer que les différentes versions de KDE, GNOME, et les autres bureaux, pour que tout s'intègre bien à la distribution.

      Avoir plusieurs GCC et libc sur la même machine, c'est largement possible. Et si c'est géré au niveau de la distribution, ça facilite grandement la vie.

      Je pense que trouver une méthode cohérente (et acceptée) pour tout empaqueter correctement est plus difficile.

      Quand on voit que la compilation de GCC dans buildroot pour un système sur cible ARM "simple" est une des étapes les plus longues, je me dis que ca pourrait être intéressant d'avoir un GCC tout prêt à installer.

      • [^] # Re: Libc

        Posté par . Évalué à  4 .

        Quand on voit que la compilation de GCC dans buildroot pour un système sur cible ARM "simple" est une des étapes les plus longues

        C´est pour ça qu´il y a l´option pour utiliser une toolchain externe.

        Dans le principe, tu construit ta toolchain une fois pour toutes, et ensuite tu dis à buildroot où la trouver. Comme ça, tu perds pas ton temps à chaque fois.

        Hop,
        Moi.

    • [^] # Re: Libc

      Posté par . Évalué à  10 .

      Pour ARM, c´est vraiment un mode très compliqué. Rien que pour le calcul flottant, c´est compliqué :

      • soft-float ; hard-float avec: VFPv3, VFPv2, Neon, Maverick, FPA, iwmmxt…
      • ABI des flottants : hard ou soft (utilisation des instructions hardware, mais passage des flottants comme pour du soft-float, sachant que l´ABI hard est différente de l´ABI soft…)

      Ensuite, comme dis précédemment :

      • ARMv4, v5, v6, v7, bientôt v8?
      • optimisé (ordonnancement des instructions) pour :
        • v5 : XScale, ex93xx, mpcore…
        • v6 : cortex-a8, etc…
        • etc…
      • etc…

      Pour ARM, à l´époque où j´avais compté, j´étais arrivé a plus de 2048 combinaisons valides possibles… 8-O

      Et puis pourquoi aussi les chaînes de compilation croisée, avec des combinaisons plus ou moins nombreuses (plutôt plus que moins, d'aileurs…) pour toutes les architectures :

      • MIPS : 32 et 64 bits, trois ABI…
      • PowerPC : 32 et 64 bits, au moins 4 ABI, des SoCs hyper variés…
      • Alpha : Heu…
      • AVR32 : avec ou sans MMU (IIRC)
      • Blackfin : avec ou sans MMU (IIRC)
      • ix86 (eg. geode est un i586 spécial, etc…), 32 et 64 bits, avec/sans MMX/MMX2/SSE/SSE2/SSE3/SSSE/SSSE2/3DNow/…
      • or32k

      Et ce avec différentes libc, compilées pour chacune des variantes d´optimisation possibles, etc…

      Et tant qu´à faire, différentes versions de binutils, de gcc (avec ou sans GRAPHITE, avec ou sans LTO, etc…), différentes versions de chaque libc (ben oui, certaines ont des bugs ou des fonctionalités supprimées (eg. glibc >= 2.14 ne permet plus de développer des applis utilisant les RPC)…

      Bon, bref, à part packager quelques toolchains, qui de toute façon ne couvriront qu´une petite partie des gens intéressés, et pour quelques cibles trés visibles, c´est pas gagné.

      Et je parle en connaissance de cause : je maintiens crosstool-NG (cité plus bas), j'ai déjà présenté le sujet à trois conférences (ELCE '09, ELCE '10 et FOSDEM '10), et faire des chaînes de compilation croisée fait partie de mon boulot (aussi)… Et pour plus d´infos, je devrais (à confirmer) donner une conférence sur le sujet aux RMLL 2012.

      Bref, que du bonheur… :-p

      Hop,
      Moi.

      • [^] # Re: Libc

        Posté par . Évalué à  1 .

        Merci pour ta réponse complète! Effectivement, 2048 combinaisons, ce n'est pas raisonnable de tout packager.

        Cela dit, la ligne sur les ix86 m'interpelle. Il y a en effet beaucoup de cas possibles aussi, comme tu l'indiques. Mais quand j'installe ma distrib, déjà elle tourne sur n'importe quelle variation (du moins beaucoup) de ix86 sans problème, et lorsque j'installe GCC, j'ai le même binaire pour tous les ix86 supportés.

        Alors je sais, ça ne génère pas du code optimal, c'est souvent pour les i386, mais ca marche bien pour la plupart des cas.

        Pourquoi un compilo pour Cortex-M0 avec sa libc associée ne conviendrait pas pour la plupart des développements sur Cortex-M3? Ou pour reprendre ton exemple, pourquoi ne pas utilisé que des instructions ARMv5 pour une chaine de base? Si on veut optimiser, on peut construire sa toolchain, mais de base, "ça marche".

        Après, il peut y avoir des flags de compil' pour le soft-float/hard-float par exemple.

        Enfin, je comprends mieux le besoin de générer une chaine de compilation maison, ou de l'obtenir auprès d'un tiers, puisqu'il y a une infinité de possibilités, surtout chez ARM qui est présent chez de nombreux fondeurs.

        A+

        • [^] # Re: Libc

          Posté par . Évalué à  1 .

          Alors je sais, ça ne génère pas du code optimal, c'est souvent pour les i386, mais ca marche bien pour la plupart des cas.

          La grande majorité des distributions ne sont plus compilées pour i386 depuis gcc3. Maintenant c'est i486 pour Slackware et Debian, et i686 pour la majorité des autres distributions.

          • [^] # Re: Libc

            Posté par . Évalué à  4 .

            i486 pour […] Debian

            Heu, sur Squeeze, c´est i586. IIRC, i486 ne supporte NPTL, et glibc/eglibc sont NPTL depuis longtemps (les LinuxThreads sont morts depuis au moins 5 ans, déjà qu´ils étaient pas en grande forme avant ! ;-) )…

            Hop,
            Moi.

            • [^] # Re: Libc

              Posté par . Évalué à  2 .

              IIRC, i486 ne supporte NPTL

              Sous Slackware 13.1 (glibc 2.11, i486):

              $ objdump -d /lib/libpthread.so.0 | grep -i wrmsr
              $ objdump -d /lib/libpthread.so.0 | grep -i cmpxchg8b
              $ objdump -d /lib/libpthread.so.0 | grep -i cpuid
              $ objdump -d /lib/libpthread.so.0 | grep -i rdtsc
              $ objdump -d /lib/libpthread.so.0 | grep -i rdmsr
              $ objdump -d /lib/libpthread.so.0 | grep -i rsm
              $

              D'après Wikipédia ce sont les seules nouvelles instructions i586.

              Et d'après la documentation de Debian Squeeze, seuls les 386 et plus anciens (2.1.2.1.) sont incompatibles.

        • [^] # Re: Libc

          Posté par . Évalué à  3 .

          quand j'installe ma distrib, déjà elle tourne sur n'importe quelle variation (du moins beaucoup) de ix86 sans problème

          Le plus petit dénominateur commun… ;-) Pour ix86, c'est souvent i586 de nos jours, notamment car NPTL ne supporte pas i386 (ni i486 IIRC).

          Et comme tu dis, ce n´est pas optimisé. Exit l´accélération SSE pour le calcul de hash ; exit l´accélération SSE3 pour le calcul 3DES… (exemples ! )

          Certains programmes ont cependant une détection à l´exécution pour utiliser certaines routines ou d'autres en fonction du CPU (eg. ffmpeg, IIRC).

          Pourquoi un compilo pour Cortex-M0 avec sa libc associée ne conviendrait pas pour la plupart des développements sur Cortex-M3?

          Si tu considères une famille de CPU ARM, alors oui, une toolchain ciblant le plus petit dénominateur commun de cette famille va générer du code tournant sur tous les CPUs de cette famille, même si de façon non-optimale dans la plupart des cas. En fait, le compilo, c´est pas trop grave, avec des flags de compil, on peut choisir un autre processeur. Par contre, la libc, une fois compilée, c´est marre.

          Dans le monde de l´embarqué, les resources sont souvents contraintes, et notamment l'alimentation pour les mobiles, par exemple. Faire tourner du code optimisé pour le processeur réellement utilisé, ça peut faire gagner quelques miliwatt par-ci, par-là, et pof ! deux heures d'autonomie supplémentaire !

          Après, il peut y avoir des flags de compil' pour le soft-float/hard-float par exemple.

          Avec gcc, on peut (même si c´est loin d´être trivial) compiler une toolchain 'multilib' qui utilise les flags de compil pour savoir quelle libc utiliser. Reste qu'il faut quand même compiler la libc autant de fois qu'il y a de combinaisons possibles de ces flags de compil.…

          • [^] # Re: Libc

            Posté par . Évalué à  -1 .

            à propos, j'essaie de compiler gcc et la glibc pour x86-64 sur un x86, pour recompiler le noyau. j'arrive pas à le faire avec CrosstoolNG, et si j'ai réussi à compiler gcc stage 1, impossible de compiler directement la glibc car il y a une dépendance cyclique.

            La solution c'est, je pense, d'utiliser la newLib pour avoir une libc qui permette de compiler la glibc … Je pensais que la glibc était "freestanding".

    • [^] # Re: Libc

      Posté par . Évalué à  0 .

      En fait, il faudrait une toolchain avec une libc, libm et libgcc compilée avec toutes les cibles ARM pour que ce soit efficace

      Oui en plus il faut rajouter toutes les variations d'ARM et le fait que les différents bus varient d'une plateforme à l'autre.
      En fait sous ARM c'est plutôt une plateforme = un toolchain. Dejà tu as de la chance si la même toolchain fonctionne entre la v1 et la v2 d'un même device.

  • # Sourcery CodeBench

    Posté par . Évalué à  2 .

    Pour des projets à base de Cortex M3 j'utilise la ToolChain Sourcery CodeBench la libC utilisée est newlib , ils fournissent aussi une ToolChain arm-linux-*.
    Par contre ils ne fournissent pas de package pour distribution, c'est un script d'installation.

    • [^] # Re: Sourcery CodeBench

      Posté par . Évalué à  2 .

      Oui, cette toolchain est connue, et c'est un des éléments de ma réflexion: Pourquoi diable faut-il que j'aille chercher chez Mentor Graphics le code source / le binaire de GCC qui est par ailleurs disponible dans ma distrib et sur http://gcc.gnu.org ?

      En plus, ce n'est pas vraiment "gratuit", puisqu'il faut s'enregistrer. Je préfère encore suivre les conseils de Linux Magazine et compiler moi-même la toolchain à l'aide du script https://github.com/esden/summon-arm-toolchain (et la libc est également newlib).

      • [^] # Re: Sourcery CodeBench

        Posté par . Évalué à  4 .

        As-tu essayé crosstool-ng (qui est aussi un ensemble de script/patches pour la génération de chaînes de compilation croisée) ?
        http://crosstool-ng.org/

        • [^] # Re: Sourcery CodeBench

          Posté par . Évalué à  2 .

          C´est pas moi qui ai commencé à en parler, alors je l´ai replacé un peu plus haut ! ;-]

          Mais bon, content de voir que des gens le recommande ! :-)

          Hop,
          Moi.

  • # Gentoo ?

    Posté par (page perso) . Évalué à  -3 .

    L'intérêt d'avoir une distro où rien n'est compilé d'avance, c'est que tout est dispo plus facilement :-)

    http://www.gentoo.org/main/en/where.xml
    (pas d'iso disponible, mais tu peux booter sur ce que tu veux, puis installer ton stage3, puis continuer ton installation en 3 commandes dont la première fait 250 caractères…)

    • [^] # Re: Gentoo ?

      Posté par (page perso) . Évalué à  -1 .

      Et comme ça en bonus il aura le droit à une année sabbatique le temps que sa chaine de compilation ARM soit prête…

      • [^] # Re: Gentoo ?

        Posté par . Évalué à  1 .

        Pour l'avoir fait, c'est relativement rapide et c'est un coût unitaire.
        L'outil Crossdev est vraiment très bien fait.
        Pour les plateformes où on ne peut s'attendre à ce que quelqu'un est compilé la toolchain pour vous, c'est quand même intéressant d'avoir un outil qui automatise la tâche sans avoir à aller à la pioche au script-qui-va-bien.
        Enfin, une fois compilée, on peut très bien générer des packages binaires pour le déploiement.

      • [^] # Re: Gentoo ?

        Posté par (page perso) . Évalué à  1 .

        Ca me semble être préférable à la solution actuelle. D'ailleurs, c'est quoi la solution actuelle ? (oui parce que c'est mignon de mettre "-2", mais Gentoo est bien une distribution qui fournit un package arm).

  • # Compiler pour le Nokia N900 (ARMv7)

    Posté par (page perso) . Évalué à  6 .

    Une des raisons pour laquelle j'ai acquis un N900, c'est pour pouvoir y faire tourner mes logiciels (codés en C/C++).
    J'avais réussi à installer ce qu'il fallait sous Ubuntu, mais ce fût pénible. A tel point que, suite à une réinstallation d'Ubuntu, plutôt que de réinstaller (et reconfigurer !) tous les outils, j'ai essayé d’installer le compilateur directement sur le N900. Et bien, c'est beaucoup plus simple ! C'est sûr qu'on a intérêt à brancher le N900 sur secteur et à être patient lorsqu’on lance une compilation (surtout avec un l'option '-Ox'), mais ça fonctionne ! Concrètement, je développe le logiciel sur ma machine de bureau, et, une fois achevé, je me logue en 'ssh', transferts les sources et le 'Makefile' par 'scp', puis lance un 'make' et j'ai mon logiciel qui tourne sur le N900.

    Ce n'est sans doute pas possible sur toutes les plateformes à base d'ARM (le N810, par exemple, manque de mémoire pour compiler un logiciel un peu conséquent, mais il fait tourner tous les exécutables que j'ai compilé sur mon N900), mais certains de ces bestiaux ont les ressources nécessaires. Le N900, par exemple, et nettement plus puissant que l'ordinateur sur lequel j'ai installé mon premier Linux (et réaliser mes premières compilations) !

    Ingénieur consultant en informatique; développeur de Logiciels Libres.

  • # buildsystem mageia

    Posté par (page perso) . Évalué à  3 .

    tu peux te renseigner concernant mageia à partir de http://blog.mageia.org/fr/2011/06/23/de-nouveaux-habits-pour-mageia-une-preversion-du-portage-arm-est-disponible/

    ou de http://stewbenedict.org/mageia-arm-pogo.html qui montre une utilisation de l'image qemu pour un PogoPlug Pro pour se créer un chroot (et compiler nativement ses paquets).

    bon, ce n'est pas de la compilation croisée, les résultats pouvant différer d'une compilation native.

  • # Crossdev

    Posté par . Évalué à  5 .

    Sous gentoo, il y a crossdev:

    crossdev -t arm-none-linux-gnueabi -S
    
    

    ça marche même pour des target spéciaux, type i686-pc-mingw32 ou avr.

    • [^] # Re: Crossdev

      Posté par (page perso) . Évalué à  1 .

      Je confirme, j'avais testé à l'époque pour faire quelques petits devs sur GP2X. On lance crossdev, on attend (glibc, gcc, … ça prend un peu de temps) et hop une chaîne de compil qui marche

      Un autre avantage de crossdev, on peut ensuite utiliser l'arbre portage pour faire des "cross-emerge", et donc avec une commande compiler tous les packages dont on a besoin (dans mon cas les libs SDL, et glib aussi je crois).

  • # ELDK / Crosstool

    Posté par . Évalué à  3 .

    Sur ArchLinux, on trouve des chaines de compilation assez facilement, en binaire sur le dépôt community, ou sur AUR (à compiler dans ce cas là par contre).

    Cependant, les combinaisons pour construire une chaine de compilation sont très variées, et il est difficile de toute les packagées. Oriente toi vers ELDK qui est un bon outil qui propose une série de binaires prêts à installer. Crosstool aussi est plus complexe mais plus modulable. Il s'agit d'un ensemble de scripts qui te télécharge les sources requises en fonction des choix que tu as fait (architecture cible, libc,…) et qui t'installe la chaine de compilation. Et pour ces deux produits, pas de "registration needed" :)

  • # Fedora s'est posé la question récemment

    Posté par . Évalué à  1 .

    Le problème vient des temps de compilations en natif très long: http://lwn.net/Articles/487622/

  • # lib pour micro

    Posté par . Évalué à  1 .

    Bonjour,

    Je profite du sujet pour poser ma question de débutant.
    Une fois qu'on a fait le tour d'arduino, qui présente des avantages évidents pour les débutants, mais aussi pas mal de limitations (limitation en IO, et Hz du hard, ..).

    Quelle est la prochaine étape ?
    pour mon besoin, http://mbed.org/ propose un ensemble hard/soft adapté. Mais son IDE en ligne & co, c'est rédhibitoire.

    Ce que propose leaflab est attractif côté hard, mais leur soft semble encore léger
    http://leaflabs.com/devices/
    ou encore olimex, du hard bien foutu, un prix ajusté
    http://www.olimex.com/dev/olimexino-stm32.html
    mais la encore, côté soft …

    Je cherche une solution pour faire des AI, une AO, du CAN, des DIO (sur interruptions ou pas), qques UART.
    Avec les libs qui vont bien (style, ne pas tout me retaper à la main pour le CAN..)

    Si qu'un à une bonne piste, je suis preneur !

    • [^] # Re: lib pour micro

      Posté par . Évalué à  1 .

      A ce propos, je te conseille la lecture du dernier Linux Magazine, l'article sur le Cortex-M3 qui utilise le même micro que la platine Olimex STM32.

      Côté soft, il y a la libopencm3 qui semble assez active. Après, j'ai pas encore testé, mais ça ne saurait tarder!

      Sinon, il y a aussi les cartes NXP LPCXpresso disponible pour ~20€ qui utilise un micro similaire. Mais quid des outils justement…

      A+

      • [^] # Re: lib pour micro

        Posté par . Évalué à  1 .

        LPCXpresso ! Oui, c'est intéressant aussi.
        Encore pas testé.
        Mais un rapport perf+IO/prix très attractif.

        Je vais lire le linux_magazine sur le Cortex-M3. Mais j'ai peur de ne pas encore y trouver une chaîne de compilation + lib multi-usages (SPI, CAN, PWM, …)

  • # apt-get install gcc-arm-linux-gnueabi

    Posté par (page perso) . Évalué à  2 .

    Il y a la toolchain de Linaro dans ubuntu…

    http://packages.ubuntu.com/oneiric/gcc-arm-linux-gnueabi

  • # Quelle est la difficulté de la compilation croisée ?

    Posté par . Évalué à  2 .

    C'est certainement une question de néophyte, mais quelle est la difficulté à compiler pour une plateforme X sur une plateforme Y ?

    Au final, il s'agit "juste" de traduire d'un langage à un autre, et je ne crois pas que les processeurs actuels aient des commandes spéciales pour générer du code machine, non ?

    • [^] # Re: Quelle est la difficulté de la compilation croisée ?

      Posté par . Évalué à  6 .

      quelle est la difficulté à compiler pour une plateforme X sur une plateforme Y ?

      Rien de compliqué. Il faut juste avoir une chaîne de compilation croisée. Et c'est là le hic : générer ou obtenir une telle chaîne de compilation n'est pas trivial…

      Juste pour info : How is a toolchain constructed?

      il s'agit "juste" de traduire d'un langage à un autre

      De manière généralement admise, la compilation consiste à traduire un programme écrit dans un langage de haut niveau (ie. compréhensible par humain, comme le C), en instructions interprétables par le CPU (ie. une suite d'octets, du 'code binaire').

      Chaque architecture (ARM, x86, MIPS…) possède son propre jeu d'instructions, non compatibles entre eux. Donc il faut une chaîne de compilation spécifique pour chaque architecture (voire, comme expliqué plus haut, pour chaque combinaison de variante de CPU, de flags, de libc, etc…).

      Traduire d'un langage à un autre (eg. prendre un programme écrit en Go, et émttre du code C) n'est généralement pas considéré comme de la compilation. Dans ce cas on parle de trans-compilation. (et pas de cross-compilation).

      NB: le code assembleur est déjà un langage de programmation, de bas niveau, mais doit tout de même être 'compilé' (dans ce cas particulier, on dit 'assemblé') pour générer du code binaire.

      • [^] # Re: Quelle est la difficulté de la compilation croisée ?

        Posté par . Évalué à  0 .

        Très bien, mais dans ce cas, il ne s'agit pas de simplement passer le bon paramètre au compilateur ? (j'imagine que non, mais poussons le raisonnement jusqu'au bout…)

        • [^] # Re: Quelle est la difficulté de la compilation croisée ?

          Posté par (page perso) . Évalué à  4 .

          Il faut aussi que les bibliothèques que tu utilisent soit compilées pour la plateforme cible.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Quelle est la difficulté de la compilation croisée ?

          Posté par . Évalué à  9 .

          dans ce cas, il ne s'agit pas de simplement passer le bon paramètre au compilateur ?

          Dans la théorie, cela pourrait être le cas. On aurait alors (en gros) :

          • un frontal qui interprète le langage (eg. le C) et émet une représentation intermédiaire (IR, intermediate representation) du programme (pour gcc, c´est du GIMPLE (in-memory, pas de on-disk), pour llvm, c´est du bitcode (on-disk, pas de nom pour in-memory)
          • un ou plusieurs optimiseurs qui modifient la structure de l´IR (et donc émettent aussi de l´IR)
          • un backend qui interprète l'IR et émet du code assembleur
          • l´éditeur de liens (linker) qui émet du code binaire

          En fonction des flags passés au compilateur (ou en fonction de son nom), le compilateur peut alors choisir quel backend et éditeur de liens utiliser.

          C´est globalement la structure utilisée par LLVM, mais pas pour gcc. Pour gcc, le frontal, les optimiseurs et le backend sont dans le même binaire (en gros). Si tu veux rajouter un frontal ou un backend, il faut recompiler tout gcc (tsss…).

          De plus, pour LLVM, les optimiseurs peuvent être des programmes ou librairies à part. Pour gcc, ce ne peut être que des librairies, et c´est plus dur à utiliser, vu que GIMPLE est peu documenté (à ma connaissance). Pour LLVM, bitcode est très bien documenté, ce qui rend l´écriture d´optimiseurs plus facile.

          Mais en gros, dans le monde 'gcc', vu que le backend est intégré aux frontaux, ajouter une cible ou un langage implique de recompiler tout gcc…

          Hop,
          Moi.

      • [^] # Re: Quelle est la difficulté de la compilation croisée ?

        Posté par . Évalué à  3 .

        De manière généralement admise, la compilation consiste à traduire un programme écrit dans un langage de haut niveau (ie. compréhensible par humain, comme le C), en instructions interprétables par le CPU (ie. une suite d'octets, du 'code binaire').

        Je vais chipoter. :) Un compilateur traduit un langage (quel que soit le niveau) vers un autre langage. Généralement oui, on part d'un langage qui a un plus haut niveau d'abstraction vers un langage qui propose un niveau d'abstraction plus bas¹. Mais ce n'est pas obligatoire.

        Traduire d'un langage à un autre (eg. prendre un programme écrit en Go, et émttre du code C) n'est généralement pas considéré comme de la compilation.

        Autant la phrase précédente j'estime que je chipotais, autant là je ne chipote pas : traduire du Go en C est de la compilation, définitivement.

        Une chaîne de compilation (vue de très très loin), ça ressemble à ça :

        Langage source -> Front-End -> IR de haut niveau -> Middle-End -> IR de bas niveau -> Back-End

        En détails, ça donne :

        Langage source -> Front-End (Analyse lexicale -> analyse syntaxique -> analyse sémantique) -> génération de représentation intermédiaire, appelée IR (par exemple sous forme de représentation « graphique » comme un arbre de syntaxe abstrait)

        IR -> middle-end (qui transforme l'IR avec des passes successives, pour optimiser certains accès, transformer les boucles, etc.) -> IR de bas niveau

        IR de bas niveau (généralement on est passé d'un AST à une représentation proche d'une sorte d'assembleur de très bas niveau — contenant souvent plus d'infos que ce que la cible peut représenter) -> Back-End (sélection d'instruction -> ordonnancement d'instruction -> allocation de registres)

        Très souvent tout un tas d'optimisations de bas-niveau sont opérées aussi au niveau du back-end.

        C'est « tout ». Il n'est dit nulle part qu'on ne pourrait pas compiler (par exemple) d'un langage assembleur x86 vers un langage assembleur Itanium (si ce n'est que ce serait quand même 'achement difficile d'un point de vue technique, mais c'est faisable).

        [1] Par exemple, OCaml a pendant un certain temps compilé d'abord vers C, puis utilisé gcc comme « backend » vers du code natif.

        • [^] # Re: Quelle est la difficulté de la compilation croisée ?

          Posté par . Évalué à  3 . Dernière modification : le 12/04/12 à 01:13

          Dans l´ensemble, tu n´as pas tort. Mais tu as dû loupé (je pense) ces deux petits passages (oui, les mots ont de l´importance ;-) ) :

          De manière généralement admise […] la compilation consiste à traduire un programme […] en instructions interprétables par le CPU
          Traduire d´un langage à un autre […] on parle de trans-compilation.

          … dans lesquels je précisait quand même le cadre ;-)

          prendre un programme écrit en Go, et émettre du code C
          compiler (par exemple) d'un langage assembleur x86 vers un langage assembleur Itanium

          Ce n´est pas techniquement impossible (et quand même sacrément tordu dans le deuxième cas ;-) ), mais ce n'est pas ce que de manière générale on appelle de la compilation. Dans ces cas, on parle plutôt de trans-compilation (j´ai même vu une fois tradu-compilation).

          Attention, aussi : l´assembleur est un langage ! Ce n´est pas la même chose que le code binaire qui s´exécute sur le CPU.

          En détails, ça donne :
          […]

          Globalement, oui. À ceci près que l'IR de haut niveau peut déjà subir des transformation avant de passer dans le middle-end :

          [SRC] -> FE -> [HLIR] -> OPTIM -> [HLIR] -> ME/OPTIM -> [LLIR] -> BE -> [ASM] -> ASM/OPTIM -> [OBJ]

          Données au format [X] :

          • SRC = Code source
          • HLIR = High-Level IR
          • LLIR = Low-Level IR
          • ASM = Code assembleur
          • OBJ = Code objet (aka binaire)

          Actions [X] :

          • FE = Frontend
          • OPTIM = Optimisers
          • ME = Middle-end
          • BE = Backend

          Par exemple, OCaml

          Ou Go, plus récemment ; et des tas d'autres : Eiffel, Pascal… Et j'ai aussi écrit un trans-compilateur pour traduire des automates à états vers du C.

          Mais il se fait tard, et l´on pourrait dire que, la fatigue aidant, nous pinaillions sur les mots… Moins de 24h à attendre pour reprendre la discussion ! ;-p

          Hop,
          Moi.

          • [^] # Re: Quelle est la difficulté de la compilation croisée ?

            Posté par . Évalué à  2 .

            Oui dans l'ensemble nous sommes d'accord. :) Je suis juste un peu psycho-rigide sur la définition de compilation. Et je suis tout à fait d'accord pour dire qu'un langage d'assemblage est un langage (j'ai eu à écrire des préprocesseurs simples pour langages ASM à mes heures perdues…).

            Je n'ai pas donné tous les détails pour la chaîne de compil car effectivement, il faudrait aussi ajouter l'impact de l'API visée sur l'ensemble de la chaîne, l'influence des appels de fonction en règle générale, etc. etc. :)

    • [^] # Re: Quelle est la difficulté de la compilation croisée ?

      Posté par . Évalué à  1 .

      C'est certainement une question de néophyte, mais quelle est la difficulté à compiler pour une plateforme X sur une plateforme Y ?

      autotools et pkg-config pour commencer…

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.