Forum Linux.noyau Travail autour de la compilation d'un kernel

Posté par  . Licence CC By‑SA.
Étiquettes :
2
16
mai
2013

Bonjour,

J'essaye de recompiler un noyau pour une architecture ARM, en cross compilation depuis une debian wheezy, et là, de suite, j'ai quelques questions dont la réponse ne me paraît pas claire. Je me permets de vous solliciter à ce sujet :)

Mon but est de travailler simplement avec ce noyau (disons: modifier, compiler, et tester). Seulement, là, je voudrais bien faire quelque chose de plus efficace que vi et make: utiliser un IDE.

Travaillant avec netbeans, et bien soit, je lance netbeans. Il gère;
- la compilation croisée (je Xcompile des modules pour Xenomai/powerpc avec depuis longtemps)
- les évènements prebuild et postbuild (transférer un programme sur l'hote, lancer un debugguer remote…)

Bref, mon quotidien. Et là, surprise ! Le kernel dans un IDE, c'est un gros morceau, avec plus de 30k fichiers. Sur un core i5, 4Go, debian wheezy x64, le parsing du projet est…lent. Changer les valeurs de l'IDE (dont le heap size) ne change pas grand chose (ok, je n'ai plus de out of memory).
Vous l'aurez compris. Ce que je cherche, c'est de pouvoir browser mon code simplement (les milliers de DEFINE, les centaines de fonctions, les variables…) pour debugguer et suivre ce noyau. Parce que les parties non-fonctionnelles que je dois reprendre sont toutes… bien… truffées d'appels à des fonctions qui ne sont pas celle du modèle de carte sur lequel je travaille, et suivre le fil de cet écheveau serait déjà une bonne chose.

Je suis même prêt à entendre "Eclipse sait le faire", c'est pour dire mon désespoir ! ;)

Merci de vos retours sur la compilation croisée du noyau depuis un IDE moderne.

  • # Eclipse

    Posté par  . Évalué à 2.

    Effectivement, l'import se passe mieux avec Eclipse, mais étant habitué à Netbeans, j'aimerais savoir si c'est moi qui merde avec ma version 7.3

    Il me reste à voir si la navigation et surtout la compilation se passe correctement: en réalité, c'est l'intégration du makefile avec l'IDE qui m'intéresse (pouvoir, en cas d'erreur cliquer directement l'erreur pour y tomber dessus). En cas de petit projet ca marche bien, mais en cas de gros projet, avec de multiples options de configuration (ARCH, BOARD, CROSS_COMPILE, etc…), je ne sais pas comment c'est géré.

    En ligne de commande, est-il possible de remonter le fil des INCLUDEs / STRUCTs / DEFINE depuis une erreur à la compilation ? Y a-t-il des outils adaptés pour ce genre de recherche ?

    • [^] # Re: Eclipse

      Posté par  (site web personnel) . Évalué à 1.

      Peut-être Kdevelop, cela date un peu mais…voir ici

      • [^] # Re: Eclipse

        Posté par  . Évalué à 2.

        J'utilise personnellement kdev 3 (customisé, avec notamment le background parsing commenté car non déconfigurable dans les settings) et ça va plutôt bien (avec LXR en appoint). Le type dans le lien recommande kdev 4, mais bon j'ai comme des doutes vu comment le parser se traine par rapport à ctags, et aussi parce que les fonctionnalités en général ont plutôt évolué de l'utile vers le clinquant.

        Malheureusement, les binaires de kdev 3 ne sont plus facilement dispo, et sont un enfer sans nom à compiler.

  • # lxr

    Posté par  . Évalué à 3.

    Pour ce qui est de naviguer dans les sources, je te conseille LXR, ici ou là.

    • [^] # Re: lxr

      Posté par  . Évalué à 2.

      Merci, excellent conseil.

  • # Pourquoi ne pas utiliser le même environnement que les hackers du noyau chevronnés?

    Posté par  (site web personnel) . Évalué à 3.

    Je me trompe peut-être, mais je pense que la plupart utilise vi et emacs, efficacement.

    Plutôt que d'essayer de tout réinventer (ce qui n'a pas l'air d'être ton sujet), j'apprendrais plutôt à utiliser les outils établis.

    • [^] # Re: Pourquoi ne pas utiliser le même environnement que les hackers du noyau chevronnés?

      Posté par  . Évalué à 3.

      Juste une note rapide JoeltheLion, je n'ai pas envie de lancer une 'holy war':

      • je ne compte pas me spécialiser dans le développement du noyau en général: je souhaite limiter la phase d'apprentissage au strict minimu
      • ce sujet est un peu traité sur stackoverflow: http://stackoverflow.com/questions/4146911/recommend-linux-ide-for-general-linux-c-kernel-development et je me retrouve définitivement dans la réponse de fiofel "What does this bring you? Full instant code navigation: When studying kernel and developing kernel modules, this happens to be a HUGE time saver: To follow a function call, move the mouse cursor to the (called) function name, press Ctrl, click on the symbol, bingo, it loads the source module and instantly gets you to the function source code. Press the back arrow, you're back at the call place."

      Il préconise Code::Blocks, mais c'est comme Eclipse, j'aurais aimé continuer à capitaliser sur Netbeans.

      Vim/Emacs + Ctags me semblent peu pratique, même si je ne doute pas de leur efficacité pour des devs kernels purs et durs.

      • [^] # Re: Pourquoi ne pas utiliser le même environnement que les hackers du noyau chevronnés?

        Posté par  . Évalué à 3.

        Même si vim n'a pas ta préférence, avec cscope il fait ce dont tu as besoin je pense. Voici un descriptif de l'aide :

        commandes cscope :
add  : Ajouter une base de données    (Utilisation : add file|dir [pre-path] [flags])
find : Rechercher un motif            (Utilisation : find c|d|e|f|g|i|s|t name)
       c: Trouver les fonctions appelant cette fonction
       d: Trouver les fonctions appelées par cette fonction
       e: Trouver ce motif egrep
       f: Trouver ce fichier
       g: Trouver cette définition
       i: Trouver les fichiers qui #incluent ce fichier
       s: Trouver ce symbole C
       t: Trouver cette chaîne
help : Afficher ce message            (Utilisation : help)
kill : Fermer une connexion           (Utilisation : kill #)
reset: Réinitialiser toutes les connexions  (Utilisation : reset)
show : Afficher les connexions        (Utilisation : show)

        Un raccourci pour aller à une définition, un autre pour revenir. Si jamais ça te tente de tester, voici un petit tuto qui m'a permit de m'y mettre, ça prends 20 minutes max à tester.

        Tutoriel Vim/cscope

      • [^] # Re: Pourquoi ne pas utiliser le même environnement que les hackers du noyau chevronnés?

        Posté par  (site web personnel) . Évalué à 3.

        Je ne veux pas lancer de holy war non plus, la vie est trop courte pour ça :) Je voulais juste dire que c'est souvent une bonne idée d'utiliser les mêmes outils que tout le monde, surtout si on ne veut pas s'en faire une spécialité.

        Je ne sais pas exactement ce que tu reproches à vim+ctags, mais il fait exactement ce que tu décris (Ctrl-] et Ctrl-t)

        • [^] # Re: Pourquoi ne pas utiliser le même environnement que les hackers du noyau chevronnés?

          Posté par  . Évalué à 2.

          Je ne lui reproche rien, mais j'utilise des fonctionnalités (généralement graphiques) avec lesquelles je suis quand même trés familier: le refactoring, l'autocomplétion, l'intégration avec un VCS (git en l'occurence) pour des diffs visuels et immédiats, les TODO/FIXME lists, l'historique des modifications locales, la compilation/le debug en un clic…

          J'utilise vi pour l'édition des fichiers de conf (la force de l'habitude) mais pour des choses plus denses, ca ne me va pas trop.

          Ceci dit, je retiens les multiples solutions. J'irais y jeter un oeil au cas où, parce que c'est interessant à connaitre, mais de là à travailler avec, je sais que j'aurais du mal.

  • # Résultats

    Posté par  . Évalué à 2.

    Salut à tous,

    J'ai finalement utilisé Netbeans pour une grosse partie du boulot.

    A noter que:
    - le développement des modules et la retouche de parties précises peut se faire sans charger toute l'arborescence (uniquement definir certains tags de préprocesseur comme KERNEL ou, dans mon cas, CONFIG_OF et CONFIG_I2C). Ces tags n'ont pas de fonction pour la compilation, mais plutot pour le travail dans l'IDE
    - les chemins d'include du compilateur ( -I ) doivent cibler d'une part le classique /usr/src/-mes-sources-linux-/include mais aussi /usr/src/-mes-sources-linux-/arc/arm/machtegra/include
    - enfin la compilation croisée se fait avec un Makefile ou une commande spécifique au choix

    Par contre, que ce soit dans NETBEANS ou ECLIPSE, le parsing complet n'est pas:
    - significatif, par rapport à ce que, logiquement, les .h fournissent
    - voire incomplet, mais je n'ai pas creusé beaucoup plus.

    Mention pour LXR, un excellent site. Le travail sur une VM avec qemu permet de faire des tests rapides. Tout ca peut être automatisé pour déployer à l'issue d'un build (ou d'un run dans mon cas, je veux compiler sans avoir à déployer car c'est relativement long).

Suivre le flux des commentaires

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