1 points par GN⁺ 2024-08-24 | 1 commentaires | Partager sur WhatsApp
  • Un utilisateur de LWN a organisé en table des matières les 20 essais sur l’éditeur de liens de Ian Lance Taylor, jusque-là dispersés, afin de pouvoir les suivre d’un seul tenant
  • Le texte original est de Ian Lance Taylor, auteur de l’éditeur de liens gold, et regroupe des billets numérotés pour les rendre plus faciles à retrouver à partir de titres de section
  • La première partie couvre le concept d’éditeur de liens, son parcours personnel, la liaison dynamique, les formats de fichiers objets, les bibliothèques partagées, les symboles ELF, les relocalisations et l’optimisation TLS
  • La seconde partie aborde la résolution des symboles, la comparaison entre liaison statique et dynamique, l’optimisation au moment de l’édition de liens, COMDAT, l’instanciation des templates C++, les cadres d’exception et la liaison incrémentale
  • La table des matières et les commentaires sont publiés dans le domaine public, sans restriction de copie, d’usage ou de travaux dérivés

Table des matières regroupant les 20 essais sur l’éditeur de liens pour en faciliter la lecture

  • Les 20 articles de Ian Lance Taylor sur l’éditeur de liens sont organisés en table des matières continue et facile à lire
  • Il était difficile de trouver une table des matières bien reliée sur le blog de Ian ou sur LWN, d’où la création de cette table dédiée
  • Les URL des articles suivent une numérotation continue, mais une table des matières est utile pour voir d’un coup d’œil le sujet de chaque billet
  • Chaque article étant désigné uniquement par son numéro, les titres ont été principalement composés à partir des titres de section de Ian

Liste des articles inclus

Conditions de publication

  • Cette table des matières et ces commentaires sont publiés dans le domaine public
  • Il n’existe aucune restriction sur l’utilisation, la copie, l’exécution publique ou la création de travaux dérivés, et aucune autorisation supplémentaire n’est requise

1 commentaires

 
GN⁺ 2024-08-24
Commentaires sur Hacker News
  • Quelqu’un a partagé un lien vers le tout regroupé en un seul ebook via une recette Calibre ; je mets ici le résultat pour ceux que ça intéresse
    https://www.mediafire.com/folder/b8fdqx7eqcpdl/linker
    ou
    https://0x0.st/Xycy.azw3
    https://0x0.st/Xyct.epub
    https://0x0.st/Xycv.mobi
    https://0x0.st/Xycw.pdf

  • Le développeur qui a travaillé sur les linkers lld et mold a poussé les performances à l’extrême
    LLD (qui fait partie de LLVM) :
    https://llvm.org/devmtg/2017-10/slides/Ueyama-lld.pdf
    Linker MOLD :
    https://github.com/rui314/mold/blob/main/docs/design.md
    Apple a aussi présenté un nouveau linker d’un niveau comparable à mold ; la discussion précédente est ici : https://news.ycombinator.com/item?id=36218330

    • Chaque fois que je vois ça, ça me rappelle que la quête de performance ne s’arrête presque jamais
      LLD a été conçu pour être rapide, et Gold avant lui aussi, mais Mold les a largement dépassés tous les deux
  • Même si l’article date de [2008], ces textes sont de véritables pépites, et c’est toujours un plaisir de les revoir en première page de HN

    • Quand j’ai entendu parler de quelqu’un qui avait corrigé un bug de linker, je me suis dit « à quel point ça peut être difficile ? », puis j’ai lu cet article et j’ai changé d’avis
      C’est vraiment une excellente explication
  • Cette série d’articles fait partie de mes préférées, et elle m’a personnellement ouvert les yeux sur beaucoup de choses
    Je ne pense pas qu’il existe, sur Internet ou ailleurs, une ressource qui rassemble toutes ces informations au même endroit. J’aurais vraiment aimé qu’Ian en fasse un livre

    • Le livre Linkers and Loaders de John R. Levine est aussi plutôt bon
    • J’ai imprimé les 20 chapitres en PDF et je les ai maintenant comme un livre personnel
      J’aimerais toutefois qu’Ian propose une version permettant de consulter tous les chapitres sur une seule page
  • https://www.airs.com/blog/archives/51
    Il y est question de pattern matching dans du code assembleur, et de réagencer ou réutiliser des séquences

  • Recueil de commentaires précédents : https://news.ycombinator.com/item?id=27445981

  • Je comprends pourquoi les linkers sont apparus à une époque où la mémoire était limitée
    Mais je me demande s’ils sont encore nécessaires dans des environnements comme les systèmes modernes, où la mémoire est abondante. En plus, les bibliothèques partagées me semblent être une voie d’attaque sur la chaîne d’approvisionnement, comme l’attaque xz bloquée plus tôt cette année

    • Je sais que l’usage de choses comme flatpak ou Docker est à la mode, mais je n’ai pas envie de me retrouver avec 30 instances de Gtk pour chaque appli GUI que je lance
      Il faut aussi continuer à penser à des environnements comme le Raspberry Pi. Il est difficile de considérer les bibliothèques partagées comme un vecteur d’attaque plus dangereux que l’application elle-même. Si l’on télécharge un binaire statique, on ne sait pas non plus ce qu’il contient ; et je ne sais pas pourquoi tout le monde fait confiance à la moitié des images Docker téléchargées et utilisées, mais c’est pourtant ce qui se fait
    • Soit le compilateur doit voir tout le programme d’un coup, soit il faut une méthode pour combiner les résultats de plusieurs étapes de compilation
      À moins de traiter tous les fichiers source simultanément, avec exactement les mêmes options de build, il faut combiner les artefacts produits. Même avec le LTO moderne, le compilateur ne voit généralement pas tous les fichiers du programme au niveau du code source, et les bibliothèques C et C++ sont le plus souvent séparées. Tant que plusieurs langages ne produisent pas tout le programme en une seule étape de compilation et d’assemblage, il faut quelque chose pour assembler les résultats, et c’est le rôle du linker. Même si tout est compilé statiquement, la nécessité d’un linker à l’exécution ne disparaît pas, sauf à coder en dur l’adresse exacte à laquelle le programme s’exécutera ; une approche qui entre en conflit avec des mécanismes de sécurité comme l’ASLR
    • Le linking statique reste du linking, et il faut un linker pour combiner plusieurs fichiers objet en un seul exécutable
      L’idée selon laquelle la mémoire et le CPU sont abondants est, à mon avis, l’une des raisons pour lesquelles l’expérience utilisateur ne s’est pas nettement améliorée alors que le matériel est devenu plus rapide de plusieurs ordres de grandeur
    • L’abondance soudaine de mémoire dans les systèmes modernes a été entièrement absorbée par les sandbox, les packagers, les bibliothèques et les frameworks
    • Si l’on veut qu’un build après modification d’une seule ligne de code se termine en moins de 30 minutes, il faut quelque chose qui ressemble à un linker pour traiter du code compilé à une granularité plus fine que le programme entier