Comment le linker / chargeur dynamique lui-même peut-il être lié dynamiquement comme indiqué par `file`?

Considérez les dépendances des objets partagés de /bin/bash, qui incluent /lib64/ld-linux-x86-64.so.2(éditeur de liens dynamique / chargeur):

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)

L'inspection /lib64/ld-linux-x86-64.so.2montre qu'il s'agit d'un lien symbolique vers /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

De plus, les filerapports /lib/x86_64-linux-gnu/ld-2.28.soà eux-mêmes sont liés dynamiquement:

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

J'aimerais savoir:

1. Comment le linker / loader ( /lib64/ld-linux-x86-64.so.2) dynamiquement peut-il être lui-même lié dynamiquement? Se lie-t-il au moment de l'exécution?
2. /lib/x86_64-linux-gnu/ld-2.28.soest documenté pour gérer a.out binaries ( man ld.so), mais /bin/bashest un exécutable ELF?

Le programme ld.so gère les binaires a.out, un format utilisé il y a longtemps; ld-linux.so * (/lib/ld-linux.so.1 pour libc5, /lib/ld-linux.so.2 pour glibc2) gère ELF, que tout le monde utilise depuis des années.

1. Oui, il se lie lorsqu'il s'initialise. Techniquement, l'éditeur de liens dynamique n'a pas besoin de résolution d'objet et de relocalisation pour lui-même, car il est entièrement résolu tel quel, mais il définit des symboles et il doit en prendre soin lors de la résolution du binaire, il est "interprété", et ces symboles sont mis à jour pour pointer vers leurs implémentations dans les bibliothèques chargées. En particulier, cela affecte malloc- l'éditeur de liens a une version minimale intégrée, avec le symbole correspondant, mais qui est remplacée par la version de la bibliothèque C une fois qu'elle est chargée et déplacée (ou même par une version interposée s'il y en a une), avec quelque soin prises pour s'assurer que cela ne se produit pas à un point où il pourrait briser l'éditeur de liens.

   Les détails sanglants sont dans rtld.c, dans la dl_mainfonction.

   Notez cependant qu'il ld.son'a pas de dépendances externes. Vous pouvez voir les symboles impliqués dans nm -D; aucun d'eux n'est indéfini.

2. La page de manuel se réfère uniquement aux entrées directement sous /lib, c'est -à- dire/lib/ld.so (l'éditeur de liens dynamique libc 5, qui prend en charge a.out) et /lib*/ld-linux*.so*(l'éditeur de liens dynamique libc 6, qui prend en charge ELF). La page de manuel est très spécifique et ld.sone l'est pas ld-2.28.so.

   L'éditeur de liens dynamique trouvé sur la grande majorité des systèmes actuels n'inclut pas de a.outsupport.

fileet lddsignaler des choses différentes pour l'éditeur de liens dynamique, car ils ont des définitions différentes de ce qui constitue un binaire lié statiquement. Car ldd, un binaire est lié statiquement s'il n'a pas de DT_NEEDEDsymboles, c'est-à - dire pas de symboles non définis. Pour file, un binaire ELF est lié statiquement s'il n'a pas de PT_DYNAMICsection (cela changera dans la version file5.37 suivante; il utilisePT_INTERP maintenant la présence d'une section comme indicateur d'un binaire lié dynamiquement, qui correspond au commentaire dans le code).

L'éditeur de liens dynamique de bibliothèque GNU C n'a pas de DT_NEEDEDsymboles, mais il a une PT_DYNAMICsection (car il s'agit techniquement d'une bibliothèque partagée). Par conséquent, ldd(qui est l'éditeur de liens dynamique) indique qu'il est lié statiquement, mais fileindique qu'il est lié dynamiquement. Il n'a pas de PT_INTERPsection, donc la prochaine version de fileindiquera également qu'il est lié statiquement.

$ 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

(avec 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

(avec la version en cours de développement de file).

1. Je soupçonne que le fileprogramme a tort au sujet du lieur / chargeur dynamique étant lui-même lié dynamiquement. Le lddprogramme n'est pas d'accord. Du moins pas sur mon système (Debian Stretch):

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

2. man ld.solit également: "ld-linux.so * gère ELF" . Sur votre système (et le mien d'ailleurs), les deux sont des liens symboliques vers le même binaire que je déduis capable de gérer à la fois ELF et le (ancien obsolète) format a.out.