vendredi 30 juillet
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de allergy :

Journal : Bold: un linker particulier

Posté par Amand Tihon (page perso, ) le 09 août 2009
26
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

> Lire le journal (18 commentaires, moyenne: 4,7).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Intéressant

Posté par Damien Thébault (Jabber id, page perso, ) le 09/08/2009 à 01:30. (lien). É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 Amand Tihon (page perso, ) le 09/08/2009 à 11:02. (lien). É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 Frédéric Massot (page perso, ) le 09/08/2009 à 11:29. (lien). É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 Kerro () le 09/08/2009 à 13:20. (lien). É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 Amand Tihon (page perso, ) le 09/08/2009 à 14:23. (lien). É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 Kerro () le 09/08/2009 à 17:20. (lien). É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 Kerro () le 09/08/2009 à 17:37. (lien). É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 goofy () le 10/08/2009 à 04:10. (lien). É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 Nicolas Boulay () le 10/08/2009 à 09:41. (lien). É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.

              --
              "Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."

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

                Posté par Aurélien Girard () le 10/08/2009 à 10:30. (lien). É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 10 ans.

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

                  Posté par Nicolas Boulay () le 10/08/2009 à 11:14. (lien). É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 ?

                  --
                  "Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."

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

                    Posté par Axioplase ıɥs∀ (page perso, ) le 12/08/2009 à 08:04. (lien). É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à !

                    --
                    Je ne suis pas toujours de mon avis.

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

                      Posté par Nicolas Boulay () le 12/08/2009 à 09:15. (lien). É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 ?

                      --
                      "Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."

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

                        Posté par Axioplase ıɥs∀ (page perso, ) le 12/08/2009 à 10:36. (lien). Évalué à 3.

                        C'était pas *exactement* mon message.
                        Relis à haute voix le message à qui tu répondais, le tien, le mien.

                        --
                        Je ne suis pas toujours de mon avis.

.

Posté par Troy McClure (page perso, ) le 09/08/2009 à 11:57. (lien). É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 Amand Tihon (page perso, ) le 09/08/2009 à 12:27. (lien). É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.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.092s (dont 0.008 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !