Início / unix / Perguntas / 543205
Accepted
Shuzheng
Asked: 2019-09-24 03:55:08 +0800 CST

Como o próprio vinculador/carregador dinâmico pode ser vinculado dinamicamente conforme relatado por `file`?

  • 772

Considere as dependências de objetos compartilhados de /bin/bash, que incluem /lib64/ld-linux-x86-64.so.2(ligador/carregador dinâmico):

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)

A inspeção /lib64/ld-linux-x86-64.so.2mostra que é um link simbólico para /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

Além disso, os próprios filerelatórios /lib/x86_64-linux-gnu/ld-2.28.sosão vinculados dinamicamente:

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

Eu gostaria de saber:

  1. Como o próprio vinculador/carregador dinamicamente ( /lib64/ld-linux-x86-64.so.2) pode ser vinculado dinamicamente? Ele se conecta em tempo de execução?
  2. /lib/x86_64-linux-gnu/ld-2.28.soestá documentado para lidar com binários a.out ( man ld.so), mas /bin/bashum ELF é executável?

O programa ld.so lida com binários a.out, um formato usado há muito tempo; ld-linux.so* (/lib/ld-linux.so.1 para libc5, /lib/ld-linux.so.2 para glibc2) lida com ELF, que todo mundo vem usando há anos.

linux

2 respostas

  1. Best Answer

    1. Sim, ele se liga quando inicializa. Tecnicamente, o vinculador dinâmico não precisa de resolução e realocação de objetos para si mesmo, pois é totalmente resolvido como está, mas define símbolos e precisa cuidar deles ao resolver o binário que está “interpretando”, e esses símbolos são atualizados para apontar para suas implementações nas bibliotecas carregadas. Em particular, isso afeta malloc— o linker tem uma versão mínima integrada, com o símbolo correspondente, mas é substituída pela versão da biblioteca C assim que ela é carregada e realocada (ou mesmo por uma versão interposta, se houver), com alguns cuidados tomadas para garantir que isso não aconteça em um ponto em que possa quebrar o vinculador.

      Os detalhes sangrentos estão em rtld.c, na dl_mainfunção.

      Observe, no entanto, que ld.sonão possui dependências externas. Você pode ver os símbolos envolvidos com nm -D; nenhum deles é indefinido.

    2. A página de manual refere-se apenas a entradas diretamente sob /lib, ou seja /lib/ld.so (o vinculador dinâmico libc 5, que suporta a.out) e /lib*/ld-linux*.so*(o vinculador dinâmico libc 6, que suporta ELF). A página de manual é muito específica e ld.sonão é ld-2.28.so.

      O vinculador dinâmico encontrado na grande maioria dos sistemas atuais não inclui a.outsuporte.

    filee lddrelatar coisas diferentes para o vinculador dinâmico porque eles têm definições diferentes do que constitui um binário vinculado estaticamente. Para ldd, um binário é vinculado estaticamente se não tiver DT_NEEDEDsímbolos, ou seja , nenhum símbolo indefinido. Para file, um binário ELF é vinculado estaticamente se não tiver uma PT_DYNAMICseção (isso mudará na versão file5.37 seguinte; agora ele usa a presença de uma PT_INTERPseção como indicador de um binário vinculado dinamicamente, que corresponde ao comentário em o código).

    O vinculador dinâmico da biblioteca GNU C não possui nenhum DT_NEEDEDsímbolo, mas possui uma PT_DYNAMICseção (já que é tecnicamente uma biblioteca compartilhada). Como resultado, ldd(que é o vinculador dinâmico) indica que está vinculado estaticamente, mas fileindica que está vinculado dinamicamente. Ele não tem uma PT_INTERPseção, então a próxima versão do filetambém indicará que ele está vinculado estaticamente.

    $ 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

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

    (com a versão atualmente em desenvolvimento do file).

    • 21

    1. Eu suspeito que o fileprograma está errado sobre o vinculador/carregador dinamicamente sendo vinculado dinamicamente. O lddprograma não concorda. Pelo menos não no meu sistema (Debian Stretch):

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

    2. man ld.sotambém lê: "ld-linux.so* manipula ELF" . No seu sistema (e no meu também) ambos são links simbólicos para o mesmo binário que eu deduzo que é capaz de lidar com o formato ELF e o (antigo obsoleto) a.out.

    • 0

relate perguntas