W jaki sposób sam dynamiczny linker / moduł ładujący może być dynamicznie łączony, zgodnie z raportem „file”?

Rozważ zależności obiektu współdzielonego /bin/bash, które obejmują /lib64/ld-linux-x86-64.so.2(dynamiczny linker / moduł ładujący):

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)

Sprawdzanie /lib64/ld-linux-x86-64.so.2pokazuje, że jest to dowiązanie symboliczne do /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

Ponadto same fileraporty /lib/x86_64-linux-gnu/ld-2.28.sosą dynamicznie łączone:

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

Chciałbym wiedzieć:

1. W jaki sposób sam dynamicznie linker / loader ( /lib64/ld-linux-x86-64.so.2) może być dynamicznie powiązany? Czy łączy się w czasie wykonywania?
2. /lib/x86_64-linux-gnu/ld-2.28.sojest udokumentowany do obsługi plików binarnych a.out ( man ld.so), ale /bin/bashczy plik wykonywalny ELF jest wykonywalny?

Program ld.so obsługuje pliki binarne a.out, format używany dawno temu; ld-linux.so * (/lib/ld-linux.so.1 dla libc5, /lib/ld-linux.so.2 dla glibc2) obsługuje ELF, z którego wszyscy korzystają od lat.

1. Tak, łączy się podczas inicjowania. Technicznie rzecz biorąc, dynamiczny linker nie potrzebuje dla siebie rozdzielczości obiektu i przeniesienia, ponieważ jest w pełni rozwiązany w obecnej postaci, ale definiuje symbole i musi się nimi zająć przy rozwiązywaniu pliku binarnego, „interpretuje”, a te symbole są aktualizowane wskazywać na ich implementacje w załadowanych bibliotekach. W szczególności dotyczy to malloc- linker ma wbudowaną minimalną wersję z odpowiednim symbolem, ale jest ona zastępowana wersją biblioteki C po załadowaniu i przeniesieniu (lub nawet wersją pośrednią, jeśli taka istnieje), z pewną ostrożnością podjęte, aby upewnić się, że tak się nie stanie w miejscu, w którym może to spowodować uszkodzenie linkera.

   Krwawe szczegóły są rtld.cw dl_mainfunkcji.

   Zauważ jednak, że ld.sonie ma zewnętrznych zależności. Możesz zobaczyć związane z nimi symbole nm -D; żaden z nich nie jest niezdefiniowany.

2. Strona man odnosi się tylko do pozycji bezpośrednio pod /lib, tj. /lib/ld.so (Dynamiczny linker libc 5, który obsługuje a.out) i /lib*/ld-linux*.so*(dynamiczny linker libc 6, który obsługuje ELF). Strona man jest bardzo konkretna i ld.sonie jest ld-2.28.so.

   Dynamiczny linker znajdowany w zdecydowanej większości obecnych systemów nie obejmuje a.outwsparcia.

filei lddzgłaszają różne rzeczy dla dynamicznego linkera, ponieważ mają różne definicje tego, co stanowi statycznie powiązany plik binarny. Bo lddplik binarny jest statycznie powiązany, jeśli nie ma DT_NEEDEDsymboli, tzn. Nie ma niezdefiniowanych symboli. Na przykład file, plik binarny ELF jest statycznie połączony, jeśli nie ma PT_DYNAMICsekcji (zmieni się to w wersji filenastępnej 5.37; teraz używa obecności PT_INTERPsekcji jako wskaźnika dynamicznie połączonego pliku binarnego, który pasuje do komentarza w kod).

Dynamiczny linker biblioteki GNU C nie ma żadnych DT_NEEDEDsymboli, ale ma PT_DYNAMICsekcję (ponieważ technicznie jest to biblioteka współdzielona). W rezultacie ldd(który jest dynamicznym łącznikiem) wskazuje, że jest statycznie powiązany, ale filewskazuje, że jest dynamicznie powiązany. Nie ma PT_INTERPsekcji, więc kolejne wydanie filebędzie również wskazywać, że jest statycznie powiązane.

$ 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

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

(w aktualnie opracowywanej wersji file).

1. Podejrzewam, że fileprogram nie ma racji, że dynamicznie linker / moduł ładujący jest dynamicznie łączony sam. lddProgram nie zgodzić. Przynajmniej nie w moim systemie (Debian Stretch):

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

2. man ld.soczyta również: „ld-linux.so * obsługuje ELF” . W twoim systemie (a przy okazji także moim) oba są dowiązaniami symbolicznymi do tego samego pliku binarnego, który, jak dedukuję, jest w stanie obsłużyć zarówno ELF, jak i (stary, przestarzały) format a.out.