Journal Bold: un linker particulier

Posté par  (site web personnel) .
Étiquettes : aucune
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  . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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…

  • # .

    Posté par  (site web personnel) . É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  (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.