goblin
Motivierter Amateur
Webseiten kenne ich leider keine besoders guten. Das Buch ist in Ordnung, aber wirklich alt, und der Fokus liegt stark auf der Implementierung. Wenn du keinen eigenen Linker bauen möchtest, oder wirklich die kompletten Interna nachollziehen willst, dann würde ich es mir nochmal überlegen, da ein Großteil der Sachen so extrem platformabhängig ist. Außerdem kommen ARM und MIPS garnicht vor, als RISC Instruction Set ist dafür SPARC vertreten. Ebenso ist amd64 außen vor, da es das damals erst gerade konzipiert wurde. Die behandelten Architekturen sind IBM 370, SPARC und x86. An Ausführungsformaten werden DOS COM (weil es so einfach ist), Unix a.out, COFF & ELF, Microsoft PE, IBM 360 und Intel OMF vorgestellt. Soweit ich informiert bin ist da auch alles tot bis auf ELF und PE.
Viele der Zusammenhänge sind durchaus interessant, aber da es eben an Autoren von Linkersoftware gerichtet ist geht es echt in die Details, wie Relocations usw. implementiert werden. Und da die Terminologie von Plattform zu Plattform variiert (Segmente: Speichersegmente der x86-Hardware, oder die Code-/Daten/...-Segmente des ELF-Formats? ELF auf x86? Argh!) ist es teilweise auch ziemlich verwirrend. Daher denke ich dass für Leute, die eher an konkreten Implementierungen (wie ELF auf FreeBSD) interessiert sind, andere Ressourcen interessanter sind, am ehesten die Linker-Doku[url], oder auch das [url=https://en.wikipedia.org/wiki/Executable_and_Linkable_Format]ELF Format.
Ich hab mir das Buch deshalb gekauft, weil ich sehr am Compilerbau interessiert bin. Ich hab es zwar immer noch nicht geschafft, mich am clang/LLVM-Projekt zu involvieren, aber das Thema fasziniert mich schon lange. Und wenn man in den Windows-Headern rumwühlt, dann findet man da so komische Dinge wie `__near` und `__far`, das wurde mir in Linkers & Loaders bisher mit am besten erklärt.
Das ist im Übrigen auch ein super Beispiel dafür, dass es in C "Die reine Lehre" garnicht gibt, weil der Standard auf einer abstrakten Maschine definiert wurde. Wirkliche Hardware hat eben auch Dinge wie Speichersegmente und um sowas abzubilden muss die Sprache dann vom Compiler-Hersteller erweitert werden.
Schlussendlich hat das Thema Linken auch eine emotionale Seite, heutzutage ist dynamisches Linken zwar quasi allgemein Anerkannt, aber gerade in den Anfangszeiten gab es viel Kritik an der zusätzlichen Komplexität und den damals noch relativ hohen Laufzeitkosten. Plan 9 hat es aus vielen Gründen nie geschafft, den Mainstream zu erreichen, aber die Entwickler waren vehemente Gegner von dynamischem Linken, was man heute wieder an der Programmiersprache Go sehen kann, die von vielen Ex-Plan 9 Entwicklern konzipiert wurde. Rob Pike hasst dynamisches Linken bis heute, wobei er dynamisches Laden akzeptiert, was aber auf FreeBSD nicht so gerne gesehen ist, wie wir in diesem Thread erfahren haben. In der GNU Welt wurde statisches Linken vom libc-Maintainer Ulrich Drepper verteufelt und technisch nahezu unmöglich gemacht, was zu einer Flut von Alternativimplementierungen auf GNU libc basierten Systemen (a.k.a. Linux) geführt hat, da es doch noch viele Anwendungsfälle für statisch gelinkte Programmdateien gibt (embedded Systeme, Rettungssysteme, ...). Als kleine Anekdote: Vor FreeBSD bin ich sehr viel in der suckless Community rumgehangen, wo statisches Linken auch bevorzugt wird. Kleine Programme sind statisch gegen die musl libc gelinkt kleiner als dynamisch gegen die GNU libc. Das hat zur Folge, dass sie Programme schneller von der Platte eingelesen sind, keine Symbole zur Laufzeit eingelesen werden müssen und evtl. entsprechende Bibliotheken eingelesen werden müssen usw., das führt vor allem auf alten Systemen zu einer unglaublichen Responsivität.[/url]
Viele der Zusammenhänge sind durchaus interessant, aber da es eben an Autoren von Linkersoftware gerichtet ist geht es echt in die Details, wie Relocations usw. implementiert werden. Und da die Terminologie von Plattform zu Plattform variiert (Segmente: Speichersegmente der x86-Hardware, oder die Code-/Daten/...-Segmente des ELF-Formats? ELF auf x86? Argh!) ist es teilweise auch ziemlich verwirrend. Daher denke ich dass für Leute, die eher an konkreten Implementierungen (wie ELF auf FreeBSD) interessiert sind, andere Ressourcen interessanter sind, am ehesten die Linker-Doku[url], oder auch das [url=https://en.wikipedia.org/wiki/Executable_and_Linkable_Format]ELF Format.
Ich hab mir das Buch deshalb gekauft, weil ich sehr am Compilerbau interessiert bin. Ich hab es zwar immer noch nicht geschafft, mich am clang/LLVM-Projekt zu involvieren, aber das Thema fasziniert mich schon lange. Und wenn man in den Windows-Headern rumwühlt, dann findet man da so komische Dinge wie `__near` und `__far`, das wurde mir in Linkers & Loaders bisher mit am besten erklärt.
Das ist im Übrigen auch ein super Beispiel dafür, dass es in C "Die reine Lehre" garnicht gibt, weil der Standard auf einer abstrakten Maschine definiert wurde. Wirkliche Hardware hat eben auch Dinge wie Speichersegmente und um sowas abzubilden muss die Sprache dann vom Compiler-Hersteller erweitert werden.
Schlussendlich hat das Thema Linken auch eine emotionale Seite, heutzutage ist dynamisches Linken zwar quasi allgemein Anerkannt, aber gerade in den Anfangszeiten gab es viel Kritik an der zusätzlichen Komplexität und den damals noch relativ hohen Laufzeitkosten. Plan 9 hat es aus vielen Gründen nie geschafft, den Mainstream zu erreichen, aber die Entwickler waren vehemente Gegner von dynamischem Linken, was man heute wieder an der Programmiersprache Go sehen kann, die von vielen Ex-Plan 9 Entwicklern konzipiert wurde. Rob Pike hasst dynamisches Linken bis heute, wobei er dynamisches Laden akzeptiert, was aber auf FreeBSD nicht so gerne gesehen ist, wie wir in diesem Thread erfahren haben. In der GNU Welt wurde statisches Linken vom libc-Maintainer Ulrich Drepper verteufelt und technisch nahezu unmöglich gemacht, was zu einer Flut von Alternativimplementierungen auf GNU libc basierten Systemen (a.k.a. Linux) geführt hat, da es doch noch viele Anwendungsfälle für statisch gelinkte Programmdateien gibt (embedded Systeme, Rettungssysteme, ...). Als kleine Anekdote: Vor FreeBSD bin ich sehr viel in der suckless Community rumgehangen, wo statisches Linken auch bevorzugt wird. Kleine Programme sind statisch gegen die musl libc gelinkt kleiner als dynamisch gegen die GNU libc. Das hat zur Folge, dass sie Programme schneller von der Platte eingelesen sind, keine Symbole zur Laufzeit eingelesen werden müssen und evtl. entsprechende Bibliotheken eingelesen werden müssen usw., das führt vor allem auf alten Systemen zu einer unglaublichen Responsivität.[/url]