Como uma função é resolvida em tempo de execução?

1

Como uma função é resolvida no Linux em tempo de execução? É puramente baseado no nome e em alguma "tabela de símbolos", como eu imaginei, ou é algum tipo de endereço codificado? Eu li on-line que você tem que recompilar para Musl libc e para glibc, mas eles não deveriam ter as mesmas exportações de símbolo? Como os símbolos funcionam?

    
por JavaProphet 25.01.2016 / 22:25

1 resposta

1

Como o programa é carregado na memória antes do tempo de execução, as funções são mapeadas para determinados endereços de memória, em relação ao endereço base. Todas as chamadas para uma função são compiladas como o endereço de memória relevante. A tabela de símbolos é frequentemente incluída em um binário, mas para reverter os mapeamentos de endereços para nomes legíveis por humanos para fins de depuração. Tente nm -D /usr/lib/libc.so.6 em uma instalação típica do Linux para ver a tabela de símbolos da glibc.

Em termos de compatibilidade binária, glibc e Musl implementam padrões compartilhados, mas há uma variedade de idiossincrasias que devem ser refletidas em seus próprios arquivos de cabeçalho (por isso não há um pacote univeral de cabeçalhos de biblioteca padrão na maioria dos Linux). distros - eles são empacotados com cada biblioteca).

Do FAQ do musl:

Is musl compatible with glibc?

Yes and no. At both the source and binary level, musl aims for a degree of feature-compatibility, but not bug-compatibility, with glibc. When applications that work with glibc fail to compile against musl, the cause will usually be one of the following:

  • Assuming that including one header will cause symbols from another unrelated header to be exposed. This is an application bug, and fixing it is as simple as adding the missing #include directives.
  • Using implementation details from the glibc headers which were not meant to be exposed to applications. This is also an application bug, and it can usually be fixed by search-and-replace (e.g. replacing __pid_t with pid_t in the source).
  • Use of an interface that’s not implemented in musl. This can only be fixed by making the application’s use of the interface optional, or by extending musl to support the missing interface.

Binary compatibility is much more limited, but it will steadily increase with new versions of musl. At present, some glibc-linked shared libraries can be loaded with musl, but all but the simplest glibc-linked applications will fail if musl is dropped-in in place of /lib/ld-linux.so.2.

    
por 26.01.2016 / 03:44

Tags