Wie kann der Dynamic Linker / Loader selbst dynamisch verknüpft werden, wie von "file" gemeldet?

Betrachten wir die gemeinsame Objekt Abhängigkeiten /bin/bash, die umfaßt /lib64/ld-linux-x86-64.so.2(dynamische Linker / loader):

ldd /bin/bash
    linux-vdso.so.1 (0x00007fffd0887000)
    libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f57a04e3000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f57a04de000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f57a031d000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f57a0652000)

Inspektion /lib64/ld-linux-x86-64.so.2zeigt, dass es sich um einen Symlink handelt zu /lib/x86_64-linux-gnu/ld-2.28.so:

ls -la /lib64/ld-linux-x86-64.so.2 
lrwxrwxrwx 1 root root 32 May  1 19:24 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.28.so

Darüber hinaus können fileBerichte /lib/x86_64-linux-gnu/ld-2.28.sodynamisch mit sich selbst verknüpft werden:

file -L /lib64/ld-linux-x86-64.so.2
/lib64/ld-linux-x86-64.so.2: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=f25dfd7b95be4ba386fd71080accae8c0732b711, stripped

Ich würde gerne wissen:

1. Wie kann der Dynamic Linker / Loader ( /lib64/ld-linux-x86-64.so.2) selbst dynamisch verknüpft werden? Verbindet es sich zur Laufzeit selbst?
2. /lib/x86_64-linux-gnu/ld-2.28.soist dokumentiert, um mit a.out binaries ( man ld.so) umzugehen , aber /bin/bashist ein ELF ausführbar?

Das Programm ld.so verarbeitet alle Binärdateien, ein Format, das vor langer Zeit verwendet wurde. ld-linux.so * (/lib/ld-linux.so.1 für libc5, /lib/ld-linux.so.2 für glibc2) behandelt ELF, das seit Jahren von allen verwendet wird.

1. Ja, es verbindet sich selbst, wenn es initialisiert wird. Technisch gesehen benötigt der dynamische Linker keine Objektauflösung und -verschiebung für sich selbst, da er so wie er ist vollständig aufgelöst ist, aber er definiert Symbole und muss sich beim Auflösen der Binärdatei, die er „interpretiert“, um diejenigen kümmern, und diese Symbole werden aktualisiert auf ihre Implementierungen in den geladenen Bibliotheken zu verweisen. Dies betrifft insbesondere Folgendes malloc: Der Linker verfügt über eine integrierte Minimalversion mit dem entsprechenden Symbol, die jedoch mit einiger Sorgfalt durch die Version der C-Bibliothek ersetzt wird, sobald sie geladen und verschoben wurde (oder sogar durch eine zwischengeschaltete Version, falls vorhanden) Es wurde darauf geachtet, dass dies nicht an einem Punkt geschieht, an dem der Linker möglicherweise beschädigt wird.

   Die blutigen Details sind rtld.cin der dl_mainFunktion.

   Beachten Sie jedoch, dass ld.soes keine externen Abhängigkeiten gibt. Sie können die Symbole sehen, mit denen es zu tun hat nm -D; Keiner von ihnen ist undefiniert.

2. Die Hilfeseite bezieht sich nur auf Einträge direkt unter /lib, dh /lib/ld.so (die libc 5 Linkers, der Träger a.out) und /lib*/ld-linux*.so*(die libc 6 Linkers, der ELF unterstützt). Die Manpage ist sehr spezifisch und ld.sonicht ld-2.28.so.

   Der dynamische Linker, der auf den meisten aktuellen Systemen zu finden ist, bietet keine a.outUnterstützung.

fileund lddberichten verschiedene Dinge für den dynamischen Linker, weil sie unterschiedliche Definitionen dessen haben, was eine statisch verknüpfte Binärdatei ausmacht. Denn lddeine Binärdatei ist statisch verknüpft, wenn sie keine DT_NEEDEDSymbole enthält, dh keine undefinierten Symbole. Denn fileeine ELF-Binärdatei ist statisch verknüpft, wenn sie keinen PT_DYNAMICAbschnitt enthält (dies wird sich in der Version filenach 5.37 ändern ; sie verwendet jetzt das Vorhandensein eines PT_INTERPAbschnitts als Indikator für eine dynamisch verknüpfte Binärdatei, die mit dem Kommentar in übereinstimmt der Code).

Der dynamische Linker der GNU C-Bibliothek enthält keine DT_NEEDEDSymbole, aber einen PT_DYNAMICAbschnitt (da es sich technisch gesehen um eine gemeinsam genutzte Bibliothek handelt). Infolgedessen gibt ldd(dies ist der dynamische Linker) an, dass er statisch verknüpft ist, zeigt jedoch filean, dass er dynamisch verknüpft ist. Es gibt keinen PT_INTERPAbschnitt, daher wird in der nächsten Version von fileauch angegeben, dass es statisch verknüpft ist.

$ ldd /lib64/ld-linux-x86-64.so.2
        statically linked

$ file $(readlink /lib64/ld-linux-x86-64.so.2)
/lib/x86_64-linux-gnu/ld-2.28.so: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=f25dfd7b95be4ba386fd71080accae8c0732b711, stripped

(mit file5,35)

$ file $(readlink /lib64/ld-linux-x86-64.so.2)
/lib/x86_64-linux-gnu/ld-2.28.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=f25dfd7b95be4ba386fd71080accae8c0732b711, stripped

(mit der aktuell in Entwicklung befindlichen Version von file).

1. Ich vermute, das fileProgramm ist falsch, weil der Dynamic Linker / Loader selbst dynamisch verlinkt ist. Das lddProgramm stimmt nicht überein. Zumindest nicht auf meinem System (Debian Stretch):

   ldd /lib/x86_64-linux-gnu/ld-2.24.so
       statically linked
   

2. man ld.soliest auch: "ld-linux.so * behandelt ELF" . Auf Ihrem System (und übrigens auch auf meinem) sind beide Symlinks zu derselben Binärdatei, die meiner Meinung nach sowohl ELF als auch das (alte veraltete) a.out-Format verarbeiten kann.