1 Punkte von GN⁺ 2024-08-24 | 1 Kommentare | Auf WhatsApp teilen
  • Ein LWN-Nutzer hat die verstreuten 20-teiligen Linker-Essays von Ian Lance Taylor als Inhaltsverzeichnis zusammengestellt, damit man sie am Stück verfolgen kann
  • Die Originaltexte stammen von Ian Lance Taylor, dem Autor des gold-Linkers; die primär nummerierten Beiträge wurden anhand von Abschnittsüberschriften so gruppiert, dass sie leichter wiederzufinden sind
  • Der erste Teil behandelt Linker-Konzepte, persönliche Historie, dynamisches Linken, Objektdateiformate, Shared Libraries, ELF-Symbole, Relocations und TLS-Optimierung
  • Der spätere Teil führt weiter über Symbolauflösung, den Vergleich von statischem und dynamischem Linken, Link-Time Optimization, COMDAT, C++-Template-Instanziierung, Exception Frames und inkrementelles Linken
  • Inhaltsverzeichnis und Kommentare sind als Public Domain veröffentlicht und unterliegen keinen Einschränkungen beim Kopieren, Verwenden oder Erstellen abgeleiteter Werke

Ein leicht auffindbares Inhaltsverzeichnis der 20-teiligen Linker-Essayreihe

  • Ian Lance Taylors 20-teilige Linker-Reihe wurde als fortlaufend gut lesbares Inhaltsverzeichnis zusammengestellt
  • Da in Ians Blog oder bei LWN kein gut verlinktes Inhaltsverzeichnis leicht zu finden war, wurde ein eigenes Inhaltsverzeichnis erstellt
  • Die URLs der Beiträge sind fortlaufend nummeriert, aber ein Inhaltsverzeichnis, das die Themen der einzelnen Beiträge auf einen Blick zeigt, ist nützlich
  • Die einzelnen Beiträge werden nur über Nummern bezeichnet; die Titel wurden daher überwiegend aus Ians Abschnittsüberschriften abgeleitet

Enthaltene Beiträge

Veröffentlichungsbedingungen

  • Dieses Inhaltsverzeichnis und die Kommentare sind als Public Domain veröffentlicht
  • Es gibt keine Einschränkungen für Nutzung, Kopieren, Aufführung oder das Erstellen abgeleiteter Werke, und es ist keine zusätzliche Erlaubnis erforderlich

1 Kommentare

 
GN⁺ 2024-08-24
Hacker-News-Kommentare
  • Jemand hat verlinkt, dass das Ganze mit einem Calibre-Rezept zu einem einzigen E-Book gebündelt wurde; für alle, die es brauchen, stelle ich das Ergebnis hier bereit
    https://www.mediafire.com/folder/b8fdqx7eqcpdl/linker
    oder
    https://0x0.st/Xycy.azw3
    https://0x0.st/Xyct.epub
    https://0x0.st/Xycv.mobi
    https://0x0.st/Xycw.pdf

  • Der Entwickler, der an den Linkern lld und mold gearbeitet hat, hat die Performance bis zum Äußersten getrieben
    LLD (Teil von LLVM):
    https://llvm.org/devmtg/2017-10/slides/Ueyama-lld.pdf
    MOLD-Linker:
    https://github.com/rui314/mold/blob/main/docs/design.md
    Auch Apple hat einen neuen Linker veröffentlicht, der auf einem ähnlichen Niveau wie mold liegt; die frühere Diskussion dazu ist hier: https://news.ycombinator.com/item?id=36218330

    • Jedes Mal, wenn ich das sehe, inspiriert es mich dazu, dass das Streben nach Performance kaum je endet
      LLD wurde auf Geschwindigkeit ausgelegt, Gold davor ebenfalls, aber Mold hat beide deutlich übertroffen
  • Auch wenn die Artikel von [2008] sind, sind sie wirklich Gold wert, und ich freue mich immer, wenn sie wieder auf die HN-Startseite kommen

    • Als ich hörte, dass jemand einen Linker-Bug behoben hatte, dachte ich: „Wie schwer kann das schon sein?“ Nach diesem Artikel habe ich meine Meinung geändert
      Wirklich eine hervorragende Erklärung
  • Diese Artikelserie gehört zu meinen Favoriten und hat mir persönlich in vielerlei Hinsicht die Augen geöffnet
    Ich glaube nicht, dass es im Internet oder anderswo eine Quelle gibt, die all diese Informationen an einem Ort versammelt. Ich hätte es großartig gefunden, wenn Ian daraus ein Buch gemacht hätte

    • Das Buch Linkers and Loaders von John R. Levine ist ebenfalls ziemlich gut
    • Ich habe alle 20 Kapitel als PDF ausgedruckt und besitze sie jetzt quasi als persönliches Buch
      Allerdings würde ich mir wünschen, dass Ian eine Version bereitstellt, in der man alle Kapitel auf einer Seite sehen kann
  • https://www.airs.com/blog/archives/51
    Es geht darum, im Assembler-Code Pattern Matching zu betreiben und Sequenzen umzuordnen oder wiederzuverwenden

  • Frühere Kommentarsammlung: https://news.ycombinator.com/item?id=27445981

  • Ich verstehe, warum Linker in Zeiten knappen Speichers entstanden sind
    Aber ich frage mich, ob Linker in Umgebungen mit reichlich Speicher wie modernen Systemen immer noch nötig sind. Außerdem denke ich, dass Shared Libraries doch ein Angriffsweg für Supply-Chain-Angriffe sein können, wie bei dem Anfang des Jahres abgewehrten xz-Angriff

    • Ich weiß, dass Dinge wie flatpak oder Docker im Trend liegen, aber trotzdem möchte ich nicht, dass für jede ausgeführte GUI-App 30 Gtk-Instanzen laufen
      Umgebungen wie der Raspberry Pi müssen weiterhin berücksichtigt werden. Shared Libraries sind schwerlich ein gefährlicherer Angriffsweg als die App selbst. Auch wenn man ein statisches Binary herunterlädt, weiß man nicht, was darin steckt, und ich weiß auch nicht, warum alle der Hälfte der Docker-Images vertrauen, die sie herunterladen und verwenden, aber so wird es nun einmal gemacht
    • Entweder muss der Compiler das gesamte Programm auf einmal sehen, oder es braucht eine Methode, die Ergebnisse mehrerer Kompilierungsschritte zusammenzuführen
      Solange nicht alle Quelldateien gleichzeitig und mit exakt denselben Build-Optionen verarbeitet werden, müssen die Ergebnisse zusammengeführt werden. Selbst mit modernem LTO sieht der Compiler normalerweise nicht alle Dateien eines Programms auf Quellcodeebene, und C-Libraries und C++-Libraries sind meist getrennt. Solange mehrere Sprachen nicht das gesamte Programm in einem einzigen Kompilier- und Assembly-Schritt erzeugen, braucht man etwas, das die Ergebnisse zusammenführt, und das ist der Linker. Selbst wenn alles statisch gebaut wird, verschwindet die Notwendigkeit eines Runtime-Linkers nicht, solange man nicht die exakten Adressen, an denen das Programm laufen wird, hart kodiert; ein solcher Ansatz kollidiert mit Sicherheitsmechanismen wie ASLR
    • Auch statisches Linken ist weiterhin Linken, und um mehrere Objektdateien zu einer ausführbaren Datei zusammenzuführen, braucht man einen Linker
      Die Denkweise, dass Speicher und CPU reichlich vorhanden seien, ist meiner Ansicht nach einer der Gründe, warum die User Experience trotz um mehrere Größenordnungen schnellerer Hardware nicht merklich besser geworden ist
    • Der plötzliche Speicherüberfluss moderner Systeme wurde von Sandboxes, Paketierern, Libraries und Frameworks vollständig eingeholt und aufgebraucht
    • Wenn man möchte, dass ein Build nach der Änderung nur einer Codezeile innerhalb von 30 Minuten fertig wird, braucht man etwas Linker-Ähnliches, das mit kompiliertem Code in kleineren Einheiten als dem Gesamtprogramm umgehen kann