Que tipos de arquivos podem ser carregados dinamicamente?

0

Conceitos do Sistema Operacional, por Silberschatz A., Galvin P.B., Gagne G. - Operating System Concepts, 9ª Edição - 2012 diz

8.1.4 Dynamic Loading

In our discussion so far, it has been necessary for the entire program and all data of a process to be in physical memory for the process to execute. The size of a process has thus been limited to the size of physical memory. To obtain better memory-space utilization, we can use dynamic loading. With dynamic loading, a routine is not loaded until it is called. All routines are kept on disk in a relocatable load format. The main program is loaded into memory and is executed. When a routine needs to call another routine, the calling routine first checks to see whether the other routine has been loaded. If it has not, the relocatable linking loader is called to load the desired routine into memory and to update the program’s address tables to reflect this change. Then control is passed to the newly loaded routine.

The advantage of dynamic loading is that a routine is loaded only when it is needed. This method is particularly useful when large amounts of code are needed to handle infrequently occurring cases, such as error routines. In this case, although the total program size may be large, the portion that is used (and hence loaded) may be much smaller.

Dynamic loading does not require special support from the operating system. It is the responsibility of the users to design their programs to take advantage of such a method. Operating systems may help the programmer, however, by providing library routines to implement dynamic loading.

8.1.5 Dynamic Linking and Shared Libraries

Quais tipos de arquivos têm "um formato de carga relocável" no Linux,

  • um arquivo executável ELF,
  • um arquivo de biblioteca compartilhada .so,
  • um módulo do kernel,
  • arquivos de objeto .o?

Todos eles podem ser carregados dinamicamente?

O "formato de carga relocável" na citação significa .o arquivo de objeto, um módulo de kernel, mas não o arquivo de biblioteca compartilhada .so, de acordo com:

O livro não menciona nada ainda sobre a biblioteca compartilhada até a Seção 8.1.5, então a Seção 8.1.4 me parece que o carregamento dinâmico não está necessariamente carregando uma biblioteca compartilhada em um programa do usuário, mas pode carregar outra coisa. Isso é verdade?

O último parágrafo da seção 8.1.4 parece dizer que os programadores precisam executar o carregamento dinâmico explicitamente. Refere-se a dlopen() ? Que tipos de arquivos ELF podem aceitar dlopen() como seu primeiro argumento, uma biblioteca compartilhada .so, um arquivo objeto .o, um módulo do kernel, um arquivo ELF executável?

Obrigado.

    
por Tim 17.10.2018 / 19:49

1 resposta

0

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 by dlopen cannot be listed since their names may be a result of run time string processing.

    
por 17.10.2018 / 20:36