Journal Bold: un linker particulier

Posté par (page perso) .
Tags : aucun
26
9
août
2009
J'ai l'honneur de vous faire part de la sortie de Bold, un linker d'un genre particulier qui ne servira pas à grand monde :-)

Il est spécifiquement conçu pour ceux qui souhaitent réaliser des intros 4k (voire 1k), et ne fonctionne que pour x86_64. Pour des tailles supérieures, je doute que ses avantages contrebalancent ses limitations.

Distribué sous GPL 3, il est écrit en python et disponible sur [http://www.alrj.org/projects/bold/]. Toute suggestion, amélioration, critique ou remarque est la bienvenue.

La partie "runtime", qui peut être incluse dans le binaire final, est écrite en assembleur et bénéficie d'une exception à la GPL, un peu comme le runtime de GCC.

Les principales caractéristiques de Bold sont les suivantes :
  • En-têtes ELF limités au strict minimum
  • Structures internes (particulièrement la table DYNAMIC) réduites à leur plus simple expression.
  • Résolution des symboles externes par hash, pour ne pas embarquer dans le binaire les noms de fonctions à rallonge (OpenGL est parfois champion pour ça)
J'ai encore quelques idées d'amélioration, mais peu de courage pour les implémenter :
  • Réordonner les différentes sections jusqu'à trouver l'arrangement qui compresse le mieux
  • Porter la chose pour x86, en 32 bits
  • # Intéressant

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

    Je trouve ça intéressant comme projet, ça permet d'étudier la partie linker d'un autre point de vue que ce qui est fait avec gcc.
    (On a déjà vu des projets comme gold proposer des linkers alternatifs pour certaines fonctionnalités, ici c'est une autre direction)

    D'ailleurs, il y a quelques posts de Flameeyes (qui poste notamment sur Planet Gentoo), qui sont intéressants à lire:
    http://blog.flameeyes.eu/2008/04/11/about-gold-and-speed ("sub-string collapsing" ?)
    http://blog.flameeyes.eu/2006/09/22/sometimes-i-think-im-was(...) (-fvisibility)

    Sinon j'ai quelques questions :
    Quelle est la méthode utilisée pour compresser et décompresser le code? J'imagine que le décompresseur doit être intégré au début de l'exécutable, suivi de l'exécutable réel compressé?
    Quel est l'algorithme utilisé, lzma/xz (XZ Embedded?), bz2, gz? J'imagine que d'un côté c'est bien de pouvoir beaucoup compresser, mais en 4k il n 'y a pas beaucoup de place pour avoir un décompresseur trop complexe.
    • [^] # Re: Intéressant

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

      Merci pour tes deux liens.

      Je ne me suis pas penché sur le problème du "sub-string collapsing" parce qu'en général, quand le binaire est limité en taille de cette manière, peu de bibliothèques sont utilisées (SDL et GL suffisent souvent). Les noms des bibliothèques étant les seules entrées de la strtab, les collisions sont virtuellement inexistantes.

      En ce qui concerne la compression, bold ne fait rien lui-même. La solution retenue et communément acceptée est d'utiliser un dropper, une petite ligne de script shell insérée avant le fichier compressé.
      #!/bin/sh
      a=/tmp/I;tail -n+3 $0|zcat>$a;chmod +x $a;$a;rm $a;exit
      [binaire compressé]


      De cette manière, le décompresseur est très court. Ceux qui veulent jouer la sécurité peuvent se baser sur gzip, mais lzma commence à être de plus en plus présent et même à faire partie des paquets "obligatoires" des grandes distributions (j'ai déjà recensé debian, opensuse, mandriva, slackware, gentoo, arch, fedora, ubuntu). bzip2, lui, est rarement efficace sur des petits fichiers.

      Il y a des gens qui retirent même le shebang du dropper, mais en pratique, je constate que ça pose quand même pas mal de problèmes.
  • # Scène démo

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

    Il faudrait peut être parler du contexte, il y a sûrement des lecteurs qui ne savent pas de quoi tu parles :o)

    On parle de démo, d'intro et de la scène démo :

    - Les démos sur Wikipédia : http://fr.wikipedia.org/wiki/Demomaking
    - La scène sur Wikipédia : http://fr.wikipedia.org/wiki/Sc%C3%A8ne_d%C3%A9mo
    - La vidéo de Second Reality, une démo mythique : http://www.youtube.com/watch?v=8G_aUxbbqWU
    • [^] # Re: Scène démo

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

      Arh, mes 22 ans :-)
      Précisions: cette démo fonctionnait sans problème sur un 486DX2-66 (moins de 30 millions d'instructions par seconde) sur du matériel non accéléré (pas de vidéo accélérée, pas de carte son élaborée, et je crois pas d'utilisation de coprocesseur arithmétique) et sur 2 Mo de mémoire.
      A l'époque, c'était vraiment une tuerie.
      • [^] # Re: Scène démo

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

        Elle avait vraiment marqué les esprits à l'époque.

        Il en existe même une version pour Commodore 64, assez incroyable : [http://www.youtube.com/watch?v=zVPW40ygds4] !
        Par la suite, on a également vu apparaître une version "live", Real Reality: [http://www.youtube.com/watch?v=-Da6e-BjhWM].
        • [^] # Re: Scène démo

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

          Exellent la parodie live :-)

          C'est vrai que c'était typique de l'époque. Tout comme les mecs qui pondaient un tracker en deux jours (les gars de Triton je me souviens, du genre "ouais bon ben les trackers existants ne me vont pas, j'en code un". Hop, deux jours plus tard c'est fait) ou ceux qui voulaient utiliser le mode protégé plus facilement (hop, je fais une bibliothèque, ça a donné heu... je ne me souviens plus du nom, mais utilisé par tous le monde ensuite).
          • [^] # Re: Scène démo

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

            Ca y est, j'ai retrouvé :-)
            C'était Tran qui avait créé PMODE (DOS extender http://en.wikipedia.org/wiki/PMODE ). J'ai retrouvé sa trace car je me suis toujours souvenu de sa superbe démo Timeless (http://www.pouet.net/prod.php?which=2878 ) qui n'a rien de techniquement terrible, mais que je trouve vraiment chouette. Pour un codeur, il se débrouille très bien en graphisme et musique (tout est de lui).

            Et, tadaaaam, Timeless est portée sous Linux ! Et Windows, et d'autres plateformes. C'est vrai que ce type avait l'habitude de fournir son code, ce qui n'était pas courant à l'époque.
            • [^] # Re: Scène démo

              Posté par . Évalué à 4.

              Bon c'est bien beau de remonter aux calendes grecs mais de nos jours, il y a quoi comme démos qui déchire sous nunux ?

              J'ai un peux lâcher l'affaire depuis la fin des études…
              • [^] # Re: Scène démo

                Posté par . Évalué à 2.

                A cette époque, il y avait autant de codeurs pour une démo que dans une équipe de jeu. En gros qq développeurs, voir un gars seul.

                Aujourd'hui la moindre équipe de dev de jeu est composé d'une quinzaine de personne, sans compter les graphistes et autres musiciens.

                De plus les systèmes d'aujourd'hui sont infiniement plus complexe qu'à l'époque et avec l'utilisation du HW 3d tous les rendus se ressemblent.

                Bref, il n'y a plus vraiment de place pour briller avec une démo.

                Mais je suis sûr que l'on pourra me montrer quelques contre exemple.

                "La première sécurité est la liberté"

                • [^] # Re: Scène démo

                  Posté par . Évalué à 2.

                  Il reste toujours le concours de celui qui a la plus petite.
                  Les compétitions de démos de 64Ko voire 8ko ou même 4ko sont stupéfiantes.

                  BeOS le faisait il y a 15 ans !

                  • [^] # Re: Scène démo

                    Posté par . Évalué à 2.

                    Cela a l'intérêt de réduire le travail à faire.

                    Il utilise quoi comme téchnique ? Les shaders ou cela reste du pure ASM x86 ?

                    "La première sécurité est la liberté"

                    • [^] # Re: Scène démo

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

                      >> Cela a l'intérêt de réduire le travail à faire.

                      Faut quand même satisfaire l'ordinateur, eh !
                      C'est pas parce qu'il y a moins de mouvements de bit qu'il faut "travailler moins" là !
                      • [^] # Re: Scène démo

                        Posté par . Évalué à 1.

                        Tu veux me faire croire qu'il y aurait autant de boulot dans une demo 64K que dans une démo avec 1 Mo de binaire ?

                        "La première sécurité est la liberté"

              • [^] # Re: Scène démo

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

                D'après le site [http://www.scene.org], il y toujours des rencontres de demomakers.

                Il y a des démos sous Linux, mais pas les dates : http://www.scene.org/search.php?search=linux&x=0&y=0
  • # .

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

    ne fonctionne que pour x86_64

    Pourquoi ce choix, est-ce parce que le x86-64 est plus dense que le x86-32 ou bien est ce que c'est juste un choix arbitraire ?
    • [^] # Re: .

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

      C'est complètement arbitraire, parce que je n'ai plus de x86-32 sous la main pour tester¹. Et puis, quand on a un peu goûté à l'asm x86-64, on n'a plus trop envie de se replonger dans le 32, si limité en registres :)

      Toute la logique du link est strictement identique en 32 et 64 bits, "seules" les structures de données diffèrent. Il n'est pas du tout exclu que bold supporte un jour le x86-32, voire même d'autres architectures (là je m'avance peut-être un peu, encore que...).

      Certaines parties on un peu été codées à la Rache® et demanderont une réorganisation pour pouvoir gérer le 32 bits facilement.

      Bon, je dois aussi admettre que l'esprit de la Demo, c'est un peu de faire ce que personne n'a fait avant et les intros pour x86_64 sont rares :)

      ¹) Comme je n'utilise pas du tout la libc, il faut faire appel aux syscalls, qui ne sont pas couverts par la couche de compatibilité 32 bits offerte par Linux. Cela dit, le runtime de bold n'en utilise qu'un : SYS_exit.

Suivre le flux des commentaires

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