Uma biblioteca compartilhada não precisa ser realocável. A AT & T usou bibliotecas compartilhadas não relocáveis no SYSvr3 por volta de 1987.
O método usado pelo AT & T foi baseado em endereços fixos no lib compartilhado e o lib compartilhado foi instalado na memória do sistema (utilizável por qualquer processo) por uma ferramenta de sistema especial na inicialização. Os programas que usaram essas bibliotecas foram vinculados aos endereços fixos usados no momento da instalação. Esse método é muito limitado, pois há uma necessidade de um administrador global que define endereços de carga para várias bibliotecas.
O método usado hoje é baseado em pesquisa da Sun Microsystems em 1987 e publicado em dezembro de 1987.
Ele é baseado no recurso mmap()
no kernel. Cada programa contém código de inicialização especial que mapeia as bibliotecas necessárias que usam código relocável.
Cada biblioteca contém uma tabela especial que contém deslocamentos para vários símbolos na biblioteca. Cada programa contém uma tabela com nomes de funções e o binário faz uma sub-rotina de salto para a entrada da tabela relacionada a todas as funções necessárias.
Essa entrada da tabela contém uma instrução de salto para o código do vinculador de tempo de execução e, quando usada pela primeira vez, o vinculador de tempo de execução substitui esse salto por um salto para a função na biblioteca compartilhada.
Tudo isso é feito pelo software do sistema e não está sujeito ao design do programa do usuário.
BTW: o livro afirma que nenhum programa pode se tornar maior que a memória física. Isso foi verdade na década de 1960. A IBM mudou isso no início dos anos 70 para seus mainframes e o BSD mudou isso em 1979 para o UNIX com gerenciamento de memória virtual.
dlopen()
pode ser usado para carregar bibliotecas dinâmicas "manualmente" em tempo de execução e, portanto, permite que isso dependa do que aconteceu antes. Um programa de reprodução de som pode, e. decida usar dlopen
para carregar um decodificador mp3
depois que ele descobrir que um argumento de arquivo se refere a um arquivo de som que usa mp3
encoding.
Se você usar dlopen
, a vinculação a funções na biblioteca compartilhada carregada não ocorrerá automaticamente. Você precisa usar dlsym()
para obter o endereço do nome da função e, em seguida, chamar a função por um desreferenciamento de ponteiro.
Não é possível usar o arquivo dlopen
a .o
, pois é necessário ter o _PROCEDURE_LINKAGE_TABLE_
e isso é criado pelo processo especial de vinculação necessário para criar um arquivo .so.
.
O método usado pela Microsoft é derivado do método manual que é baseado em dlopen
. No entanto, a Microsoft cria automaticamente um código que funciona da maneira que você faz manualmente com dlopen
. O código relacionado está dentro da biblioteca estática com o mesmo nome que o chamado dll
. Esta biblioteca estática é vinculada estaticamente ao programa e contém o código trmapolina que carrega a biblioteca, recupera o endereço da função e chama o ponteiro de função.
O compilador da Microsoft sempre cria um código relocável, portanto, mesmo bibliotecas totalmente estáticas compiladas com esse compilador usam código relocável.
A alegação de que uma rotina não é carregada até que seja referenciada está errada no caso geral, ela só se aplica ao caso dlopen
.
Libraries managed by the ELF runtime system may be listed via
ldd
, libraries managed manally bydlopen
cannot be listed since their names may be a result of run time string processing.